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-Thread: 103376,21960280f1d61e84 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!trnddc05.POSTED!53ab2750!not-for-mail From: Dave Thompson Newsgroups: comp.lang.ada Subject: Re: How come Ada isn't more popular? Organization: Poor Message-ID: <7vb4u2lkqq62c0kpsjha30m4hda61dlgpa@4ax.com> References: <1169531612.200010.153120@38g2000cwa.googlegroups.com> <1169588206.234714.312650@k78g2000cwa.googlegroups.com> <1169624573.534128.172610@s48g2000cws.googlegroups.com> <87sle0sv9o.fsf@ludovic-brenta.org> <5rigs215675tlmql11ens5idv0188eqrut@4ax.com> <1170759701.876485.217200@s48g2000cws.googlegroups.com> X-Newsreader: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 26 Feb 2007 05:47:19 GMT NNTP-Posting-Host: 141.150.221.155 X-Complaints-To: abuse@verizon.net X-Trace: trnddc05 1172468839 141.150.221.155 (Mon, 26 Feb 2007 00:47:19 EST) NNTP-Posting-Date: Mon, 26 Feb 2007 00:47:19 EST Xref: g2news2.google.com comp.lang.ada:9540 Date: 2007-02-26T05:47:19+00:00 List-Id: On 6 Feb 2007 03:01:41 -0800, "Ludovic Brenta" wrote: > On Feb 6, 10:54 am, Dave Thompson wrote: > > On Wed, 24 Jan 2007 09:07:15 +0100, Ludovic Brenta wrote: > [snip] > >> (*) consider that when we increment the address by one, it then > >> references the next byte; whereas if we increment the pointer by one, > >> it points to the next "unsigned long", i.e. 2, 4 or 8 bytes and not 1 > >> byte further. C makes no distinction between addresses and pointers, > >> lacking expressiveness in a crucial area. > > > > Wrong. C, even before C89, does know about pointer targets (strides). > > Only _very_ early, Bell-Labs-only, pre-K&R1 C that was still in > > transition from B had pointer === integer. > > Wrong? I think we're in agreement here. I was explaining that a > pointer is not the same thing as an address, since incrementing a > pointer gives a different result (next object) than incrementing an > address (next byte). > Okay, I agree with that. I read your "no distinction" to mean "addresses and pointers are/appear the same [in C]" or as it is more commonly phrased (and wrong) on c.l.c "pointers are just addresses". > In C, address arithmetic is implemented in terms of char* and size_t Quibble: cv-qual un/signed/plain char *, and any integer type but preferring size_t and ptrdiff_t, or perhaps ssize_t in POSIX > only because sizeof(char) == 1; I think that's a hack. In contrast, > address arithmetic in Ada is in terms of System.Address and > Storage_Offset, which is much more explicit. > Ada is certainly more explicit, as usual. In 1970 there was still current or at least recent extensive experience with word-addressed machines where you in fact did not have consistent (flat) addresses of all possible data elements, as the now-popular understanding expects and the Ada model demands (though presumably it could be emulated). I don't know if you mean 'hack' in its older-computer-specific meaning of 'clever but arcane', or its more general and media-preferred meaning of 'cheap', 'sloppy', and even 'criminal'. Given the environment in which and the goals for which C was created, I think this was a reasonable design choice at the time, and qualified for the former meaning -- if we weren't still stuck with it (and other infelicities) today. FWLIW C99 adds standard names (typedefs) [u]intptr_t for integer types able to hold without loss (but with explicit conversions) any data pointer value, if the implementation has such (and all I know of do). You still aren't officially guaranteed arithmetic on these values, but on all known modern platforms it does work. > > > set_bit_in_register (0xDEADBEEF); > > > > The type mismatch is a constraint violation (which must be diagnosed) > > if the prototype declaration (or definition) is visible, and > So 0xDEADBEEF is an int, and there is no implicit conversion to > unsigned long*. Is that what you're saying? OK, now I see my knowledge > of C is fading away... > Right. Or rather, 0xDEADBEEF is some integer type, exactly which depending on your platform -- on most common platforms today with 32-bit signed and unsigned int it will be unsigned int -- and there is no implicit conversion from any integer type to any pointer, except as a very hysterical raisin special case the constant (manifest) zero to a null pointer (of any type). (And even that is better expressed with the standard macro NULL instead.) - formerly david.thompson1 || achar(64) || worldnet.att.net