3 ms·

Unless the C89 standard says something about VM interaction (I'm too lazy to check), it seems like your complaint is misguided.

cygx 14y ago
How so? The pointer pointing past the last member of an array may not be dereferenced. Doing so is UB - end of story.
- mnarayan01 14y ago
  As I said, I'm to lazy too delve into the C89 spec (and too young to have actually programmed in the pre-VM days), but my (only slightly) educated guess is that on the type of machine/OS C89 would have been targeted at, any exceptions thrown by reading past the end of an array could be solved by adding more memory; the same solution as would be required if the array was increased in size.
mikeash 14y ago
You have it backwards. Unless the C89 standard describes behavior for this scenario, it's illegal. The business with putting the array at the end of a page is just an example of how "illegal" can translate into "crashes" on a real-world system.
- mnarayan01 14y ago
  It's certainly not "illegal", it's merely undefined. This may be a pedantic difference but we're talking about an area where being technically correct _really_ is the best kind of correct. I bring up VM behavior because, particularly given the timeframe, it's important to consider that there once was a time when VM did not exist, and SEGV meant an actual _segmentation_ fault.
  - mikeash 14y ago
    The code in question is not valid C code. It just happens not to require an error to be raised, but I think "illegal" sums it up just fine. That's not really a specific term in this situation. As for VM and not-VM, I don't really see why it matters. It would be perfectly valid for a C compiler to generate code that does bounds checking on every array access, for example. And there were far weirder ways to do memory hardware than the standard MMU with 4kB pages that we have today, and the legacy of that can be found throughout the C standard. For example, the fact that it's illegal to store many values in a pointer, not dereference but merely store, comes from systems that really would check that stuff and crash your app if you had a bad pointer value in the wrong place, even if you didn't try to load what it pointed to.
    - mnarayan01 14y ago
      > The code in question is not valid C code. If it were not valid C code, then a standard-compliant C compiler would be required to reject it. Now don't get me wrong, having code that is dependent dereferencing past the end of an array is not a good idea. Having such code in a popular benchmark is a bad situation to be in, particularly when it interferes with progress in compiler optimization. It is not, however, "illegal" for any standard definition of illegal, and in this context clarity is important as ambiguity can interfere with compiler optimization :) Edit: Assume you have a machine/OS with a page size of 1 byte. Can a compiler generate a program that does not raise an exception in the situation mentioned by the OP? Saying such a program is illegal would surely imply that it could not.
      - mikeash 14y ago
        > If it were not valid C code, then a standard-compliant C compiler would be required to reject it. Nope! Here's a direct quote out of the copy of the standard I have lying about, from the section that discusses when diagnostic output is required: "The intent is that an implementation should identify the nature of, and where possible localize, each violation. Of course, an implementation is free to produce any number of diagnostics as long as a valid program is still correctly translated. It may also successfully translate an invalid program." That last sentence is particularly pertinent. Many (most?) languages have two kinds of programs: valid and invalid. C has three: valid, invalid requiring the compiler to reject it, and invalid but the compiler may still accept it. For whatever reason, people have a very hard time understanding the implications of the third category, or, as in your case, even realizing that it exists.
  - cygx 14y ago
    It's certainly not "illegal", it's merely undefined. Potayto, potahto. Violating language semantics results in undefined behaviour. You can only get less legal if you add syntax errors into the mix. You could make the argument that some undefined behaviour should only be considered nonportable instead of erroneous, but personally I consider code that triggers undefined behaviour as invalid or possibly written in a non-standard C dialect.

cygx 14y ago

How so? The pointer pointing past the last member of an array may not be dereferenced. Doing so is UB - end of story.

mnarayan01 14y ago
As I said, I'm to lazy too delve into the C89 spec (and too young to have actually programmed in the pre-VM days), but my (only slightly) educated guess is that on the type of machine/OS C89 would have been targeted at, any exceptions thrown by reading past the end of an array could be solved by adding more memory; the same solution as would be required if the array was increased in size.

mikeash 14y ago

You have it backwards. Unless the C89 standard describes behavior for this scenario, it's illegal. The business with putting the array at the end of a page is just an example of how "illegal" can translate into "crashes" on a real-world system.

mnarayan01 14y ago
It's certainly not "illegal", it's merely undefined. This may be a pedantic difference but we're talking about an area where being technically correct _really_ is the best kind of correct. I bring up VM behavior because, particularly given the timeframe, it's important to consider that there once was a time when VM did not exist, and SEGV meant an actual _segmentation_ fault.
- mikeash 14y ago
  The code in question is not valid C code. It just happens not to require an error to be raised, but I think "illegal" sums it up just fine. That's not really a specific term in this situation. As for VM and not-VM, I don't really see why it matters. It would be perfectly valid for a C compiler to generate code that does bounds checking on every array access, for example. And there were far weirder ways to do memory hardware than the standard MMU with 4kB pages that we have today, and the legacy of that can be found throughout the C standard. For example, the fact that it's illegal to store many values in a pointer, not dereference but merely store, comes from systems that really would check that stuff and crash your app if you had a bad pointer value in the wrong place, even if you didn't try to load what it pointed to.
  - mnarayan01 14y ago
    > The code in question is not valid C code. If it were not valid C code, then a standard-compliant C compiler would be required to reject it. Now don't get me wrong, having code that is dependent dereferencing past the end of an array is not a good idea. Having such code in a popular benchmark is a bad situation to be in, particularly when it interferes with progress in compiler optimization. It is not, however, "illegal" for any standard definition of illegal, and in this context clarity is important as ambiguity can interfere with compiler optimization :) Edit: Assume you have a machine/OS with a page size of 1 byte. Can a compiler generate a program that does not raise an exception in the situation mentioned by the OP? Saying such a program is illegal would surely imply that it could not.
    - mikeash 14y ago
      > If it were not valid C code, then a standard-compliant C compiler would be required to reject it. Nope! Here's a direct quote out of the copy of the standard I have lying about, from the section that discusses when diagnostic output is required: "The intent is that an implementation should identify the nature of, and where possible localize, each violation. Of course, an implementation is free to produce any number of diagnostics as long as a valid program is still correctly translated. It may also successfully translate an invalid program." That last sentence is particularly pertinent. Many (most?) languages have two kinds of programs: valid and invalid. C has three: valid, invalid requiring the compiler to reject it, and invalid but the compiler may still accept it. For whatever reason, people have a very hard time understanding the implications of the third category, or, as in your case, even realizing that it exists.
- cygx 14y ago
  It's certainly not "illegal", it's merely undefined. Potayto, potahto. Violating language semantics results in undefined behaviour. You can only get less legal if you add syntax errors into the mix. You could make the argument that some undefined behaviour should only be considered nonportable instead of erroneous, but personally I consider code that triggers undefined behaviour as invalid or possibly written in a non-standard C dialect.