Thread: While loop not looping

Originally Posted by stahta01

@smokeyangel: Your quote does NOT agree with your conclusion.

Would you agree that the first quote does though? That's not in the 'implementation defined' section.

Originally Posted by smokeyangel

A.6.3 Implementation-defined behavior

Each implementation shall document its behavior in each of the areas listed in this section. The following are implementation-defined:
...
* The null pointer constant to which the macro NULL expands (4.1.5).

Well, we have in a not-implementation-defined part of the standard that the null pointer constant is 0. So I read it to mean that NULL can be defined to be different things within that rule, like 0 or (void*)0, GCC's magic __null.... so long as it gives a null pointer when cast to a pointer type.
I'm sure that plain (void*)0 is always the null pointer - even though this quote seems to give the implementation freedom to do what it likes with NULL, I think it'd still have to handle "0" in code correctly as NULL, changing it into whatever underlying value is needed.

That's just my reasoning based on what I think the standard means -- I don't actually know how this works.

Originally Posted by laserlight

Tsk, tsk, I always check which forum I'm on so I can refer to the relevant document
Unfortunately, I don't have a copy of C11, so I still refer to C99.


The paragraph 3 refers to a note 55:

The relevant part of 7.17:

So, NULL is implementation defined within the constraints of "an integer constant expression with the value 0, or such an expression cast to type void *".

Suppose NULL is "an integer constant expression with the value 0". An expression with the value 0 is equal to 0, hence NULL would be equal to 0.

Suppose NULL is "an integer constant expression with the value 0 (...) cast to type void*". NULL would already be cast to a pointer type, 0 is a null pointer constant which would be converted to void* in the comparison, and "any two null pointers shall compare equal", hence NULL would be equal to 0.

Since NULL would be equal to 0 under an exhaustive listing of cases, NULL must be equal to 0.

So that would mean that it is impossible to write a standard compliant compiler for the Symbolics Lisp Machine?

"The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair <NIL, 0> (basically a nonexistent <object, offset> handle) as a C null pointer."

Originally Posted by Jimmy

So that would mean that it is impossible to write a standard compliant compiler for the Symbolics Lisp Machine?

"The Symbolics Lisp Machine, a tagged architecture, does not even have conventional numeric pointers; it uses the pair <NIL, 0> (basically a nonexistent <object, offset> handle) as a C null pointer."

Quite possibly impossible, but I don't think the null pointer would be the problem.

Suppose I just invented a machine where the null pointer is 0x1000. That is:

If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

Meaning 0x1000 can't ever point to an object/function. I can't put anything in the memory there, it's not allowed by my architecture. So I then write some normal C, checking the return of malloc:

Code:

   int * p = malloc(sizeof(int));
   if (!p) 
       return 1;

The !p is really

Code:

  if (p == 0)

The 0 here is (by context) the null pointer constant, rather than the value 0.

Let's say malloc failed. p will be the null pointer, 0x1000. 0 or "NULL" will compare equal with 0x1000 -- because the null pointer constant is used to get the actual null pointer.
As said on C FAQ, this is compile time magic: the compiled code doesn't have any concept of NULL being 0.

I know nothing about the Symbolics Lisp Machine -- but

pair <NIL, 0> (basically a nonexistent <object, offset> handle)

even if I wanted to, how would I write that in C? Perhaps some sort of struct? But then that doesn't help because I have to have a pointer pointing to this struct, which is illegal for null pointers. So.... the syntax is "0". It maps to something interesting and machine specific.


In general though I don't see how you could have a complaint C implementation with non-numeric pointers (in the non NULL case). The standard is suitable lax:

Originally Posted by standard

6.3.2.3 Pointers

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.

6 Any pointer type may be converted to an integer type. Except as previously specified, the
result is implementation-defined. If the result cannot be represented in the integer type,
the behavior is undefined

That seems to say you can get away with it, with any attempts to convert to a numeric value being implementation defined to fail somehow. I'd be more concerned about pointer arithmetic, which is described without any leeway that I can see for non-numeric pointers.

It's hard to say what a truly standard compliant compiler is anyway. The standards (C and C++) are unclear and ambiguous in places (I don't mean implementation defined behaviour - I mean ill-defined behaviour!), and often different compilers go different ways on these parts. Some compilers (more C++ than C) openly support only a subset of the standard. I've no idea what that compiler claimed to support, but I doubt it was intended to be fully compliant.