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: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-26 08:02:56 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> 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: Sun, 26 Aug 2001 15:02:49 GMT NNTP-Posting-Host: 66.65.77.58 X-Complaints-To: abuse@rr.com X-Trace: typhoon.nyc.rr.com 998838169 66.65.77.58 (Sun, 26 Aug 2001 11:02:49 EDT) NNTP-Posting-Date: Sun, 26 Aug 2001 11:02:49 EDT Organization: Road Runner - NYC Xref: archiver1.google.com comp.lang.ada:12430 comp.lang.c:76952 comp.lang.c++:85754 Date: 2001-08-26T15:02:49+00:00 List-Id: "pete" wrote in message news:3B888631.204F@mindspring.com... > Igor Tandetnik wrote: > > > > "Joe Maun" wrote in message > > news:3B8462C8.5596C089@yahoo.com... > > > Kaz Kylheku wrote: > > > > Also, shifting right a signed quantity whose sign bit is 1 is > > > > implementation-defined; > > > > > > This doesn't matter in this case. The value that the vacated bits take > > > is indeed implementation defined, but the sign bit must reliably be > > > shifted into the required position, since nothing frees it from the > > > requirement that "The result of E1 >> E2 is E1 right-shifted E2 bit > > > positions". > > > > > > > I think it's undefined in C99. > > > > > > No, it isn't. > > > > > I don't know. C99 says: > > "If E1 has a signed type and a negative value, > > the resulting value is implementation-defined." > > It says the whole result of the shift is implementation-defined, > > not that the bits to the left of original bits are > > implementation-defined. I don't see any guarantee that original > > bits have to be preserved. > > > C++ standard has the same exact wording. > > The propagation of the high order bit when a signed integer > is shifted right is THE example of implementation-defined behavior. The question is not what happens to high-order bits that are introduced by the shift - it is clear that the standards make no guarantee about it and leave it to implementation. The question is what happens to the bits that were there before the shift - do the standards guarantee that all of the original bits (except low-order ones shifted away) are preserved albeit shifted from their original positions? 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. -- With best wishes, Igor Tandetnik