Hacker News Reader

Comment by _kst_ | Hacker News Reader

I checked the section "Interlude: Arrays" because the relationship between pointers and arrays in C is a major sticking point.

It claims that, given a declaration

    int array[] = { 45, 67, 89 };

the expressions "array", "&array", and "&array[0]" are all equivalent. They are not. "&array" and "&array[0]" both refer to the same memory location, but they're of different types.

In the next section:

"By the way, though sizeof(void) is illegal, void pointers are incremented or decremented by 1 byte."

Arithmetic on void pointers is a gcc-specific extension (also supported by some other compilers). It's a constraint violation in standard C.

I don't think this is the "best" article on pointers in C.

I usually recommend section 6 of the comp.lang.c FAQ, http://www.c-faq.com/

View on HN

> "&array" and "&array[0]" both refer to the same memory location, but they're of different types.

Indeed. And isn't this what makes the classic "countof" macro possible? The macro returns the number of elements in an array, calculating this by dividing the size of the array by the size of the first element:

  #define countof( array )  ( sizeof(array) / sizeof((array)[0]) )

The C faq presents as supposedly common questions and answers without saying what a pointer is.

In contrast I really like the posts definition.

> A pointer is a memory address.

Not perfect but for concision and accuracy it cannot be beat.

Well, it's concise, but it leaves out something important. A C pointer has both a memory address and the type of whatever it believes it points to. The latter is what makes C-style pointer arithmetic possible, because if you know the type, you know its size too.

Right. That's why, when you have an array of structs, say each 8 bytes in size, and a pointer ptr to the start of it, each time you do:

  ptr++;

it increments the address stored in ptr, not by 1, but by 8 (bytes) - so as to now point to the next struct in the array. Same if you do:

  ptr--;

except in that case it decrements the address by 8.

And if you did:

  ptr += 2;

it would increment the address in ptr to point to 16 bytes further ahead in memory than it was earlier, for the same reason. ptr will now point to the struct which is two items further ahead in the array. So you can access that struct with the expression:

  *ptr

Problem is, the author isn't using that definition as a rung on Witgennstein's ladder. He believes it himself. That's why he's oblivious to the differences between array, &array and &array[0]. The expressions produce the same memory address and since that is what a pointer is by definition, they are equivalent.

> He believes it himself

Not necessarily a strong belief, just an amount of ignorance perhaps.

> "&array" and "&array[0]" both refer to the same memory location, but they're of different types.

"&array[0]" also does a dereference, which may cause undefined behaviour if array is null or invalid. You can get fun stuff like the optimizer omitting null checks later on.

Interesting. In C, “&array[0]“ is the same thing as “(array + 0)”, but in my copy of the C11 draft standard, I can't find anything about adding zero to a null pointer.

"&array[0]" is equivalent to "&(array[0])" - [] has greater precedence than &. Desugared, this is "&(*(array + 0))" - add 0, dereference, then take the address.

Yes, you're right about precedence.

Is there a valid use case for doing pointer arithmetic on a void pointer? It just seems so disgusting on the surface. Did someone just really not want to bother casting to uint8_t*?

As for the array types, I think maybe the article is really trying to say that they'll all compile down to the same thing in the end (probably...compilers can be weird sometimes).

Casting to uint8_t* is not portable either, so it's not particularly better than using compiler extensions that let you increment void*.

"char" is portable and by definition sizeof(char) == 1 and on top of that char pointers can alias other types.

If I could time travel and influence the design of C the first things I'd do is change switch to break by default. The 2nd thing I'd do is rename "char" into "byte" since that's effectively what it is (and it's seldom a character these days since we often use UTF-8 or other multi-byte encodings).

> The 2nd thing I'd do is rename "char" into "byte" since that's effectively what it is

This isn't always true. See machines where CHAR_BIT > 8.

I always thought that 1 char was exactly 1 byte, but that 1 byte was not necessarily 8 bits?

I think from a C standards point of view, that's true; I was using the general convention of 1 byte=8 bits, but char being one or more of these bytes. Hence CHAR_BIT is the number of bits in a char, and sizeof gives the number of chars that would fit in the specified type.

A byte is the smallest addressable memory unit, nothing more, nothing less. It's true that on most modern machines it's always equal to 8 bits (and it's mandated by POSIX AFAIK) but that's orthogonal.

In French when talking about storage capacity we use "octet" instead of "byte", I always thought that made more literal sense (if you have a 1megabyte memory on a system where CHAR_BITS is 16, do you have 8 or 16 megabits?).

There are bit-addressable CPUs and DSPs. Examples are many microcontrollers (part of the memory accessible in bit-addressable windows), and famous TMS34010 (https://en.wikipedia.org/wiki/TMS34010).

4-bit CPUs (like the one in your toothbrush or thermometer) can also of course address 4-bit "words", "bytes" or nibbles.

So 8 bits might not be the smallest addressable memory unit.

> Is there a valid use case for doing pointer arithmetic on a void pointer? It just seems so disgusting on the surface. Did someone just really not want to bother casting to uint8_t * ?

As a side note, there was a debate whether casting to `uint8_t * ` is a strict-aliasing issue (As `uint8_t` and `char` are not guarenteed to be the same type, and so the compiler isn't required to treat them as such).

That said, you're correct that you can always cast to `char * ` in this case as `char * ` is allowed to alias anything. I do agree pointer arithematic on `void * ` a bit messy, I think the intention was just as a convenience thing, but it can definitely be abused.

> As for the array types, I think maybe the article is really trying to say that they'll all compile down to the same thing in the end (probably...compilers can be weird sometimes).

I donno, I've read this page before and think the author genuinely doesn't know about pointers to arrays - if they do they've done a good job of pretending they don't exist. They are not mentioned anywhere on the page (Besides the part that says they're are all the same), and near the top the author talks about parentheses in variable declarations and says:

> This is not useful for anything, except to declare function pointers (described later).

Which anybody who has used a pointer to an array will know is not true, as you have to use parentheses to differentiate between a pointer to an array from an array of pointers.

> `uint8_t` and `char` are not guarenteed to be the same type

Remember that `char`, `signed char` and `unsigned char` are the different types, even though `char` takes the same range of values as either `signed char` or `unsigned char`.

The typedef `uint8_t` is usually set to `unsigned char`, not `char`, even on systems where `char` is unsigned. Partly this reflects the fact that `char` is usually used to represent actual characters, while the other two types are usually used to represent integers that take the same amount of memory as `char`. The standard technically does not allow `uint8_t` to be `char` [1], although this requires an extremely pedantic reading.

Anyway, if you replace `char` with `unsigned char` in your comment then it's correct. I believe all current major implementations typedef `uint8_t` to `unsigned char`, but that's not guaranteed and even old implementations of GCC had a different type. `unsigned char` satisfies the same relaxed aliasing rule as `char` [2] but `uint8_t` may not.

[1] https://stackoverflow.com/a/16002781

[2] https://stackoverflow.com/a/40575162

> I believe all current major implementations typedef `uint8_t` to `unsigned char`

That can't be right, because CHAR_BIT is not always 8.

Practically speaking, for most people these days it is. POSIX specifies 8 bits and windows uses it. If you're working with a larger bit char, you're most likely well aware of it (offhand, some TI embedded chips are the only ones I know of, and even theyre rare!)

It depends on what you count as a "major implementation".

Dude, I've just been asked to teach c pointers and this was super helpful. Got a good c++ FAQ? :)

Marshall Cline made a good one, here's a mirror, the original seems down: http://www.dietmar-kuehl.de/mirror/c++-faq/references.html

Marshall Cline's C++ FAQ is really, really good, IMO. I had read it some years ago, I think both the online version and the book, even though I've not really worked on C++ in projects. It goes into good depth and detail, not only on C++ language features and points, but also a lot into OOP/OOAD topics. Things like why you should (sometimes) push code from the client to the server - push in the sense of shift, not in the sense of mobile code, how old code can call new code - that didn't exist when the old code was written - don't remember the full details of that one right now, it may be via virtual functions and inheritance), and many more such things, a lot of them very useful. And all written in a fun, engaging style.

Marshall Cline’s FAQ been absorbed by the “official” C++ FAQ: https://isocpp.org/faq

Reply on news.ycombinator.com