C mystery?

[Baker]

[Baker]

[Spike]

yes there's a difference.

to read a single word in pseudo asm:
pointer:
mov [&ptr] -> reg
mov [reg+offset] -> result

array:
mov [&arr+offset] -> result

square brackets denote a memory reference.

While the syntax is mostly the same, they are not identical at a hardware level. 'const' doesn't really mean anything, other than as purely a hint (which can be used for optimisations and generating warnings/errors).

You can always define eg:
extern char foo[];
that would be valid, due to the extern not requiring size info, but beware that it breaks sizeof in any file where foo was not formally sized.

[Baker]

[Spike]

to get around the sizeof issue, most people just put an entry on the end with everything set to null or something otherwise invalid, as a marker to know when its reached the end.
if you really need a pointer, you can always do extern mytype *fooptr; mytype fooarr[] = {{foo}}; mytype *fooptr = fooarr; with a few added consts, which would of course give a pre-initialised pointer to the same address that the array is located at.
note that (fooarr) and (&fooarr) will both return the same address. Because arrays are weeird, like function pointers really.

char* has to always be loaded before use, while an array's offset can be hardcoded within the instructions that use it.
this means that arrays result in larger individual instructions, while pointers take an extra instruction, the other references are typically smaller by a few bytes (especially on amd64)

[Baker]

Can I expect single byte data types, like char or unsigned char, to hold up to my previous conception that:

char* somevar;

and

char somevar[20];

... can be expected to be reliably the same from a referencing standpoint? And the behavior you described above is typically limited to struct behavior?

I ask because I have never experienced a situation where either of these has failed me:

char* something = somevar; // Where char somevar[20];
byte* something = somedata; // Where byte is unsigned char and byte somedata[20];

Obviously I'm only talking about to trusting that the reference works, clearly sizeof is lost.

[I know the perils of sizeof. Perhaps not all of them, but I am super-paranoid about it know the few occasions that I can expect to trust it. I also know the sizeof a struct can vary from expectations, you and others explained when I discovered "the padding" that cannot be trusted to operate in any specific way.]

[Spike]

huh? a pointer is always 4 bytes (8 bytes on a 64bit machine).
while a 20-element byte array is of course 20 bytes...
a pointer to a 20-element byte array is still just 4 bytes. there's just an extra 20 bytes which is not part of the pointer itself, but part of what it points to.

just because the syntax is the same doesn't mean that the hardware instructions are, which means you cannot mix and match them in different C files, because the hardware representation would conflict between modules / .c files.

If you never take the address of the pointer/array, then the *syntax* is the same and you can freely change the definition between pointer and array - so long as you never use sizeof and the prototype of it matches in every single .c file.

pointer arithmatic works just fine regardless of whether the data is at a constant location (array) or a variable location (pointer). The syntax differences really only come when you take the address of a constant vs variable, while the hardware always cares about the difference. Storing the constant (array) address of the data inside a variable (pointer, even if defined const) is no different from storing the number 5 in a an int, and will allow the hardware to access your fixed-address array data through a variable.

When you have position independant code (more common in linux), the 'constant' addresses are calculated based upon the program counter offset. the maths is along the lines of (&dataaddress - baseaddressofinstruction) + instructionpointer, the first two parts being a constant and the second part being a register of some kind, though on x86 there'll be some additional offsets because you cannot directly reference the instruction pointer register.

Remember - a pointer is an integer variable, accessed through the value stored in that integer. An array is an actual chunk of memory, accessed through the constant address of the first byte.

[Baker]