[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: large integer truncation in regex module

From: Steven M. Schweda
Subject: Re: large integer truncation in regex module
Date: Sun, 27 May 2012 19:55:22 -0500 (CDT)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]