Re: Non-null pointers in C/C++?

>> >So, there are no more questions about "unnullable"? If so, how can I
>>>propose the addition of unnullable to the C standard?
>>
>> I still claim that if there is no way to convert a nullable pointer
>> to an unnullable pointer (which includes a check for NULL and the
>> possibility of failure), you've missed about 99% of the problem
>> that unnullable pointers are supposed to solve (dealing with dynamic
>> memory allocation).
>
>How about this way (posted by me on this thread on June, 1st):
>
>void do_something()
>{
>        char* p = get_pointer_from_somewhere();
>
>        if (p == NULL)
>        {
>            // There's nothing to do with a null pointer here, so just 
>return
>            return;
>        }
>
>        unnullable char* r = (unnullable char*)p;
>        // Go ahead and work with r
>}

Ok, describe (preferably in standardese) under what cir***stances
the compiler *MUST* determine that p is not NULL at the declaration
of r.  If that one is too obvious, I can construct a maze of if and
switch statements that guarantee that p is not NULL when it arrives
at the declaration of r, but the compiler cannot prove that.

Also, the compiler needs to throw an error if the line "if (p ==
NULL)" gets changed to "if (q == NULL)" where q is declared elsewhere
but r is still initialized from p.

>> So far, I've seen mostly proposals to prohibit
>> trying to do such a conversion.
>>
>
>Why prohibiting such a conversion?!

Obviously you want to prohibit:
	unnullable char *r = NULL;
Some people apparently thought forcing a check was too messy, so
they want to prohibit converting from anything that *might* be null.
Some proposals wanted to only permit unnullable pointers to be
initialized from things that CANNOT be null (such as taking the
address of a variable).  That, IMHO, limits the use of it so much
that it's worthless.

You want to be able to take pointers from real-world functions that
can fail (e.g. malloc() and fopen()), *CHECK* them (no wimping out that
letting a null sneak in is "undefined behavior"), and then assign it to
an unnullable pointer.  Much of the problem of dereferencing NULL pointers
comes from the failure to include such checks.


>> Also, if you expect "unnullable" to do any good, it needs do***ented
>> behavior should a NULL manage to slip in where it's not wanted.
>
>Why do you expect that a NULL may slip in an unnullable pointer?! How do
you 
>image this happening? 

If you initialize an unnullable from the return value of a function
that can return NULL, and forget the NULL check, and don't mandate
that the compiler perform an actual check (not calling it "undefined
behavior"), a NULL could sneak in.  So you want to make sure that at
the time of the conversion, there IS such a check.  Preferably enforced
by syntax, so it won't even compile until you put in the check.

No existing code has unnullable pointers, so if you're modifying
the code to use them, it's easy to miss something.  That's a large
part of the reason for wanting them:  existing code tends to forget
the checks.  Also, there's the myth that "we've got plenty of memory,
malloc() will never fail".
-- 
comp.lang.c.moderated - moderation address: clcm@[EMAIL PROTECTED]
 -- you must
have an appropriate newsgroups line in your header for your mail to be
seen,
or the newsgroup name in square brackets in the subject line.  Sorry.