Programming

Originally Posted by garysk

As I pointed out in my reply to @jimmacnamara, there was no overflow. By means of logic that is not obvious to me, the compiler made certain decisions, which resulted in two things:

1. The data aligned, one comma-separated datum per named member of each instance of the structure within the array of structures. The values expected, except for the NULL-initialized char [5], appeared in their expected places in the array and within every element of the array. If they didn't align one to one, that would have been the time to break out the additional curly braces.

2. The "NULL" initializer of the member array was interpreted as a signal to initialize the member array with null bytes. Somehow, no doubt through application of fundamental rules of the language (which is what is not clear to me), the compiler made the decision to convert the *((void *)0) to (char)0, essentially converting a declared pointer into a declared integer.

To my knowledge there is not a simpler explanation of the decision (the need for that decision that I created by expecting the compiler to resolve ambiguous code notwithstanding) than to ascribe it to datatype promotion/demotion. Typically, though, the compiler balks at pointer-integer conversion, and I would have expected something like that here, rather than silently do as it thought I said.

I think there should have been a warning somewhere, or an error, applied to the construct by the compiler. But alas, none was indicated.

I am aware that the compiler "tries" to do what it asked to do, and to try to make things fit, but if it's not clear, I'd rather have errors and warnings out the kazoo than to have it guess as to what is intended. And I know that the compiler is neither intelligent nor animate, and can only obey the rules given; I am at this point really only interested in understanding the rules that came into play here.

Originally Posted by Don Cragun

I agree with what Jim McNamara has already said. I hope this may provide a little more that will help explain what you're seeing.

Depending on the programming environment you're using, NULL is likely to be defined to be 0, 0L, or (void *)0. (All three of these are used for one or more of the multiple programming environments provided by OS X and all three of these are legitimate values for NULL according to the C Standard depending on the relative sizes of pointers and integers in your programming environment.)

If NULL expands to 0 in your programming environment, there would be absolutely no difference to the compiler between the initializer:

Code:

NULL, '\0', '\0'

and the initializer:

Code:

'\0', '\0', '\0'

If NULL expands to 0 or 0L, no pointer to integer conversion is needed to turn NULL into an integer constant used to initialize the array of characters in your structure.

I agree that if your compilation environment has NULL defined to be (void *)0 it would have been nice for the compiler to produce a warning, but I don't see anything in the C Standard that would require that to happen since the conversion from a NULL pointer to an integer constant expression is a well defined operation with no loss of data involved.

Originally Posted by garysk

Thank you, Achenle, for reiterating this point. This point was made in the original post. Obviously, the constant address that is symbolized by the name of the member cannot be changed. The original questions were "why no objection from the compiler" and "where did the NULL go". The best answers seem to be that the NULL was interpreted at its most primitive, a zero, and used to fill the member array, and because this was a slam-dunk move on gcc's part, there was no need for it to object.

In a loop that uses tags_sn == NULL as its terminating condition, it fails to terminate and instead of course gets a segmentation violation and dumps core.

Originally Posted by achenle

You sure didn't seem to know it, else you never would have posted this:

Oiginally posted by garysk. In a loop that uses tags_sn == NULL as its terminating condition, it fails to terminate and instead of course gets a segmentation violation and dumps core.

Originally Posted by garysk

Don, a million thanks for your cogent reply.

'Pon our systems, NULL the pointer is defined as (void *)0. NUL the character is (char)0. This is why I have been saying, as you do below, it would be natural to expect a warning about the type coercion implied by my mistake.