DM> Ah - you think of char[]'s as "strings".  The language does 
 DM> not - it sees char[] as "array of char," or, "array of 
 DM> signed byte."  (Here 'byte' is determined to be the 
 DM> smallest unit of memory that can hold the character set, 
 DM> or, a char.)  The fact that there is a convention of using 
 DM> nul-terminated blocks of characters as a "string" is 
 DM> immaterial.

   Well, I think of an array of char as a 'string' insofar as it is a 
   string (sequence) of bytes, as opposed to a NUL-terminated string, 
   which it may or may not be.  Along the same lines, I think of an 
   array of int (16 bits on my compiler) as a string of words, and an 
   array of long int as a string of dwords.  As for the array name, I 
   think of it as a const * to the base element of the array, as 
   opposed to the actual block of array data.
   
   The things that got me thinking that the NUL was always applied to 
   a char array when initialized with a string literal in double 
   quotes were that a) since (according to my compiler's 
   documentation) "C does not check array subscripts", and b) char 
   array[20]="whee"; will set the fifth byte of the array to NUL, it 
   was always done.  To have it done in an array of five elements or 
   more, but not in an array of four elements implies that the 
   compiler is checking the boundaries of the array, and that is 
   something that my manual said wasn't done in C. 
   
   I'll attribute it to documentation that was misleading, or at least 
   unclear.

 DM> The language, however, recognizing this popular convention, 
 DM> allows strings in quotes to be equivalent to an array of 
 DM> the same characters, with a nul terminator if there is room 
 DM> (*).  For example:

 DM> "hi" == {'h', 'i', '\0'}

 DM> (*) this only applies in an assignment.  There are more 
 DM> ways to use this convention, primarily, as a pointer to 
 DM> that data structure in memory.

 DM> Therefore, rather than writing the following code:

 DM> char hello_world[LEN] = { 
 DM> 'H', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd', '!', '\0'
 DM> };

 DM> we can write:

 DM> char hello_world[LEN] = "Hello world!";

 DM> Now, for some interesting bits... if we change the macro 
 DM> "LEN" above, we can get some interesting quirks.

 DM> 1. LEN < 12
 DM> Compilers should complain about excess elements in the array.
 DM> 2. LEN = 12
 DM> The former, having explicitly thirteen characters, 
 DM> has an excess element in the array.  The latter, having the 
 DM> nul only being implicit, does not have any excess character.
 DM> 3. LEN = 13
 DM> Both are fine, and have exactly the same data in them.
 DM> 4. LEN > 13
 DM> As with LEN = 13, both have the same data in them.  However,
 DM> every  item of the array, as is mandated by the standard, is then 
 DM> "assigned" the properly-cast value of zero.  For char's, 
 DM> this means the nul character, although for pointers (an 
 DM> array of pointers, for instance), this is the NULL value 
 DM> (which may or may not have the bit value of all zero bits, 
 DM> but is always equal to the constant zero when cast).
 
   This latter point, about the elements of arrays being set to zero, 
   was another thing I hadn't heard of before.  As I understood it, C 
   doesn't initialize a local variable when declared, unless it is
   explicitly initialized at the same time, or in the case of an 
   array, implicitly initialized by being assigned a const * to the 
   area of memory where the area data resides.
   
   For example, int grok; will allocate storage for an int, but not 
   initialize it.  Int grok=0; will allocate space for and initialize 
   the variable.  I thought that any elements of an array that were 
   not explicitly initialized held whatever values they happened to 
   contain- ie, a char array of 20 elements, assigned the string 
   literal "hello world" would contain NUL as the twelfth element, and 
   everything after would be garbage.
   
   As for pointers, I never rely on them having _any_ particular value 
   (NULL included!) unless I've explicitly set that value myself.  Are 
   you saying that if I have a line like char *whee[10]; that all ten 
   pointers will be NULL pointers before a call to malloc() or some 
   such?
 
 RS>    Hmm, slick.  I didn't know that.  I s'pose it's handy if you want 
 RS>    to initialize char arrays that aren't to be used as strings, or if 

 DM> This is its primary purpose...
 
 RS>    you have fixed-length fields that you'll use in routines like 
 RS>    strncpy() and printf("%2s",array).  I learn new things
in this echo 
 RS>    all the time.  :)

 DM> That's what it's here for, isn't it?  :-)
 
   Yup. :>
 
 DM> Nope - a good compiler should say nothing.
 RS>  
 RS>    Hmm.  I bet my compiler issues a warning.  

 DM> Have you tried it?
 
   Tried my compiler?  Yes, I use it frequently.  Tried to see if it 
   issues a warning in this context?  Not yet.  I was merely surmising 
   that, given my history with the compiler, it might well 'goof up' 
   here.  This is the compiler (Microsoft QuickC v2.5) that has 
   unclear or erroneous documentation, if what you've posted here is 
   correct.  It's also the compiler that inexplicibly changed compiler 
   options in the integrated environment on me.  It's highly unlikely 
   that it was an error on my part- I'd have had to activate a drop 
   down menu, choose the appropriate selection in a dialog box, tab my 
   way over to another field in a second dialog box, and change a 
   setting there- rather hard to do by accident.  That compiler switch 
   was one that flagged all functions and macros that weren't ANSI 
   compliant with warning messages, and it was doing more than that- 
   it was givingme 'unresolved external' errors for inline assembly.  
   It took me a while to track down what the hell was causing the 
   problem.
   
   In case you're wondering why I bother to keep using it, it's 
   because a) it was free for me, b) I have all the manuals and 
   original disks, and c) I'm too lazy/cheap to acquire another.  :/

... "It compiled?  The first screen came up?  Ship it!" -Bill Gates
___ Blue Wave/DOS v2.30 [NR]

--- Maximus 2.01wb