Bug 51171

/bin/sh handles only 32-bit numbers while there are a lot of 64-bit values in
the system now. Also it just silently ignores hte overflows so the system
administrator have no chance to find out that there were incorrect calculations
done in the scripts.

It is traditional behaviour but not necessary. Here is my arguments I've send
to -standards mailing list. They did not meet objections:

1) POSIX and SUSv3 _require_ at least long type for integers in the shell, and
   explicitly _allow_ to use integer in the range beyond the long type range.
   SUSv2 _requires_ long and _allows_ extensions as well (but there are no
   explicit words about wider range as in SUSv3). It is the theoretical aspect.
2) ksh, zsh and bash handle longer integers properly. The last two have
   64-bit arithmetics and first one has float inside. That is the compatibility
   aspect.
3) These days we have a lot of 64-bit stuff in the system: from ipfw counters
   to file sizes. Moreover we really have such big numbers in everyday FreeBSD
   usage. But now /bin/sh silently produce just wrong results dealing with
   such numbers due to overflow. So old scripts which worked from 1997 or such
   now can produce meaningless results and it will not be even noticed.
   I can suggest to write new ones with bash or zsh but some people continue
   to use their old stuff (don't touch while works, you know). So it IS better
   to change our basic shell and extend it's abilities. That is the practical
   aspect.

Fix: I suggest the following patch on the base of the discussion in the -hackers.
It introduces 64-bit arithmetics. Also it adds a new command-line option:
-O (error when there is overflow). It is possible to build /bin/sh without
the overflow control, just -DOVERFLOW needed to be removed from the Makefile.
How-To-Repeat: 
$ /bin/sh -c 'echo $((12345678900))'
2147483647