bug-gnulib
[Top][All Lists]
Advanced

[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: Mon, 28 May 2012 23:26:08 -0500 (CDT)

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 new code, compiling on one platform verifies the
> syntax on all platforms.  This is an inherent advantage
> of "if (...)" over "#if ...", and it's an advantage we've
> come to appreciate over time.

   This argument would be more compelling if "is syntactically correct"
and "works properly" were equivalent.  Sadly, they're not, so I tend to
believe that any environment-specific code really needs to be tested in
the specific environment where it isn't all optimized into oblivion.

> In this particular example, there's another maintainability
> advantage to the new code: it has one copy of the
> magic hexadecimal constants, not two.  So testing on a
> 64-bit platform also helps to test that these constants are
> right on a 32-bit platform.  The old code didn't have this
> property.

   And it's impossible/impractical to arrange this commonality using
#define (et al.)?

> > I've used a bundled C compiler on HP-UX,
> > which has been (intentionally) crippled to the extent of disabling the
> > "-O" option(s).
> 
> As have I, but that's doesn't trump maintainability.
> For us, maintainability is more important than minor
> performance issues on obsolete or crippled systems.

   I remain unconvinced of these claimed advantages.  (But it's not my
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]