Re: Equal yet different pointers

From	Spiros Bousbouras <spibou@gmail.com>
Newsgroups	comp.lang.c
Subject	Re: Equal yet different pointers
Message-ID	<pekHoob1TIG6yUsDs8OQMm076XDnt@bongo-ra.co> (permalink)
References	(8 earlier) <d3ba637c-7742-40c8-8d56-d218488873c0@googlegroups.com> <oumb15$e9$1@dont-email.me> <d7587529-4fbc-42d0-8b68-8e794ac70fcf@googlegroups.com> <oun8rm$p4m$1@dont-email.me> <b22a787e-0dc6-403f-ac7a-12d9a2a4a953@googlegroups.com>
Organization	virginmedia.com
Date	2017-11-18 07:30 +0000

Show all headers | View raw

On Fri, 17 Nov 2017 16:45:55 -0800 (PST)
supercat@casperkitty.com wrote:
> On Friday, November 17, 2017 at 12:13:28 PM UTC-6, David Brown wrote:
> > On 17/11/17 17:23, supercat@casperkitty.com wrote:
> > > On Friday, November 17, 2017 at 3:44:13 AM UTC-6, David Brown wrote:
> > >> On 16/11/17 23:34, supercat@casperkitty.com wrote:
> > >>> K&R 2nd Edition states that if sizeof (T) is N, then any object of type
> > >>> T will have its value encapsulated in N consecutive bytes; nothing that
> > >>> I have noticed in that book even hints at the possibility that objects
> > >>> whose addresses are taken might behave in a way observably contrary
> > >>> to that.
> > >>
> > >> K&R does not define the C language.  It sort-of defines the language
> > >> from before there was a standard definition.
> > > 
> > > It describes a languages that was designed for, and is thus highly suited
> > > for, systems programming actual machines; the language was called C by its
> > > creator Dennis Ritchie.
> > 
> > "Describes" is not "defines".  In the days of the K&R book, there were
> > several inconsistent C implementations.  The book was a rough standard,
> > and compilers followed it approximately, but it was not until ANSI C89
> > that the language was defined and standardised.
> 
> Whether or not any official standards body recognized the language, most
> implementations of C in the 1980s which targeted microprocessors were
> very consistent in how they mapped core aspects of the language to a
> target platform.  One would not need to read the documentation for a Z80
> C compiler, for example, to know that unless it was configured in some
> unusual fashion, the code:
> 
>     *(int*)0x1234 = 0x5678;
> 
> would cause values 0x34 to be written to address 0x5678 and 0x12 to be
> written to address 0x5679.

I think you have address and value reversed.

Given the caveat "unless it was configured in some unusual fashion" ,
wouldn't one need to read the documentation after all ?

Address 0x1234 may be ROM in which case nothing will be written. So at best
you're saying that if the C source code has
    *(int*)0x1234 = 0x5678;

then you want the compiler to emit assembly instruction(s) to (attempt to)
write the value 0x5678 to the appropriate memory locations based on
endianess. Obviously this isn't portable for reasons having to do with the
architecture and not with the C standard. Is there any architecture where
such a thing would be useful and the C compilers don't support it ? Even if
they don't , nothing in the standard prevents them from supporting it.

For a more realistic example , I'm aware that C compilers for MSDOS had
extensions for near and far pointers. If some C source used such extensions
would it compile on say a Unix system ?

Overall I'm not sure that the consistency you claim actually existed back
then and even if it did that it made it easier to write useful code (as
opposed to contrived examples).

> > The use of quotation marks here is an extraordinarily petty and
> > self-righteous condemnation of the work done by the C standards
> > committee and C compiler developers everywhere.  The paper you like to
> > refer to, and are copying from here, made some interesting points - but
> > it's pathetic distinction between C and "C", and optimisations and
> > "optimisations", makes it sensationalist trash.  You would do well not
> > to copy it.
> 
> What names would you prefer to distinguish the language defined by Standard
> for freestanding implementations, versus a language which would be formed
> by adding a couple additional guarantees:
> 
>    Every object of size N which is of static duration or has its address
>    taken must behave as though its state is encapsulated in N bytes starting
>    at address N, and scalar types must use the same representation as defined
>    by the underlying platform.

"address N" : did you mean to use a different letter ?

"state is encapsulated in N bytes" : this is meaningless since the standard
does not give any definition for an object state. So to have something
meaningful you need to provide such a definition and describe how the state
of an object interacts with other parts of the language.

"scalar types must use the same representation as defined by the underlying
platform" : if I interpret this correctly , a conforming implementation would
be forbidden for adding metainformation to things like pointers. Such
metainformation might be the size of the object they point to. I think this
would be an unfortunate restriction ; so called fat pointers can reduce
errors at the cost of some speed. A conforming implementation should not be
precluded from offering such a trade off. Also , what would your restriction
mean for an interpreted C ? (I'm not actually sure whether an interpreted C
can count as freestanding)

>    In cases where the Standard does not define the behavior of a numeric or
>    pointer arithmetic operation or comparison, but a platform does, the
>    implementation will behave according to the platform's defined behavior.

Unless the platform's definitions use C terms , I don't see how this means
anything. A microprocessor documentation will talk about things like registers
and addressing modes. It is up to a C implementation to define a correspondence
between those and C concepts like pointers. So what would it mean for a C
implementation to follow the platform's definitions ?

> Certainly there are many programs for hosted implementations which would
> not benefit from such guarantees, and even programs for freestanding
> implementations could usually get by with weaker ones.  On the other hand,
> the latter language would be sufficient to accomplish a very wide range of
> useful tasks on many platforms without reliance upon any compiler-specific
> features beyond those two.

Would it be able to do so portably ? If not then what's the improvement over
relying on compiler specific extensions ?

> Given that the latter language can do vastly more things than the one defined
> by the Standard, I would think it deserves a name.  What name would you
> recommend?

To the extent that I can guess your intentions , I would propose
    PAC = portable assembly C

.I think your complaint is that C was more of a portable assembly in the
1980s than it is now but I'm not convinced that this is correct and even if
it is , that it is because of the standard and not because the processors have
become more elaborate or because compilers have become better at doing
optimisations.

> I would certainly agree that the language described above could be improved
> by allowing programmers to waive aspects of those guarantees that they don't
> need.

If your suggestions would mean fewer opportunities for optimisations then I
would say that it is essential that the programmer has the ability to waive
the additional constraints.

> On the other hand, I would suggest that any language which wants to
> use the same name as the language that became popular in the 1980s should
> be capable of doing everything that could be done in that language.

I'm pretty sure it can and a lot more.

> Perhaps what's needed is a notation C[platform] to denote the language C
> augmented by the guarantees associated with a specified platform, in which
> case the freestanding language defined by Standard would be C[abstract
> machine unrelated to any practical hardware].

Who would define those C[platform] guarantees ? Surely not the C standard
committee because it would be impossible to do so. If you mean some external
group then there's nothing which prevents a group or individual to define an
extended C which in some way works better on some specific architecture. If
you have any specific ideas go ahead and write a document and put in online.
But otherwise many of your suggestions (not just in this post) are too vague.

-- 
Who watches the watchers ?
Who bakes the bakers ?
Who builds the builders ?
Who programs the programmers ?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 11:29 +0100
  Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 03:01 -0800
    Re: Equal yet different pointers "Bill Davy" <Bill@XchelSys.co.uk> - 2017-11-16 11:03 +0000
    Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 13:55 +0100
      Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 06:44 -0800
        Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 14:49 +0000
          Re: Equal yet different pointers Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-11-16 08:28 -0800
        Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 16:46 +0100
      Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:29 -0500
        Re: Equal yet different pointers Nick Bowler <nbowler@draconx.ca> - 2017-11-17 22:47 +0000
          Re: Equal yet different pointers Richard Damon <Richard@Damon-Family.org> - 2017-11-18 17:03 -0500
  Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 11:09 +0000
    Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 11:14 +0000
    Re: Equal yet different pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 03:41 -0800
      Rick's neuroses (Was: Equal yet different pointers) gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-16 12:11 +0000
        Re: Rick's neuroses (Was: Equal yet different pointers) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 04:30 -0800
          Re: Rick's neuroses (Was: Equal yet different pointers) David Brown <david.brown@hesbynett.no> - 2017-11-16 14:52 +0100
            Obscure references (Was: Rick's neuroses (Was: Equal yet different pointers)) gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-19 12:32 +0000
              Re: Obscure references Noob <root@127.0.0.1> - 2017-11-20 11:08 +0100
                Re: Obscure references David Brown <david.brown@hesbynett.no> - 2017-11-20 12:36 +0100
    Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 14:45 +0100
      Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 08:55 -0800
        Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 17:09 +0000
          Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 09:33 -0800
        Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-16 19:20 +0000
          Re: Equal yet different pointers Keith Thompson <kst-u@mib.org> - 2017-11-16 11:36 -0800
            Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 22:50 +0100
              Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 14:34 -0800
                Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 10:44 +0100
                Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-17 08:23 -0800
                Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 19:13 +0100
                Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-17 16:45 -0800
                Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-18 07:30 +0000
        Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 22:25 +0100
          Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-16 23:11 +0000
            Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 15:47 -0800
            Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 10:49 +0100
      Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-16 19:20 +0000
        Re: Equal yet different pointers "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-11-16 11:26 -0800
        Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-16 22:22 +0000
          Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:09 +0000
            Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-17 08:50 +0000
              Re: Equal yet different pointers Gareth Owen <gwowen@gmail.com> - 2017-11-17 17:42 +0000
                Re: Equal yet different pointers gazelle@shell.xmission.com (Kenny McCormack) - 2017-11-17 19:35 +0000
      Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:34 +0000
        Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 15:58 -0800
        Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-17 00:57 +0000
        Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 12:32 +0100
          Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-17 12:31 +0000
            Re: Equal yet different pointers mark.bluemel@gmail.com - 2017-11-17 07:23 -0800
            Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-17 17:14 +0100
              Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 00:12 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 13:39 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 01:39 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 14:42 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 02:01 +0000
                Re: Equal yet different pointers Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-18 02:07 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-18 15:35 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 11:23 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 12:02 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-18 23:25 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 13:44 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 01:05 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 14:30 +1300
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 01:48 +0000
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-19 16:21 +1300
                Re: Equal yet different pointers Reinhardt Behm <rbehm@hushmail.com> - 2017-11-19 11:44 +0800
                Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-19 10:10 +0000
                Re: Equal yet different pointers mark.bluemel@gmail.com - 2017-11-20 00:52 -0800
                Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-19 23:27 +0100
                Re: Equal yet different pointers Richard Damon <Richard@Damon-Family.org> - 2017-11-19 22:48 -0500
                Re: Equal yet different pointers Ian Collins <ian-news@hotmail.com> - 2017-11-20 16:52 +1300
    Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 14:28 +0000
      Re: Equal yet different pointers Barry Schwarz <schwarzb@dqel.com> - 2017-11-16 07:10 -0800
        Re: Equal yet different pointers David Brown <david.brown@hesbynett.no> - 2017-11-16 16:51 +0100
          Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:57 -0500
      Re: Equal yet different pointers supercat@casperkitty.com - 2017-11-16 08:03 -0800
      Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 12:38 -0500
        Re: Equal yet different pointers "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-16 20:13 +0100
          Re: Equal yet different pointers "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-16 14:29 -0500
    Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 15:57 +0000
      Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 16:07 +0000
        Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 19:01 +0000
          Re: Equal yet different pointers Spiros Bousbouras <spibou@gmail.com> - 2017-11-16 19:14 +0000
            Re: Equal yet different pointers Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-16 19:47 +0000
      Re: Equal yet different pointers bartc <bc@freeuk.com> - 2017-11-16 23:08 +0000
        Re: Equal yet different pointers Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-11-17 00:33 +0000

csiph-web