Stefan Teleman writes:
> > Actually, no, it's not. You know its apparent location in the stdout
> > character stream, but nothing about where the problem might be in the
> > code.
>
> In other words, the fact that i see "(null)" instead of some other printable
> value, printed out, provides me with absolutely no indication as to which
> char*
> pointer was NULL, in the sequence of arguments passed to printf(3C) and
> friends.
In many cases, it doesn't tell you which executable was involved, or
which loadable module in that executable, or anything about the
conditions that caused the problem.
> Speaking only for myself: when i see the string "(null)" printed out, when in
> fact i was expecting "Giraffe", i do not think "Oh, the stdout character
> stream
> contains the string \"(null\"). How odd. I wonder what could have caused
> this.".
>
> I think "Why is Giraffe NULL, when it shouldn't be ?".
I suspect that's because you may be the developer of that software,
and thus know the locations and contents of the printf() strings
themselves.
Try it as a user:
Installing software modules.
Unable to load module (null).
Operation complete; 327 modules loaded.
Does that tell you anything useful? What executable failed? Was it a
library function or the main program? Could it have been one of the
modules that was (apparently) being loaded by way of dlopen?
It may as well have said "somthing bad happened."
Glenn Fowler writes:
> On Wed, 25 Jun 2008 12:30:24 -0400 James Carlson wrote:
> > I think what's missing there is that this is (unfortunately) not just
> > a minority of developers. The bulk of user-space software looks like
> > this these days. People are just plain careless, ...
>
> this is a bit harsh
> people tend to code to what their local system tolerates
I've thought about it a bit, and I'm going to stand by it. Even if
your system 'tolerates' something as an implementation artifact, that
doesn't make it right.
In order for this to be something other than simple carelessness, I
think the developer would have had to have seen that "(null)" output,
and decided, "eh, that's good enough." If that's what happened, then
what I wrote isn't probably harsh enough.
> e.g., glibc implements posix
> well, yes, it might, but it also makes choices on some implementation defined
> behavior
> that could be mistaken for standard behavior, sometimes even after
> meticulous reading of the standard
Regardless of whether glibc implements POSIX, I don't think that
ignoring bad pointers is good programming practice. Perhaps it's just
my opinion alone, but I think failing to consider whether a pointer
ought to be NULL and doing something about it reflects a lack of due
care.
Sure; that can affect anyone. If you find it in my code, feel free to
point the example out as an instance of carelessness on my part.
(I'm not seeking a Gary Hart moment here, but rather saying that I
don't think the criticism is unfair.)
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
