Paul Eggert writes:
> On 05/22/2012 05:45 AM, Eric Blake wrote:
>> I wonder if the 'extensions' module should add a -U_POSIX_SOURCE to
>> CFLAGS on platforms where defining _POSIX_SOURCE is known to disable
>> useful extensions.
>
> Typically it's not a good idea to second-guess users if they exp
On 05/22/2012 05:45 AM, Eric Blake wrote:
> I wonder if the 'extensions' module should add a -U_POSIX_SOURCE to
> CFLAGS on platforms where defining _POSIX_SOURCE is known to disable
> useful extensions.
Typically it's not a good idea to second-guess users if they explicitly
put something into CFL
On 05/22/2012 06:36 AM, Simon Josefsson wrote:
>> It may have worked by accident for now, but POSIX doesn't require it to
>> work, so we are better off using an explicit include that POSIX does
>> guarantee so that if future Interix ever fixes their headers for POSIX
>> compliance, we continue to
Eric Blake writes:
> On 05/22/2012 06:21 AM, Simon Josefsson wrote:
>> Bruno Haible writes:
>>
>>> Hi Simon,
>>>
I have reverted the strdup and select patch, and I'll treat
this as a user error.
>>>
>>> It was a user error. But the select.c patch was good: it fixed an
>>> earlier-unde
On 05/22/2012 06:21 AM, Simon Josefsson wrote:
> Bruno Haible writes:
>
>> Hi Simon,
>>
>>> I have reverted the strdup and select patch, and I'll treat
>>> this as a user error.
>>
>> It was a user error. But the select.c patch was good: it fixed an
>> earlier-undetected mistake (that would have
Bruno Haible writes:
> Hi Simon,
>
>> I have reverted the strdup and select patch, and I'll treat
>> this as a user error.
>
> It was a user error. But the select.c patch was good: it fixed an
> earlier-undetected mistake (that would have likely been a compilation
> error on Interix).
However In
Hi Simon,
> I have reverted the strdup and select patch, and I'll treat
> this as a user error.
It was a user error. But the select.c patch was good: it fixed an
earlier-undetected mistake (that would have likely been a compilation
error on Interix).
Bruno
Bruno Haible writes:
> Simon Josefsson wrote:
>> It was configured with:
>>
>> CC=c89 CFLAGS="-D_POSIX_SOURCE -I/usr/local/include" ...
>
> Bingo. On many platforms, the _POSIX_SOURCE macro has the effect of
> *hiding* declarations, not of enabling them:
>
> $ uname -srv
> IRIX64 6.5 10060437
>
Simon Josefsson wrote:
> It was configured with:
>
> CC=c89 CFLAGS="-D_POSIX_SOURCE -I/usr/local/include" ...
Bingo. On many platforms, the _POSIX_SOURCE macro has the effect of
*hiding* declarations, not of enabling them:
$ uname -srv
IRIX64 6.5 10060437
$ cat foo.c
#include
$ cc -E foo.c | g
Bruno Haible writes:
> Hi Simon,
>
>> Do we want to support IRIX 6.5? It doesn't appear to have strdup:
>>
>> cc-1515 c89: ERROR File = client.c, Line = 45
>> A value of type "int" cannot be assigned to an entity of type "char *".
>> *output = strdup (p);
>> ^
>> 1 error detec
Hi Simon,
> Do we want to support IRIX 6.5? It doesn't appear to have strdup:
>
> cc-1515 c89: ERROR File = client.c, Line = 45
> A value of type "int" cannot be assigned to an entity of type "char *".
> *output = strdup (p);
> ^
> 1 error detected in the compilation of "client
On 05/21/2012 01:42 PM, Simon Josefsson wrote:
> Would this be a reason to un-deprecate the 'strdup' module?
That's easy, right? and would solve the problem?
So let's go with that.
Do we want to support IRIX 6.5? It doesn't appear to have strdup:
cc-1515 c89: ERROR File = client.c, Line = 45
A value of type "int" cannot be assigned to an entity of type "char *".
*output = strdup (p);
^
1 error detected in the compilation of "client.c".
Would this be a rea
13 matches
Mail list logo
