«

Which C libraries (current and historical) interpret a null pointer as
a pointer to a null (that is, empty) string?

Dennis Allison wrote:

> Which C libraries (current and historical) interpret a null pointer as
> a pointer to a null (that is, empty) string?

There was at least one implementation (pre C-89), which
took great pains into putting 0x0 at location zero
in the data segment.

Thus, the NULL pointer (on that implemenation a zero)
would always point to a location with the contents '\0'
for a char *, and all zero bits for other pointers to
that location.

Needless to say, things broke in myriad ways when
code was ported to another implementation.

--
Ñ
"It is impossible to make anything foolproof because fools are so
ingenious" - A. Bloch

On Fri, 05 Mar 2004 19:13:35 GMT, Nick Landsberg <>
wrote:

>
>
>Dennis Allison wrote:
>
>> Which C libraries (current and historical) interpret a null pointer as
>> a pointer to a null (that is, empty) string?
>
>There was at least one implementation (pre C-89), which
>took great pains into putting 0x0 at location zero
>in the data segment.
>
>Thus, the NULL pointer (on that implemenation a zero)
>would always point to a location with the contents '\0'
>for a char *, and all zero bits for other pointers to
>that location.
>
>Needless to say, things broke in myriad ways when
>code was ported to another implementation.

And even /that/ is more to the tune of "the platform tries to minimize the
potential damage in the case when a C program (user code or lib function)
mistakenly treats a null pointer as if it were a valid pointer to
something".

I get the feeling the OP was asking if there are/were any string-handling
libraries that always check for a special-case of 0 when handed a char *,
and do some reasonable thing in that case.

I don't know, but if there were then that would have to be considered some
sort of non-standard extension, and it might even be offensive to folks
using the string lib functions because it implies extra special-case
overhead that proper use of those pointers would have rendered unnecessary.

Anyway, as a postscript to Nick's remarks, I'm compelled to give out kudos
to the early MSVC team for establishing what I think was an excellent
little "hack" in their runtime system in debug mode: They place a magic
value at location zero, and after program execution check to see if it has
changed. If so, a nice diagnostic ("NULL pointer assignment...") is
emitted. This has probably saved me countless hours of head-scratching over
runtime meltdowns...
-leor

Leor Zolman
BD Software

www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

Leor Zolman <> writes:

> Anyway, as a postscript to Nick's remarks, I'm compelled to give out kudos
> to the early MSVC team for establishing what I think was an excellent
> little "hack" in their runtime system in debug mode: They place a magic
> value at location zero, and after program execution check to see if it has
> changed. If so, a nice diagnostic ("NULL pointer assignment...") is
> emitted. This has probably saved me countless hours of head-scratching over
> runtime meltdowns...

This has a much older history than MSVC. It was definitely in
even fairly early versions of Turbo C for DOS, and I don't
remember any claims that they invented the idea.
--
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

On Fri, 05 Mar 2004 12:14:06 -0800, Ben Pfaff <> wrote:

>Leor Zolman <> writes:
>
>> Anyway, as a postscript to Nick's remarks, I'm compelled to give out kudos
>> to the early MSVC team for establishing what I think was an excellent
>> little "hack" in their runtime system in debug mode: They place a magic
>> value at location zero, and after program execution check to see if it has
>> changed. If so, a nice diagnostic ("NULL pointer assignment...") is
>> emitted. This has probably saved me countless hours of head-scratching over
>> runtime meltdowns...
>
>This has a much older history than MSVC. It was definitely in
>even fairly early versions of Turbo C for DOS, and I don't
>remember any claims that they invented the idea.

I didn't mean to imply they invented it, or even claimed they did. I'm just
happy the have it. Perhaps they're even due a few kudos just for being
willing to implement it even though they didn't "have" to, and/or in spite
of the fact someone might have chosen to come along and use it against them
(you know, MS-as-thief-of-other-people's-good-ideas and all that...)
-leor


Leor Zolman
BD Software

www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

Leor Zolman wrote:
>
.... snip ...
>
> I get the feeling the OP was asking if there are/were any string-
> handling libraries that always check for a special-case of 0 when
> handed a char *, and do some reasonable thing in that case.
>
> I don't know, but if there were then that would have to be
> considered some sort of non-standard extension, and it might even
> be offensive to folks using the string lib functions because it
> implies extra special-case overhead that proper use of those
> pointers would have rendered unnecessary.

My implementations of strlcat and strlcpy (available on my site)
do just that, and have drawn criticism for it. Thus "strlcpy(s,
NULL, size);" will create an empty string in s. My attitude is to
avoid crashes whenever I can give a NULL argument a reasonable
interpretation.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

CBFalconer <> spoke thus:

> My implementations of strlcat and strlcpy (available on my site)
> do just that, and have drawn criticism for it. Thus "strlcpy(s,
> NULL, size);" will create an empty string in s. My attitude is to
> avoid crashes whenever I can give a NULL argument a reasonable
> interpretation.

I'm not sure why you'd get criciticism - it sounds like very
convenient behavior to me. Oh wait, that's why you're getting
criticism

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

On Fri, 05 Mar 2004 21:51:28 GMT, CBFalconer <> wrote:

>Leor Zolman wrote:
>>
>... snip ...
>>
>> I get the feeling the OP was asking if there are/were any string-
>> handling libraries that always check for a special-case of 0 when
>> handed a char *, and do some reasonable thing in that case.
>>
>> I don't know, but if there were then that would have to be
>> considered some sort of non-standard extension, and it might even
>> be offensive to folks using the string lib functions because it
>> implies extra special-case overhead that proper use of those
>> pointers would have rendered unnecessary.
>
>My implementations of strlcat and strlcpy (available on my site)
>do just that, and have drawn criticism for it. Thus "strlcpy(s,
>NULL, size);" will create an empty string in s. My attitude is to
>avoid crashes whenever I can give a NULL argument a reasonable
>interpretation.

That's the power -- both beautiful and terrible -- of separation between
language and library...anyone can choose to use the standard string
functions or to use yours...or even (saints have mercy) put the standard
names on your implementations and sneak them into the library
-leor

Leor Zolman
BD Software

www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

On Fri, 05 Mar 2004 19:41:55 GMT, Leor Zolman <> wrote
in comp.lang.c:

> On Fri, 05 Mar 2004 19:13:35 GMT, Nick Landsberg <>
> wrote:
>
> >
> >
> >Dennis Allison wrote:
> >
> >> Which C libraries (current and historical) interpret a null pointer as
> >> a pointer to a null (that is, empty) string?
> >
> >There was at least one implementation (pre C-89), which
> >took great pains into putting 0x0 at location zero
> >in the data segment.
> >
> >Thus, the NULL pointer (on that implemenation a zero)
> >would always point to a location with the contents '\0'
> >for a char *, and all zero bits for other pointers to
> >that location.
> >
> >Needless to say, things broke in myriad ways when
> >code was ported to another implementation.
>
> And even /that/ is more to the tune of "the platform tries to minimize the
> potential damage in the case when a C program (user code or lib function)
> mistakenly treats a null pointer as if it were a valid pointer to
> something".
>
> I get the feeling the OP was asking if there are/were any string-handling
> libraries that always check for a special-case of 0 when handed a char *,
> and do some reasonable thing in that case.
>
> I don't know, but if there were then that would have to be considered some
> sort of non-standard extension, and it might even be offensive to folks
> using the string lib functions because it implies extra special-case
> overhead that proper use of those pointers would have rendered unnecessary.

Nothing non-standard about it at all. The standard no longer applies
once a program invokes undefined behavior, and passing a null pointer
to any standard library function that does not specifically state that
it accepts them (such as realloc(), free(), strto*()) is specifically
undefined behavior.

Some programmers might prefer a guaranteed unmistakeable crash to
bring a coding defect to their attention, but an implementation that
does this is no more or less than conforming than one that treats a
null pointer as pointing to a '\0' character.

At most it's a QOI issue.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

On Fri, 05 Mar 2004 19:13:35 GMT, Nick Landsberg
<> wrote:

>Dennis Allison wrote:
>
>> Which C libraries (current and historical) interpret a null pointer as
>> a pointer to a null (that is, empty) string?
>
>There was at least one implementation (pre C-89), which
>took great pains into putting 0x0 at location zero
>in the data segment.

VAX/VMS C still did this in the late 80's, IIRC.

>Thus, the NULL pointer (on that implemenation a zero)
>would always point to a location with the contents '\0'
>for a char *, and all zero bits for other pointers to
>that location.
>
>Needless to say, things broke in myriad ways when
>code was ported to another implementation.

Porting others' VAX C code to Unix and OSF/1 was a real pain.

--
Sev