Re: I need a new compiler...

Paul wrote:
On 2008-12-15 10:32:41 -0600, Michael Wojcik <mwojcik@xxxxxxxxxxx> said:
PR wrote:
On Dec 12, 11:29 am, Michael Wojcik <mwoj...@xxxxxxxxxxx> wrote:
No, it doesn't. Some C implementations may extend the language to
provide direct access to memory and devices (whatever that may mean on
the platform), but that's not part of the C language.

Actually, yes it it.

No, it is not. I suggest you read ISO 9899-1999 (plus Technical
Corregida), which is the definition of the C language. You will find
that it does not require implementations to "provide low-level
system/memory/device access", and indeed does not define any language
constructs which remotely resemble anything such "access" might include.

Oh yes, it is. Pointers, and address and indireciton operators were
ratified with C89, and are maintained through all current implementations.

And no part of the standard requires that pointers or the address or
indirection operators provide access to system memory. Feel free to
cite c&v if you believe otherwise.

Access to memory is always defined in C, as
pointers are intrinsic.

C pointers do not need to provide access, "low-level" or otherwise, to
physical memory or devices. They need to support the dereference
operator, and so could be considered as providing access to "memory"
in the sense of the abstract machine, but there is *absolutely no
requirement* that such access have any particular relationship to the
hardware.

No, they are address operators, similar to and interchangable with the &
operator.

Pointers are not "address operators" in any way, shape, or form. There
is one address operator (&), and there are various cases where other
constructs decay to addresses.

But, once more, those addresses are purely defined in terms of the
virtual machine and do not have any required correspondence with the
physical machine.

ISO 9899-1999 5.1.2.3 #1: "The semantic descriptions in this
International Standard describe the behavior of an
abstract machine in which issues of optimization are irrelevant."

There is very much an absolute requirement that they do.

Care to show us where in ISO 9899 that requirement appears?

You are arguing C++, which is a totally different animal indeed.

I most certainly am not. ISO 9899 is the C specification.

And pointers are not special variable types,

Indeed. They have pointer type, which is not "special" (whatever that
might mean). But it's not any other kind of type, either.

Pointers are address operators, always.

Pointers are not operators in C, so your claim is invalid by definition.

If you don't know what
"special" means in terms of language and compile construction, then look
it up. The usage of the term is both precise and accurate.

Complete rot. "Special type" has no single special meaning as a term
of art in computation theory or compiler design. The references I have
to hand use it in a variety of ways, or not at all.

Originally, yes. As the language is currently defined, no. Type
punning between pointers and integers invokes Undefined Behavior. That
it works in some implementations is beside the point.

It invokes a warning at compile time that you did something without a
cast.

You really can't be bothered to check, can you?

6.3.2.3 #5: "An integer may be converted to any pointer type. Except
as previously specified, the result is implementation-defined, might
not be correctly aligned, might not point to an entity of the
referenced type, and might be a trap representation."

And since this conversion is not a constraint violation, conforming
implementations are not required to issue a diagnostic, so you're
wrong on that count, too.

You can certainly cast an address to an integer.

I never claimed otherwise.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
.

Relevant Pages

  • Re: size of a sizeof(pointer)
    ... Few things are crystal-clear in English etymology. ... ("few C implementations provide safe pointers"), ... But the language does not *depend* on this trade-off, ...
    (comp.lang.c)
  • Re: Dynamic memory allocation stack heaps
    ... from assembly language to C.(predominantly communication protocol ... Since in microcontrollers/processors memory is considered valuable, ... But you have to realise that different implementations ... when moving from one language to another ...
    (comp.lang.c)
  • Re: malloc() vs mmap()
    ... actually C++ implementations have to. ... implementations are using memory. ... And Java is more than just the language. ... standard libraries, does not use memory: ...
    (comp.unix.programmer)
  • Re: new here, my lang project...
    ... I feel general, as I am unsure, eg, how a language like c would map to ... on the way structs are layed out in memory, the way pointers are ... such a vm will typically manage it's own memory, ... one can't put any more data in a struct, doing so would break the app. ...
    (comp.object)
  • OT: concrete and clay WAS: Re: I need a new compiler...
    ... which is the definition of the C language. ... find that it does not require implementations to "provide ... indirection operators provide access to system memory. ... Pointers in C very much are address operators, in every way, shape, ...
    (comp.lang.cobol)