The title claims everything, but certainly it doesn't cover everything. It mentions const but doesn't mention volatile. It also doesn't mention restrict which is more confusing than const/volatile. It didn't mention the strict aliasing rule. It actually didn't even mention NULL.
Pointers in C (2010)
31–40 of 113 posts
Re: Pointers in C (2010)
#32I 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 size…
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.
Re: Pointers in C (2010)
#33Ah, boxes again. For me, all confusion about C's pointer-happiness cleared up when I finally realized that C (and Asm, I guess) works with heap memory as a big blob of bytes, and it's programmer's job to keep the blob's contents from getting messed up―with some thinly-veiled help from the language and the compiler. Everything else, including variables, is just syntactic sugar when it points to the heap. (With the cla…
My favorite proof that C arrays and strings are actually just syntactic sugar for pointer arithmetic is that the following are all valid and equivalent: char theLetterC = "ABC"[2]; char theLetterC = *("ABC" + 2); char theLetterC = *(2 + "ABC"); char theLetterC = 2["ABC"]; "You can't prove anything about a program written in C or FORTRAN. It's really just Peek and Poke with some syntactic sugar." -Bill Joy
> Peek and Poke
Now that's the words I haven't heard in a long time.
Re: Pointers in C (2010)
#34I always wonder what makes pointers so difficult for some. So far I have always been able to explain it to people by drawing a linear memory space and then showing how different types are allocated. It seems to me that pointers are one the easier concepts in programming.
Same here, but then again I already knew Z80, 80x86, 68000, Basic and Pascal before I got to learn C. I guess it is a problem for those who C is the first language where they see pointers in action.
Yeah, so much this. I did most of my programming in asm in the mid 70s to early 80s. C wasn’t available back then on most 8-bit systems I used (Z-80, 6502, 6809, 1802, SC/MP). C pointers made complete sense to me once 16-bit microcomputers showed up.
Re: Pointers in C (2010)
#35I 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 size…
> "&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]) )Re: Pointers in C (2010)
#36Earlier quoted context omitted.
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).
> 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'r…
> `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.
Re: Pointers in C (2010)
#37I 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 size…
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.
Re: Pointers in C (2010)
#38I always wonder what makes pointers so difficult for some. So far I have always been able to explain it to people by drawing a linear memory space and then showing how different types are allocated. It seems to me that pointers are one the easier concepts in programming.
In my place, those who teach C/C++ doesn't have any practical knowledge on it. They are just reading out programs from the textbook.
Context: This is true in many parts of India at least, where I suspect the parent is from.
I used to teach C, found pointers a bit tough, then understood them after playing around a bit. General teachers of C indeed didn't have any real world exposure to programming.
Re: Pointers in C (2010)
#39Earlier quoted context omitted.
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).
Re: Pointers in C (2010)
#40The title claims everything, but certainly it doesn't cover everything. It mentions const but doesn't mention volatile. It also doesn't mention restrict which is more confusing than const/volatile. It didn't mention the strict aliasing rule. It actually didn't even mention NULL.
We uneverythinged the title above.