Longstanding __USE_W32_SOCKETS hiccup.

[Dave Korn]

Corinna Vinschen wrote:
> On Aug  7 15:29, Dave Korn wrote:
>> Corinna Vinschen wrote:
>>
>>> struct timeval in winsock2.h only differs by using `long' instead of
>>> time_t and susecond_t as types of tv_sec and tv_usec.  The size of the
>>> structs is the same, the underlying types are equivalent.
>>>
>>> So, wouldn't it be less hassle in the long run to define struct timeval
>>> in winsock2.h equivalent to sys/time.h if building for Cygwin?
>>   Looking at your patch, I discovered that we never actually define
>> _TIMEVAL_DEFINED anywhere!
>>
>>   That gave me another idea; what if we turn your idea on its head, and define
>> struct timeval in sys/time.h equivalent to winsock2.h if *not* building for
>> Cygwin (sockets, i.e. if __USE_W32_SOCKETS).
> 
> I don't understand.  Who would use the *Cygwin* header sys/time.h
> and then not build for Cygwin?

  Sorry, I worded that confusingly.  "Not building for Cygwin *sockets*", not
"not building for Cygwin" is what I meant.

>>   I _think_ (not having pondered it for very long yet) that doing it this way
>> should work for any order of includes and any state of the __USE_W32_SOCKETS macro.
> 
> What was wrong with my proposal?

  Nothing fundamentally wrong with the code as far as I could see, more that I
have systematic/architectural/design-philosophical reservations:

1- Involves more intrusive edits: two files instead of just one.
2- Has to go through the MinGW/w32api teams rather than something we can do
locally (since it's adding support that's only wanted on Cygwin).
3- Changes the definition of timeval to diverge from what's in MSDN, and does so
unconditionally, even when coder explicitly states (__USE_W32_SOCKETS) that they
want the MS API.

    cheers,
      DaveK