Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: K&R exercise 3-4 handle largest negative number implementation Date: Wed, 30 Mar 2016 12:03:43 -0700 Organization: None to speak of Lines: 57 Message-ID: References: <5caca6ab-a075-4462-b0e1-ed74057955a5@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="14553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/G9pyll/4WrvvMEy2ft5QX" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:BrlWTDfOsYC7ODlMXgyDKx+7fqc= sha1:aMbVEJvG9Er59JvDF5RrNoScUac= Xref: csiph.com comp.lang.c:85373 supercat@casperkitty.com writes: > On Tuesday, March 29, 2016 at 2:31:38 PM UTC-5, Keith Thompson wrote: >> C99 changed the rules for integer division, requiring truncation toward >> zero. > > I sometimes get confused with some of the differences between K&R2 and the > C89/C90 Standard. In principle, there is no difference; K&R2 describes the language defined by the 1989 ANSI C standard (which is the same language described by the 1990 ISO C standard). K&R2's description is less rigorous. What differences to you see? > I find it curious that C90 chose to loosen things compared > to K&R2 but C99 chose to restore things to the pre-C90 state of affairs. I don't believe that's accurate -- nor, as far as I know, is the C99 behavior the same as "the pre-C90 state of affairs". > I also find it interesting that a behavior which was chosen to make > things simplest for ancient hardware is actually more expensive in > many cases on modern hardware than would be Euclidian division/modulus > (in a lot of hardware, division by most constants could be handled by > doing a multiply- by-constant and ignoring the lower word, but the > required signed-division hardware needs an extra step to correct > negative results). The C99 rationale says: In C89, division of integers involving negative operands could round upward or downward in an implementation-defined manner; the intent was to avoid incurring overhead in run-time code to check for special cases and enforce specific behavior. In Fortran, however, the result will always truncate toward zero, and the overhead seems to be acceptable to the numeric programming community. Therefore, C99 now requires similar behavior, which should facilitate porting of code from Fortran to C. The table in ยง7.20.6.2 of this document illustrates the required semantics. C89/C90 has the div() and ldiv() functions (C99 added lldiv()) which specify the truncate toward zero behavior when the "/" and "%" operators didn't specify it. With C99's change to specify the behavior of "/" and "%" more precisely, those functions are not as useful, but they can still be used to get both results in one operation. (Personally, I find a definition where, for example, -7 % 5 yields 3 rather than -2 to make more mathematical sense, but apparently the Fortran numeric programming community doesn't share my opinion.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"