🚀 go-pugleaf

kanze@gabi-soft.fr (J. Kanze) wrote:

>The error may be historically conditioned.  As I interpret the C
>standard, an enumerated constant has type int, and a constant integral
>expression which evalutates to 0 is a null pointer.  Even in the ARM,
>however, ``An enumeration is a distinct integral type.''

That begs the question, however, whether being an integral type with
constant value zero is sufficient to allow assignment to a pointer.
Let me illustrate:

    void *p = 0;

This is definately legal. The pointer can be initialized or assigned
from the literal.

    const int nil1 = 0;
    void *p = nil1;

    const unsigned char nil2 = 0;
    p = nil2;

Is this legal? I believe all of the above is legal, though IMO it
shouldn't be (see below)

    enum ptrNil { nil3 };
    void *p = nil3;

You are claiming that this is not legal because nil3 is of type ptrNil
which is not compatable with the type of p. However, I fail to see how
nil3 is different from nil1 and nil2 in this respect. All are `integral'
types with value zero.

I agree that the assignment of nil3 to p *should not* be legal because
nil3 is not a pointer type. But by the same logic, neither should the
assignments to nil1 and nil2 be legal. IMO it would be simplest to
disallow implicit conversion from any integral type to a pointer type
*except* in the case of literal zero. I don't think adding this
prohibition would break much code. <stdlib> defines NULL as

   #define NULL 0

so any code that uses NULL or 0 for the null pointer would still work.
Perhaps to cover most of the rest of the cases we could add the rule
that any constant expression with value `(void *) 0' can be converted to
any pointer type without a cast. This would allow nice constructions
like:

   void *const nil = 0;

In summary, I think that using a zero enumeration as a null pointer *is*
currently legal, but shouldn't be.

-------------------------------------------------------------
Pablo Halpern                   phalpern@truffle.ultranet.com

I am self-employed. Therefore, my opinions *do* represent 
those of my employer.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]