Date: Tue, 8 Apr 2003 17:51:43 -0400 From: Mike Barcroft <mike@FreeBSD.org> To: Alex Semenyaka <alexs@ratmir.ru> Cc: freebsd-standards@freebsd.org Subject: Re: /bin/sh arithmetics: BIG NUMBERS Message-ID: <20030408175143.C14397@espresso.bsdmike.org> In-Reply-To: <20030408085112.GA22222@snark.ratmir.ru>; from alexs@ratmir.ru on Tue, Apr 08, 2003 at 12:51:12PM %2B0400 References: <20030408085112.GA22222@snark.ratmir.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Alex Semenyaka <alexs@ratmir.ru> writes: > Collegues, > > I need your opinion. Several days ago I've send to -hackers mailing list a > patch for /bin/sh which introduce 64-bit arithmetic operations instead of > 32-bit ones we have now. There were now principal objections there but > Giorgos Keramidas <keramida@freebsd.org> adviced me to ask here about the > FreeBSD's standards compliance of this. I hope that it IS ok withem but > I want to be absolutely sure. > > Argumentation "pro": > > 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. Sounds like its standards conformant. > Any "contras"? I would suspect there's a performance penalty on i386. Have you done any benchmarking? Best regards, Mike Barcroft
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030408175143.C14397>