Fwd: [RFC] Consistent numeric range for "expr" on all architectures

David Schultz das at FreeBSD.ORG
Thu Jun 30 17:42:09 UTC 2011


On Thu, Jun 30, 2011, Stefan Esser wrote:
> Am 30.06.2011 18:46, schrieb David Schultz:
> > There are two problems, however.  First, the implementation
> > doesn't do this: it uses intmax_t, which has platform-dependent
> > width, at least in theory.  Second, it sounds like POSIX doesn't
> 
> Yes, but it seems that intmax_t is guaranteed to be at least 64bit wide.

The distinction is that int64_t is always exactly 64 bits, whereas
intmax_t could be wider.  If the goal is to guarantee that expr's
arithmetic is architecture-independent, then int64_t is a more
appropriate type.  (This requires a narrowing conversion and range
check after strtoimax(), but the compiler should optimize it
away.)

> > Overflow checking is a separate concern, and one that is more
> > likely to cause problems.  I'd be more careful about changing the
> > default behavior there, because some scripts might rely on modular
> > arithmetic without overflow checks.
> 
> You cannot portably rely in overflow, since you have no guarantee that
> overflow occurs at a specific boundary.

My point was that some scripts might rely on the lack of overflow
checking anyway.  This is a separate and potentially more
problematic change.  But I'm not trying to argue that it's
necessarily a bad idea.

> > Another thing that is likely to cause confusion is expr(1)
> > behaving differently from the shell builtin, and differently from
> > the shell's arithmetic.  Above all else, I suggest trying to make
> > everything consistent...perhaps talk to jilles@ about the shell
> > side of things.
> 
> My change in 2000 made the shell builtin do 64bit arithmetic as well (in
> fact, the shell build just included the expr.y file ...).

I don't know the state of the shell these days.  Didn't jilles@
change the shell to do that more recently?  My point here is that
working to make both the shell and expr behave identically would
be ideal.


More information about the freebsd-standards mailing list