From: Paul Eggert
Any decent compiler will generate exactly the same
code for both. No shifts or OR will be done at
runtime -- they'll all be done at compile time.
For example:
[...]
Yes, while I tend to underestimate them, I do understand compile-time
expression evaluation and
On 05/28/2012 08:38 AM, Steven M. Schweda wrote:
I'm left wondering whether, say, var = con1 31 1 | con0 offers
so great an improvement in clarity
It's not simply clarity (which is a matter of style).
It's maintainability. For example, if a typo had
been inadvertently put into the old 32-bit
From: Paul Eggert
[...]
It's maintainability. For example, if a typo had
been inadvertently put into the old 32-bit code
(a misspelled identifier, say, due to someone typing
a character by mistake), it would not have been caught
by someone compiling on the 64-bit platform. But with
the
On 05/28/2012 09:26 PM, Steven M. Schweda wrote:
any environment-specific code really needs to be tested in
the specific environment
Sure, that's important, but it's also important
to minimize the number of problems that can slip
through and be caught only by testing. Our tests
are not
On 05/26/2012 01:24 PM, Steven M. Schweda wrote:
On VAX (a 32-bit system), it's fatal.
That's worse than a warning, and I can see similar problems
might happen on other 32-bit-only systems, so we should fix it.
Generally speaking we prefer 'if (xxx)' to '#if xxx' where
either will do,
From: Paul Eggert
I installed the following patch, which I hope fixes the problem. [...]
It does around here. Thanks. I just hope that all the C
preprocessors around the world appreciate all the work that you're
saving them. It was educational for me, too. I'm beginning to see why
my old
Steven M. Schweda wrote:
From: Paul Eggert
I installed the following patch, which I hope fixes the problem. [...]
It does around here.
Thanks for confirming.
Thanks. I just hope that all the C
preprocessors around the world appreciate all the work that you're
saving them. It was
From: Jim Meyering
Thanks for confirming.
Glad to. It was (almost) the least I could do.
Do you know of a modern optimizing compiler that fails
to elide the dead code? If so, please let us know.
I realize that continuing this discussion is almost certainly
pointless, but, just for
On 05/27/2012 05:55 PM, Steven M. Schweda wrote:
it's not immediately obvious (to me) that the
code for two shifts and an OR will necessarily be more efficient (in
space or time) than the code for an assignment
Any decent compiler will generate exactly the same
code for both. No shifts or OR
Re: http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00154.html
[...] I think an ifdef may be used instead [...]
I agree. I, too, recently ran into this problem, in my case, on VMS.
On Alpha (and IA64, both 64-bit systems), the result is annoying
informational messages:
ALP $ cc
Gianluigi Tiesi wrote:
On 26/03/2012 7.33, Jim Meyering wrote:
Gianluigi Tiesi wrote:
On 25/03/2012 6.58, Paul Eggert wrote:
On 03/24/2012 09:28 PM, Gianluigi Tiesi wrote:
While compiling regex module one android I've discovered a problem
that on other 32bit compiler is only a warning
...
On 25/03/2012 6.58, Paul Eggert wrote:
On 03/24/2012 09:28 PM, Gianluigi Tiesi wrote:
While compiling regex module one android I've discovered a problem
that on other 32bit compiler is only a warning
...
it's correct, but I think an ifdef may be used instead since
BITSET_WORD_BITS is a define
Gianluigi Tiesi wrote:
On 25/03/2012 6.58, Paul Eggert wrote:
On 03/24/2012 09:28 PM, Gianluigi Tiesi wrote:
While compiling regex module one android I've discovered a problem
that on other 32bit compiler is only a warning
...
it's correct, but I think an ifdef may be used instead since
On 26/03/2012 7.33, Jim Meyering wrote:
Gianluigi Tiesi wrote:
On 25/03/2012 6.58, Paul Eggert wrote:
On 03/24/2012 09:28 PM, Gianluigi Tiesi wrote:
While compiling regex module one android I've discovered a problem
that on other 32bit compiler is only a warning
...
it's correct, but I think
While compiling regex module one android I've discovered a problem that
on other 32bit compiler is only a warning
in regcomp.c at 961
dfa-word_char[0] = UINT64_C (0x03ff);
dfa-word_char[1] = UINT64_C (0x07fe87fe);
the datatype is defined as unsigned long
but
On 03/24/2012 09:28 PM, Gianluigi Tiesi wrote:
While compiling regex module one android I've discovered a problem
that on other 32bit compiler is only a warning
...
it's correct, but I think an ifdef may be used instead since
BITSET_WORD_BITS is a define
Generally speaking we prefer 'if
16 matches
Mail list logo
