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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-26 20:13:51 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.cidera.com!Cidera!nyccyc01!news-out.nyc.rr.com!typhoon.nyc.rr.com.POSTED!not-for-mail From: "Igor Tandetnik" Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ 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> <30Yh7.54069$l7.6430776@typhoon.nyc.rr.com> <3B888631.204F@mindspring.com> <3B89A7D4.6E7A8BC4@yahoo.com> Subject: Re: Subtle Bugs, kudos Ada (was How Ada ...Red Code ...) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Mon, 27 Aug 2001 03:13:43 GMT NNTP-Posting-Host: 66.65.77.58 X-Complaints-To: abuse@rr.com X-Trace: typhoon.nyc.rr.com 998882023 66.65.77.58 (Sun, 26 Aug 2001 23:13:43 EDT) NNTP-Posting-Date: Sun, 26 Aug 2001 23:13:43 EDT Organization: Road Runner - NYC Xref: archiver1.google.com comp.lang.ada:12447 comp.lang.c:77001 comp.lang.c++:85849 Date: 2001-08-27T03:13:43+00:00 List-Id: "Joe Maun" wrote in message news:3B89A7D4.6E7A8BC4@yahoo.com... > Igor Tandetnik wrote: > > > > Joe Maun says that one can reliably examine the sign bit even after it was > > shifted from its original leftmost position. I argue that the standards > > specify that all the bits of the result of the shift operation are > > implementation-defined - not just high-order bits that the shift introduces. > > The standards say that the *value* resulting from the expression is > implementation-defined. They also say that the result is "E1 > right-shifted E2 bit positions". Since these two statements are not > contradictory (not specifying the high order bits is sufficient to make > the /value/ implementation defined), why do you think the latter doesn't > apply? On one hand, I can see how the standard can be read your way. On the other hand, I can't say that this clause in the standard is absolutely clear and unambiguous. My opinion is that those two statements can be considered contradictory, and, just to be on the safe side, I would not recommend relying on the result of righ-shifting a negative value in a code intended to be portable. -- With best wishes, Igor Tandetnik