Path: utzoo!attcan!uunet!gistdev!flint
From: flint@gistdev.gist.com (Flint Pellett)
Newsgroups: comp.lang.c
Subject: Re: Initializing arrays of char
Message-ID: <1020@gistdev.gist.com>
Date: 22 Oct 90 18:32:57 GMT
References: <1990Oct4.152756.6850@micrognosis.co.uk> <15674@csli.Stanford.EDU> <26860@mimsy.umd.edu> <1017@gistdev.gist.com> <1990Oct16.013349.1023@athena.mit.edu>
Organization: Global Information Systems Technology Inc., Savoy, IL
Lines: 34

scs@adam.mit.edu (Steve Summit) writes:

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

You won't get any argument from me on that: you're right.  (The
configuration in which this occurred happened to be the default
unmodified configuration right from the vendor: after it happened
I told them the same thing you just said, but not as politely.)

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

Obviously not.  They are different from the thing being discussed,
because in the above, everything that is happening is EXPLICIT.
That's my whole argument, that I dislike to see things happening
IMPLICITLY, or inconsistently, which is clearly what is going on when 
char a[2] = "a"; does add a '\0' and char a[2] = "ab"; does not.
That's why I like Karl's idea of adding the \c : because it makes
everything that is happening very explicit, so you don't miss it.

Have we beaten this to death yet?
-- 
Flint Pellett, Global Information Systems Technology, Inc.
1800 Woodfield Drive, Savoy, IL  61874     (217) 352-1165
uunet!gistdev!flint or flint@gistdev.gist.com