3 ms·

Memory (i.e. the totality of the machine's RAM) isn't, but the subsets allocated to you are. Iterating a pointer on an array certainly will give you the next it

Memory (i.e. the totality of the machine's RAM) isn't, but the subsets allocated to you are. Iterating a pointer on an array certainly will give you the next item in said array; it'll also give you something random should you go out of bounds.

camgunz 3y ago
It might, but it might not. This is actually undefined behavior, so it might do anything. This is part of C's complexity: it abstracts memory such that it mostly seems like a big array, but the addresses you're getting bear no resemblance to where they physically are. Depending on your OS, dereferencing that out of bounds pointer might signal a segfault, give you another process' data, or return data from a sensor, for example. Stuff like this is just very hard to explain to like, a Python engineer because it's just a totally different world.
- deaddodo 3y ago
  No, this is not undefined behavior. Aggregate types are the one aspect of the C "memory model" that is very well defined. The physical memory isn't necessarily contiguous, but the model of memory is. Which is the entire point. arr[0] and arr[999] are 1000 virtually contiguous blocks. You can confirm that in the spec here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
  - camgunz 3y ago
    Sorry I was referring to this: > it'll also give you something random should you go out of bounds. Out-of-bounds array accesses are UB
    - deaddodo 3y ago
      I mean, that was the point of: > it'll also give you something random should you go out of bounds. Are you just taking umbrage with the word I used? "random" clearly is meant to imply that the language makes no guarantees.
      - camgunz 3y ago
        Oh, I guess I thought you meant it would be like uninitialized memory. If you're saying you mean "UB" when you write "random" then yeah, we agree, although I think it's kind of confusing.
        deaddodo 3y ago
        > Oh, I guess I thought you meant it would be like uninitialized memory Uninitialized memory/data isn't "random", it's specifically null. Random could be something uninitialized, or it could be the kernel entrypoint or it could be a pixel data byte from some BMP.
        camgunz 3y ago
        > Uninitialized memory/data isn't "random", it's specifically null. Ooh that's very untrue [0]. Although, I guess I should make sure we're talking about the same thing. I'm saying this is undefined (the little program I've linked below): #include <stdio.h> int main() { int a[4] = {0, 1, 2, 3}; int b = a[1000]; /* undefined behavior! */ printf("%d\n", b); } A lot of people think b should be something random (uninitialized memory), or NULL, but literally anything can happen: those options, your printer spits up all its ink onto the ceiling, you read data from a sensor on an embedded board, you read data from a different process' memory, you get a segfault, etc. It's dependent on how your OS (or whatever) manages memory beneath you. In this case w/ these compiler options and such, it's uninitialized memory. [0]: https://godbolt.org/z/KKfhxdo99 https://godbolt.org/z/KKfhxdo99
        deaddodo 3y ago
        Your definition of "random" is bespoke to you. Suffice to say, my original statement clearly matches what you seem to be getting at; whether you like the choice of words or not.
        camgunz 3y ago

camgunz 3y ago

It might, but it might not. This is actually undefined behavior, so it might do anything. This is part of C's complexity: it abstracts memory such that it mostly seems like a big array, but the addresses you're getting bear no resemblance to where they physically are. Depending on your OS, dereferencing that out of bounds pointer might signal a segfault, give you another process' data, or return data from a sensor, for example. Stuff like this is just very hard to explain to like, a Python engineer because it's just a totally different world.

deaddodo 3y ago
No, this is not undefined behavior. Aggregate types are the one aspect of the C "memory model" that is very well defined. The physical memory isn't necessarily contiguous, but the model of memory is. Which is the entire point. arr[0] and arr[999] are 1000 virtually contiguous blocks. You can confirm that in the spec here: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
- camgunz 3y ago
  Sorry I was referring to this: > it'll also give you something random should you go out of bounds. Out-of-bounds array accesses are UB
  - deaddodo 3y ago
    I mean, that was the point of: > it'll also give you something random should you go out of bounds. Are you just taking umbrage with the word I used? "random" clearly is meant to imply that the language makes no guarantees.
    - camgunz 3y ago
      Oh, I guess I thought you meant it would be like uninitialized memory. If you're saying you mean "UB" when you write "random" then yeah, we agree, although I think it's kind of confusing.
      - deaddodo 3y ago
        > Oh, I guess I thought you meant it would be like uninitialized memory Uninitialized memory/data isn't "random", it's specifically null. Random could be something uninitialized, or it could be the kernel entrypoint or it could be a pixel data byte from some BMP.
        camgunz 3y ago
        > Uninitialized memory/data isn't "random", it's specifically null. Ooh that's very untrue [0]. Although, I guess I should make sure we're talking about the same thing. I'm saying this is undefined (the little program I've linked below): #include <stdio.h> int main() { int a[4] = {0, 1, 2, 3}; int b = a[1000]; /* undefined behavior! */ printf("%d\n", b); } A lot of people think b should be something random (uninitialized memory), or NULL, but literally anything can happen: those options, your printer spits up all its ink onto the ceiling, you read data from a sensor on an embedded board, you read data from a different process' memory, you get a segfault, etc. It's dependent on how your OS (or whatever) manages memory beneath you. In this case w/ these compiler options and such, it's uninitialized memory. [0]: https://godbolt.org/z/KKfhxdo99 https://godbolt.org/z/KKfhxdo99
        deaddodo 3y ago
        Your definition of "random" is bespoke to you. Suffice to say, my original statement clearly matches what you seem to be getting at; whether you like the choice of words or not.
        camgunz 3y ago