interpreting a null pointer as an empty (null string)

[Dennis Allison]

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

 

[Nick Landsberg]

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.

 

[Leor Zolman]

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
(e-mail address removed)
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

 

[Ben Pfaff]

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.

 

[Leor Zolman]

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
(e-mail address removed)
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

 

[CBFalconer]

.... 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.

 

[Christopher Benson-Manica]

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

 

[Leor Zolman]

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
(e-mail address removed)
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

 

[Jack Klein]

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.

 

[Severian]

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.

 

[J. J. Farrell]

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...

It's a barely useful hack if you're forced to use some minimal
functionality operating environment, and it was established
before MSVC was dreamt of. Many implementations before and after
that just protect a page at 0 so you get a memory access exception
when you try to access it. I'd rather be dropped into a debugger
or given a core file that shows me exactly which piece of code
attempted the access than given a message that says "some piece
of code that you executed in the last few minutes wrote to 0".

 

[Derk Gwen]

# > 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

Most unices nowadays leave page zero unmapped, so that as soon as you
load or store null, you get an error, rather than waiting some time
later.