Re: large integer truncation in regex module

[Steven M. Schweda]

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 the record, ...

   It's not absolutely clear that "Compaq C V6.4-005 on OpenVMS VAX
V7.3" qualifies as "modern", but 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.

> +         dfa->word_char[0] = bits1 << 31 << 1 | bits0;

   That two-piece shift does avoid -- I almost wrote "neatly avoids",
but decided that that wouldn't be accurate -- a complaint like this:

%CC-W-SHIFTCOUNT, In this statement, the shift count "32" is negative or
is greater than or equal to the promoted size of the operand "bits1".

which I appreciated, but 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.

   But, hey.  If "Parentheses good, pound-sign ba-a-a-ad" is the guiding
princlple these days, then I'll just sit here on my scrap heap with the
rest of the fossils, and yearn for the good old days of fretting over
bytes and microseconds.

   I'm still glad to see a fix, even though I'm confident that this
particular fix will never be my favorite piece of code.

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

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