4 ms·

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

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
        Anyone reasonable would read "it'll also give you something random should you go out of bounds" as meaning you'll get a random value from out of bounds array accesses. They're basically the same sentences. I think if you're honest, you'll admit you either weren't clear about what would happen, or at least were a little careless with your language. But, maybe I've been too much of a jerk here! Maybe I jumped too hard into "someone's wrong on the internet!" mode. It's OK to be wrong, cool and rock and roll even. Lord knows I've been wrong and will be wrong again. If this is true then I've embarrassed myself and I apologize. Let's go forward and be excellent to each other.

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
        Anyone reasonable would read "it'll also give you something random should you go out of bounds" as meaning you'll get a random value from out of bounds array accesses. They're basically the same sentences. I think if you're honest, you'll admit you either weren't clear about what would happen, or at least were a little careless with your language. But, maybe I've been too much of a jerk here! Maybe I jumped too hard into "someone's wrong on the internet!" mode. It's OK to be wrong, cool and rock and roll even. Lord knows I've been wrong and will be wrong again. If this is true then I've embarrassed myself and I apologize. Let's go forward and be excellent to each other.