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.