Deutsch English Français Italiano |
<20240912184307.00005d07@yahoo.com> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Michael S <already5chosen@yahoo.com> Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Thu, 12 Sep 2024 18:43:07 +0300 Organization: A noiseless patient Spider Lines: 65 Message-ID: <20240912184307.00005d07@yahoo.com> References: <vaqgtl$3526$1@dont-email.me> <memo.20240830090549.19028u@jgd.cix.co.uk> <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com> <2024Sep10.101932@mips.complang.tuwien.ac.at> <ygn8qvztf16.fsf@y.z> <86frq6gnn3.fsf@linuxsc.com> <20240911195221.00004881@yahoo.com> <86bk0thfq9.fsf@linuxsc.com> <20240912141033.00006dd1@yahoo.com> <86ed5ogay6.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Injection-Date: Thu, 12 Sep 2024 17:42:44 +0200 (CEST) Injection-Info: dont-email.me; posting-host="795ae34dc5508363080905c3d099c810"; logging-data="248937"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18f7Zug26+mehJJPnOXoWuesEOA/NPiLqA=" Cancel-Lock: sha1:ZOLPTkd6xI1/e0nroo8qQYuvVCI= X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32) Bytes: 4410 On Thu, 12 Sep 2024 08:15:29 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Wed, 11 Sep 2024 17:34:38 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> > >>> Real mode x86 C compilers operating in Large and Compact Models > >>> that were popular on IBM-compatible PCs 30-40 years ago could > >>> have more than one representation for the pointer to the same > >>> memory location. If my memory serves me, the rules of pointers > >>> comparison for equality were the same as rules of comparison for > >>> <>. In both cases for reliable result pointers had to be > >>> explicitly normalized (i.e. converted from 'far' to 'huge' or > >>> something like that). > >>> > >>> It was long time ago and even back then I didn't use Large model > >>> very often, so it's possible that I misremember. But if I > >>> remember correctly, does it mean that those C compilers now would > >>> be considered non-compliant? > >> > >> The C standard was first ratified (by ANSI) in 1989. The rules > >> for pointer comparison were clarified in the C99 standard, but it > >> has always been true that pointers to the same object have to > >> compare equal. > >> > >> C environments that have things like 'far' or 'huge' pointers, > >> etc, are not standard C but must have extensions so that they can > >> deal with the different kinds of pointers. Depending on how the > >> non-standard kinds of pointer worked, the implementation might or > >> might not be conforming. Most likely though it's a moot point > >> because once a program starts using an extension all the rules > >> can change, and the C standard allows that. It's only programs > >> that look like really standard C that have to do what the C > >> standard says (for the implementation to be conforming); any > >> code that declares a 'far' pointer or 'huge' pointer certainly > >> isn't standard C. > > > > In Compact and Large models data pointers are 'far' by default. So, > > the source doesn't have to use non-standard declarations. > > In that case, if the defaulted 'far' pointers don't follow the > rules given in the C standard for regular pointers, then the > implementation is not conforming. Extensions are allowed only if > they don't change the behavior of any strictly conforming > program. If undecorated pointer declarations don't observe this > condition then it's not a valid extension, which in turn causes > the implementation to be non-conforming. Thinking about it, there likely were no way to create aliases via using only standard language constructs. That's assuming that any use of preserved values of pointers to de-allocated heap storage, including use for comparison, is non-standard. So it probably was conforming implementation at the end.