From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-28 12:00:11 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) References: <3B6555ED.9B0B0420@sneakemail.com> <87n15lxzzv.fsf@deneb.enyo.de> <3B672322.B5EA1B66@home.com> <4a885870.0108112341.7ce02ac0@posting.google.com> <3B834E5D.B0D26AB1@adaworks.com> <9lvsic$bet9s$1@ID-9852.news.dfncis.de> <9m0193$grs$1@bird.wu-wien.ac.at> <3B83F042.4CFB073D@home.com> <3B8462C8.5596C089@yahoo.com> <87n14nmbf8.fsf@deneb.enyo.de> <3B89A809.46083436@yahoo.com> <871ylxpxu6.fsf@deneb.enyo.de> <3B8AA131.3FCC0E9A@yahoo.com> <87g0ad44ab.fsf@deneb.enyo.de> <3B8B1130.97FFDD66@yahoo.com> <3B8BD171.32C155D2@yahoo.com> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: <_SRi7.115023$B37.2552767@news1.rdc1.bc.home.com> Date: Tue, 28 Aug 2001 19:00:10 GMT NNTP-Posting-Host: 24.68.85.82 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 999025210 24.68.85.82 (Tue, 28 Aug 2001 12:00:10 PDT) NNTP-Posting-Date: Tue, 28 Aug 2001 12:00:10 PDT Xref: archiver1.google.com comp.lang.ada:12530 comp.lang.c:77262 comp.lang.c++:86277 Date: 2001-08-28T19:00:10+00:00 List-Id: In article <3B8BD171.32C155D2@yahoo.com>, Joe Maun wrote: >Kaz Kylheku wrote: >> >> In article <3B8B1130.97FFDD66@yahoo.com>, Joe Maun wrote: >[...] >> >introduces, which is what the quote above mentions. Everybody agrees >> >that that's implementation defined. The question is what about the bits >> >that already exist - are they guaranteed to be reliably shifted right? I >> >say yes, some say no. >> >> I have a C99 draft copy which says: >> >> ``If E1 has a signed type, and a negative value, the resulting value >> is implementation-defined.'' >> >> What is so hard to understand about this? >> >> There is absolutely no ambiguity about what it means for a resulting >> value to be implementation-defined. > >Right. However, while the value computed is implementation-defined, the >state of some bits is not necessarily so. An implementation-defined result gives the implementor complete freedom to choose the algorithm by which the result is selected. It's the same as unspecified behavior, except for the requirement to document. If the standard wanted to narrow down the selection, then the wording would contain the necessary refinements, with references to the behavior of particular bits. >Unlike most other operators, >the shift operators are defined both in terms of bits *and* values, two >different concepts. I don't see any reference to bits in the sentence ``If E1 has a signed type, and a negative value, the resulting value is implementation-defined''. >When a particular aspect of the standard is implementation defined, the >behavior chosen by the implementation has no license to violate a >different aspect of the standard. So while the *whole* value is indeed >implementation defined (there is no such thing as a partial value), I >don't see where it gets the license to violate "The result of E1 >> E2 >is E1 right-shifted E2 bit positions", which is not specified in terms >of values but in terms of bits. The entire paragraph from C99 says this: The result of E1 >> E2 is right shifted E2 bit positions. If E1 has an unsigned type, or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 divided by the quantity, 2 raised to the power of E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined. So you see, when the result is not implementation-defined, it is actually defined *arithmetically* as the quotient of an integer division by a power of two.