Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!bloom-beacon!daemon From: scs@adam.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: Initializing arrays of char Message-ID: <1990Oct16.013349.1023@athena.mit.edu> Date: 16 Oct 90 01:33:49 GMT References: <1990Oct4.152756.6850@micrognosis.co.uk> <15674@csli.Stanford.EDU> <26860@mimsy.umd.edu> <1017@gistdev.gist.com> Sender: daemon@athena.mit.edu (Mr Background) Reply-To: scs@adam.mit.edu (Steve Summit) Organization: Thermal Technologies, Inc. Lines: 70 In article <1017@gistdev.gist.com> flint@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@adam.mit.edu