"Gordon Burditt" <gordonb.ll93b@[EMAIL PROTECTED]
> wrote in message
news:clcm-20080523-0005@[EMAIL PROTECTED]
>>> and what happens if a null pointer gets passed as an argument to a
>>> non-null pointer parameter?
>>
>>It's undefined behaviour, but the compiler may be able to detect it and
>>issue a diagnostic.
>
> In that case, I think you just threw all the "safety" arguments out
> the window. If you're going to claim "safety" benefits, the compiler
> needs to *CHECK*. Of course, the issue is still there about what
> to do when the check fails.
Not *all* the safety arguments, just some of them. Just because the
behaviour is officially undefined doesn't mean that a good compiler can't
insert opcodes to check for null and abort the program with an error
message -- or, even better, have a switch to let you choose whether you
want
the check or not.
I wouldn't expect this new feature to add more safety (or more syntactic
complexity) to C than adding the "const" qualifier once did. Despite the
fact that C doesn't make it impossible to attempt to modify a
const-qualified object by casting away the constness of a pointer, I don't
think anybody would claim that "const" has absolutely no safety benefits.
> In order to be useful, there has to be a way to convert a plain,
> old, ordinary, unsafe pointer to a non-null pointer, provided, of
> course that it p***** the check.
There's a difference between "useful" and "perfectly safe". A feature
that
makes programming a little safer can be useful, even if it doesn't make it
perfectly safe.
> Here's a suggestion, but I'm sure
> someone will think the syntax is horrible. ifnotnull is not a
> function, it's a syntax construct, sorta like if. The assignment
> in ifnotnull(nnp = np) is only done if the value is not null.
Indeed, it does look pretty horrible. But what feels worse to me is that
if
you decide to go in that direction, you should also invent non-zeroable
arithmetic types and similar syntax to protect division, and of course a
non-indeterminate qualifier that could apply to any type to indicate that
an
object cannot possibly contain an indeterminate value (and therefore, for
instance, must be initialized if it's automatic). Good luck with that.
....
>>And in a debug mode, it could also insert opcodes to
>>test for null at runtime.
>
> I'll even go so far as to say that in debug mode, it would be a
> good idea that converting *one* dangerous pointer to a not-null
> pointer should, ideally, involve checking *all* not-null pointers
> for being not null, to the extent possible. This would at least
> include all of the not-null pointers with declarations in scope.
The C standard has no concept of "debug mode". Any debug facilities are a
quality-of-implementation issue.
> Should we also forbid uninitialized not-null pointers?
Exactly, and what about pointers that point to an object that has gone out
of scope?
What about pointers inside a union?
My vote: if you're looking for a language with absolute safety, C is one
of
the worst possible choices. It will never make it impossible for you to
shoot youself in the foot if you try; the best that can be done is to make
it more helpful in avoiding shooting yourself by accident.
--
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.
|
