Simon Josefsson wrote:
I'd admit that these winsock2.h tests are a bit ugly, but I don't see
a good alternative. Ideas?
I don't see a better alternative. The problem is that the replacement
sys/socket.h is not available at the moment the autoconf test is run.
We cannot change that easily.
Bruno Haible [EMAIL PROTECTED] writes:
Simon Josefsson wrote:
I'd admit that these winsock2.h tests are a bit ugly, but I don't see
a good alternative. Ideas?
I don't see a better alternative. The problem is that the replacement
sys/socket.h is not available at the moment the autoconf test
Simon,
Ok to install the patch? You're mentioned as the origin of the file.
Sure. You don't need to ask me: I'm not mentioned as maintainer of this
file in modules/*.
Bruno
Hi Bruno,
Does this patch look okay to you?
-- Mark
ChangeLog entry:
* lib/stdint_.h: A POSIX conforming inttypes.h already
includes a superset of stdint.h on some platforms like SGI
for both c89 and c99, but only provide stdint.h for c99.
Avoid
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bruno Haible on 6/22/2006 5:37 AM:
Eric Blake wrote:
Is it worth adding a system module to gnulib that detects implementations
with
this bug, and provides rpl_system to work around it?
How many programs will be ported to OS/2?
Bruno Haible [EMAIL PROTECTED] writes:
Simon,
Ok to install the patch? You're mentioned as the origin of the file.
Sure. You don't need to ask me: I'm not mentioned as maintainer of this
file in modules/*.
Done.
The M4 macro doesn't seem to belong to one canonical module, so I was
not
Some older preprocessors substitue macro parameter names that occur in
character constants or string literals. This breaks base64.c since it
uses x as a parameter name in a macro that has a 'x' character constant
in its expansion. Here's a fix:
Index: base64.c
[EMAIL PROTECTED] (Larry Jones) writes:
Some older preprocessors substitue macro parameter names that occur in
character constants or string literals. This breaks base64.c since it
uses x as a parameter name in a macro that has a 'x' character constant
in its expansion.
I was under the
Larry Jones wrote:
I've found at least one otherwise-c89 compiler that
keeps the old preprocessor behavior in its default mode.
Which compiler is this, on which system? Please don't hide your knowledge.
Since it's so
easy to avoid the problem, it seems worthwile to do so.
It's not so easy
Bruno Haible writes:
Larry Jones wrote:
I've found at least one otherwise-c89 compiler that
keeps the old preprocessor behavior in its default mode.
Which compiler is this, on which system? Please don't hide your knowledge.
Sorry, it's IBM C V6 for AIX.
Since it's so
easy to avoid
Larry Jones wrote:
it's IBM C V6 for AIX.
I think they ship all kinds of compiler drivers, for several possible
standards, so you can choose the most appropriate one. So the escape
can be to use a different compiler driver.
I've also submitted a fix to autoconf folks that will result in
Eric Blake wrote:
According to Bruno Haible on 6/22/2006 5:37 AM:
Eric Blake wrote:
Is it worth adding a system module to gnulib that detects implementations
with
this bug, and provides rpl_system to work around it?
How many programs will be ported to OS/2? How active is the EMX-OS/2
Thanks for reporting that. Looks to me like someone just got
frustrated by 'const' without really understanding it, and put in a
'const' everywhere they could think of. (Sounds like some of my
students. :-)
I installed the following somewhat more-aggressive patch, which
removes eight uses of
13 matches
Mail list logo
