This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Output of "uname -s" and "uname -o"


On Tue, Jun 10, 2008 at 01:10:44AM -0400, Igor Peshansky wrote:
>On Mon, 9 Jun 2008, Eric Blake wrote:
>
>> According to Igor Peshansky on 6/9/2008 8:37 AM:
>> > > Old header files plus backward compatibility.  The structure is
>> > > exposed to applications.  Every change here requires to check for
>> > > the Cygwin version under which the application has been built.  I
>> > > cursed the short field length myself at onepoint, but the added
>> > > complexity looks a bit questionable.
>> >
>> > #define uname uname_long
>> > #define utsname utsname_long
>> > #define _UTSNAME_LENGTH 20
>> > struct utsname_long {
>> >   char sysname[_UTSNAME_LENGTH];
>> >   char nodename[_UTSNAME_LENGTH];
>> >   char release[_UTSNAME_LENGTH];
>> >   char version[_UTSNAME_LENGTH];
>> >   char machine[_UTSNAME_LENGTH];
>> > };
>> > int uname_long (struct utsname_long *);
>> >
>> > Or something along those lines...
>> > 	Igor
>>
>> This would be a similar change to when stat64 was created.  You can't
>> make a struct have larger fields without adding compatibility checks to
>> make cygwin1.dll support the old size for some time to come, unless we
>> declare all applications compiled before the larger-size struct as
>> no-longer-supported.
>
>You can change the struct, provided it's a different struct.  AFAICS,
>the above #defines take care of this.  Applications compiled against
>the old Cygwin versions will use uname (and struct utsname), and the
>newly compiled code will use uname_long and struct utsname_long.

Maybe it isn't clear.  This may be new territory to you but we have
already done things like changing the size of a structure by using
#define (and other) trickery in Cygwin even before transitioning from
stat64 to stat.  You also need a new function, of course.

I haven't seen any good explanation of how you'd deal with any
application which is relying on the current behavior since you'd be
breaking externally visible backwards compatibility.  That's the
difference between changing the structure size for uname versus changing
the structure size for stat or terminfo.

cgf


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]