Re: [PATCH v2 1/5] Import "glob" and "getcwd" modules from gnulib

[Sergio Durigan Junior <sergiodj@redhat.com>]

On Wednesday, September 20 2017, Pedro Alves wrote:

> On 09/20/2017 09:30 PM, Sergio Durigan Junior wrote:
>> On Wednesday, September 20 2017, I wrote:
>> 
>>> On Wednesday, September 20 2017, Pedro Alves wrote:
>>>
>>>> This is all wrapped in #ifdef WINDOWS_SOCKETS, hence the question.
>>>>
>>>> It should be easy for you to determine whether WINDOWS_SOCKETS
>>>> is defined in your mingw build, and thus whether all this code
>>>> is part of the build or not.
>>>
>>> I will do that and report back.  Thanks,
>> 
>> WINDOWS_SOCKETS is not defined when building with the mingw compiler
>> from Fedora.  This means that removing that "#define" was actually not
>> correct, because "close" will not work as expected even with gnulib.
>
> Looks like it's defined by gnulib/m4/socketlib.m4, and seemingly
> we're not pulling in that module.
>
>> 
>> My proposal is to define "close" as it was being defined before, but
>> actually "#undef" it if it's already defined by other headers, like:
>> 
>>   #ifdef close
>>   #undef close
>>   #endif
>>   #define close(fd) closesocket (fd)
>> 
>> Does that work for you?
>> 
>
> (There's no need of wrap #undef with #ifdef/#endif.  That's redundant.)
>
> That'd #undef 'close' on all hosts, even if gnulib decides to
> replace it for some reason.  E.g., REPLACE_FCHDIR
> check in rpl_close (see my previous email).

Not all hosts; only on hosts that define USE_WIN32API.  This would
basically make sure we stick to the current behaviour, which is to
always define "close" as "closesocket" on win32.

> How about we switch close/closesocket around:
>
> #ifndef USE_WIN32API
> # define closesocket close
> #endif
>
> And then use closesocket instead of close?

That'd work, but my preference is to use "close" everywhere because
that's the de facto way of dealing with sockets.  Only win32 hosts need
this "closesocket" thing, and I don't think it makes sense to base use
this name in our sources.

But that's my opinion; if you want, I can reverse the logic on the
define's.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/