X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Date: Tue, 6 Aug 2013 09:09:35 -0400
Message-Id: <201308061309.r76D9ZUQ005211@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp AT delorie DOT com
In-reply-to: <op.w1d7ry2o0e5s1z@-> (dont_use_email@nohavenotit.com)
Subject: Re: _CRT0_FLAG_NULLOK
References: <21e77579-1a40-4442-8111-fc976fba78fc AT googlegroups DOT com>
 <b5o37qFldl9U1 AT mid DOT dfncis DOT de>
 <f24e8cd3-83ca-4386-a319-a9adb4d74c68 AT googlegroups DOT com>
 <3df2f50f-9543-47a7-8e40-a9be82ce5018 AT googlegroups DOT com>
 <87fvuvny2v DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp> <op.w020sren0e5s1z@->
 <87ehaeonbp DOT fsf AT uwakimon DOT sk DOT tsukuba DOT ac DOT jp> <op.w04oetou0e5s1z@->
 <201308011247 DOT r71ClEhM008182 AT delorie DOT com> <op.w08sn91j0e5s1z@->
 <201308031802 DOT r73I2NAq010284 AT delorie DOT com> <op.w1d7ry2o0e5s1z@->
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> > NULL's actual value is required to be zero, from the program's point
> > of view.
> 
> If it's from the program's point of view, then it's not it's actual
> value.  It's its semantic representation.

Now you're being overly pedantic.  NULL is zero, the standard says so.
How that relates to hardware is irrelevent, as it should never be
dereferenced.

> The point is on *any* memory system  The actual value used for
> NULL needn't be zero.

No, the standard says the actual value used for NULL needs to be zero.

> So, I take it you also disagree with the C compiler automatically
> initializing unitialized variables.

The standard says that they're initialized, so I agree with the
compiler initializing them.

> I'll also take it you dislike 'void' and 'void*' since those also
> prevent users from coding making certain coding mistakes with pointers.

I like void because it prevents certain coding mistakes.

> I.e., I don't see why you'd like the just mentioned "safety"
> features of C, but you wouldn't like another change that would
> prevent similar novice style coding mistakes...

Defererencing NULL is something the standard says you *shouldn't* do,
so I like making sure you *shouldn't* do it.

> > IMHO if a pointer points to *anything* that "works", it's
> > a bad choice for NULL.
> 
> Even if NULL still functions correctly as NULL?

Sure.  NULL is a pointer that doesn't point to anything.  I like
systems that make sure it *really* doesn't point to anything.

> NULL can still be compared to.

That's its purpose.

>  It just now functions as an empty string for functions expecting
> strings,

This is a bad idea.

> if they don't explicitly check for NULL.

If they don't check, either they're broken, the function was called
wrong, or the program crashes.

If the program is broken, it should break *hard* so you can (1) tell
that it's broken, and (2) fix it easily.