Initializing arrays of char

Steve Summit scs at adam.mit.edu
Tue Oct 16 11:33:49 AEST 1990


In article <1017 at gistdev.gist.com> flint at gistdev.gist.com (Flint Pellett) writes:
>IMHO the committee blew it: their decision lets a programmer who will
>only use a string in a non-null terminated manner (like with strncpy)
>save 1 lousy byte, and opens the door for a ton of mistakes to get through.

Anyone who wants character arrays initialized with "regular"
strings should always be using

	char a[] = "hello";

Both

	char a[6] = "hello";
and
	char a[5] = "hello";

are risky, and both "open the door for a ton of mistakes to get
through."  Neither should be used in the normal case, but in the
abnormal case, when you've taken character counting upon yourself
for whatever reason and are prepared to live with the
consequences, either seems appropriate (depending, of course, on
your needs, which should be well documented and understood).

If anything, I'd say that non-nul-terminated strings are a bit
closer to the elusive "spirit of C."  The fact that the compiler
politely appends \0 has always seemed microscopically odd to me,
since nothing in the language proper assumes or depends on it.
(Yes, the standard libraries are now essentially part of the
"language proper;" so this statement is less true today.)  To be
sure, having the compiler append \0 is monumentally handy, and
I'm not saying that it shouldn't, but since when has the C
compiler held your hand?

(I'm actually not being terribly sarcastic here, but please don't
flame this opinion, in either direction, if you disagree -- it's
not a major point.)

Given that the implicit appending of \0 is a little bit "out of
band," I am pleased that there is a way for the programmer who
needs to to explicitly disable it.  This seems very much in the
spirit of C (and Unix).  (Granted, counting characters is
upsetting.  See Karl Heuer's recent post for an alternative
mechanism, which happened not to be adopted by the committee.)

>Here is a real life example of the impact of this decision: for
>about a week we had a 3B2 machine which kept crashing about once an
>hour because of this!
>1. It always crashed because it ran out of swap space.
>2. It was incorrectly set up so that one user could use up all the swap.
>3. One particular program was always running when it crashed.
[the program contained an inadvertent non-nul-terminated string
due to the above mechanism which turned into]
>an infinite loop chasing it's own tail.

Sorry to be unsympathetic, but if a system can be brought to its
knees by a user program grabbing all available swap space and/or
cpu cycles, then that's the bug, pure and simple.

Should "features" such as

	while(1);				/* don't try */
or
	while(malloc(1) != NULL);		/* these at */
or
	while(fork() >= 0);			/* home, kids */

be disallowed for the same reason?

                                            Steve Summit
                                            scs at adam.mit.edu



More information about the Comp.lang.c mailing list