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 'c
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
That change is obviously safe, but why is it needed? Gnulib assumes
C89, and the preprocessors that you mention don't conform to C89.
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 putti
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
> > ea
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 e
Ben Pfaff writes:
>
> I was under the impression that gnulib targets C89 and above,
> making this a non-issue.
It would be, but I've found at least one otherwise-c89 compiler that
keeps the old preprocessor behavior in its default mode. Since it's so
easy to avoid the problem, it seems worthwile
[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 i
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
===
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 wa
-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
Hi Bruno,
Does this patch look okay to you?
-- Mark
ChangeLog entry:
* lib/stdint_.h: A POSIX conforming already
includes a superset of on some platforms like SGI
for both c89 and c99, but only provide for c99.
Avoid including if everything works with
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
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
> is not available at the moment the autoconf test is
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
is not available at the moment the autoconf test is run.
We cannot change that easily.
Bruno
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
community still?
Bruno
16 matches
Mail list logo
