Re: large integer truncation in regex module

[Steven M. Schweda]

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 dead-code elimination, and I'll admit that a
"decent compiler" can optimize out all the stuff in here which irritates
me so much.  However, as I explained before, "one of the advantages of
using the C preprocessor as it was intended to be used is that one
doesn't need to _care_ whether the compiler proper can optimize away
some useless code, because it will never see that useless code."  That's
still true, and not caring is, to me, still valuable.

> [...] on both x86-64 and x86 (with GCC 4.7.0 -O2).

   My concept of portability extends beyond Intel CPU chips and GCC. 
>From time to time, for example, I've used a bundled C compiler on HP-UX,
which has been (intentionally) crippled to the extent of disabling the
"-O" option(s).

> [...] looking at the resulting assembly language code.

   Some nice, cool day when I find no better ways to spend my time, ...

>    I realize that continuing this discussion is almost certainly
> pointless, [...]

   The evidence for that one is piling up all around us, but ...

   As I recall, the original argument presented for eschewing use of the
C preprocessor here went something like the following:

> Generally speaking we prefer 'if (xxx)' to '#if xxx' where
> either will do, because the former is easier to read and
> reason about.

I'm left wondering whether, say, "var = con1 << 31 << 1 | con0" offers
so great an improvement in clarity over, say, "var = con" that it
justifies the preference for "()" over "#" here.

------------------------------------------------------------------------

   Steven M. Schweda               address@hidden
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547