Paul Eggert writes:
>
> I think it's more that we're worried about having to cater to other
> silly compiler incompatibilities with C89. There are so many of them...
Yes, I understand. The camel's nose into the tent
> But to save time on this I installed your patch
Thanks.
> (though I u
[EMAIL PROTECTED] (Larry Jones) writes:
> The cost of the change is exceeding low
I think it's more that we're worried about having to cater to other
silly compiler incompatibilities with C89. There are so many of them...
But to save time on this I installed your patch (though I used _
rather t
Ralf Wildenhues writes:
>
> ...this time the percolation latency will be about as low as it gets.
Only on your end. The bottleneck is usually at the other end of the
pipeline. :-)
-Larry Jones
Physical education is what you learn from having your face in
someone's armpit right before lunch. -
Hi Ralf,
...this time the percolation latency will be about as low as it gets.
:-)
Likely so, OTOH, they are not bound together so folks will try to mix
'n match. :)
Since I don't assume I get the chance of saying this very often...
* Larry Jones wrote on Fri, Jun 23, 2006 at 07:51:37PM CEST:
> The big benefit is that it fixes the immediate problem now as opposed
> to waiting for the autoconf change to percolate out into the world.
...this time the percolatio
Paul Eggert writes:
>
> That change is obviously safe, but why is it needed? Gnulib assumes
> C89, and the preprocessors that you mention don't conform to C89.
It isn't absolutely needed, but I'd argue that it's desirable. The cost
of the change is exceeding low -- it doesn't make the code any
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
===
13 matches
Mail list logo
