7 ms·

>It sounds as if the root of the problem is the C standard. Wouldn't it be better to fix that Isn't the reason for a lot of undefined behavior either in the na

>It sounds as if the root of the problem is the C standard. Wouldn't it be better to fix that Isn't the reason for a lot of undefined behavior either in the name of performance through optimization and assumptions, portability because the implementation can just do whatever the underlying platform natively does or the committee just couldn't agree on it? All three of those scenarios appear inherently unfixable to me without a separate sub-standard that intentionally clamps down on performance/ease of portability and actually gets the committee to agree.

tmalsburg2 11y ago
I don't know the reasons for why so many things are undefined in C. However, if a program does one thing when compiled with compiler A and another thing when compiled with compiler B, how does that help portability? To my perhaps naive mind this makes portability harder to achieve not easier.
- pjc50 11y ago
  A classic example of trying to define behaviour regardless of what all the different hardware does is Java choosing IEEE754 floating point. Which isn't natively supported on x86. https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf If C had standardised to the idiosyncracies of the PDP-11, it might have held back its development.
  - jey 11y ago
    Are you referring to 80-bit floats used by the (long obsolete) x87 FPUs?
    - pjc50 11y ago
      The 80-bit floats were still in use right through the 2000s; I know because I had to work out what option to use to get reproducible fp rounding on 64-bit doubles in 32-bit C. I've not had occasion to look at the details of amd64 fp.
  - edmccard 11y ago
    >Java choosing IEEE754 floating point. Which isn't natively supported on x86. IEEE754 was based on the design of the 8087, and it's been native on x86 since the 80387. The problem with Java choosing IEEE754 was, according to the paper you linked, not that it wasn't supported on all hardware, but that Java didn't follow the spec completely, "Later we shall see why Java’s expanded market would be served better by actual conformity to the letter and spirit of IEEE Standard 754"
- habitue 11y ago
  The point is you are supposed to avoid undefined behavior, precisely because these things can be different between compilers. In theory, this lets the compilers optimize better for a specific platform/cpu, while avoiding changing the meaning of the programmer's code. In practice, most platforms and compilers have done the same exact thing with the same "undefined" behavior, that a large body of code relies on that defacto standard.
  - mcguire 11y ago
    "In practice, most platforms and compilers have done the same exact thing with the same "undefined" behavior, that a large body of code relies on that defacto standard." All compilers on the same platform have done the same exact thing with the same "undefined" behavior. At the moment, all platforms are x86. Previously, all platforms were SPARC, and before that, VAX.
    - krallja 11y ago
      > At the moment, all platforms are x86 My iPhone, Raspberry Pi, Chromecast, Xbox, and PlayStation disagree with you.
      - beefhash 11y ago
        Additionally, the Nintendo 3DS uses a ARM9 and an ARM11; the Nintendo Wii uses PPC-based CPUs. Non-x86 are still present.
kuschku 11y ago
Or you use a subset of C where the compiler bans using undefined behavior and doesn’t compile with it?
- Kristine1975 11y ago
  Assume p is a pointer. Then this is possibly invoking undefined behavior, unless the compiler can prove that p will never be NULL: *p;
  - kuschku 11y ago
    Then you require that either the programmer checks if the pointer is null, or the compiler can infer that it isn’t null, or that you add an annotation for that. (Either an annotation for a method parameter to require it not to be null, or an annotation that marks it as nullable, or an annotation that disables these warnings. It’s what we do in Java, too.
  - scott_s 11y ago
    The real problem is when compilers make assumptions based on such uses. For example, optimizing C compilers will see that, and assume that p must not be NULL, because otherwise it would be undefined. That can lead to dangerous results. John Regehr is a computer science professor at the University of Utah, and has written about this extensively: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213
    - qb45 11y ago
      This optimization exists for a reason. With macros, operator overloading or templates it's very easy to generate code like this: if (!p) { return -1; } else { do something; } if (!p) { return -1; } else { do something else; } if (!p) { return -1; } else { do even more; } ... And now, you want the compiler to remove all these redundant checks. Moreover, you very likely don't want warnings here.
      - scott_s 11y ago

tmalsburg2 11y ago

I don't know the reasons for why so many things are undefined in C. However, if a program does one thing when compiled with compiler A and another thing when compiled with compiler B, how does that help portability? To my perhaps naive mind this makes portability harder to achieve not easier.

pjc50 11y ago
A classic example of trying to define behaviour regardless of what all the different hardware does is Java choosing IEEE754 floating point. Which isn't natively supported on x86. https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf https://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf If C had standardised to the idiosyncracies of the PDP-11, it might have held back its development.
- jey 11y ago
  Are you referring to 80-bit floats used by the (long obsolete) x87 FPUs?
  - pjc50 11y ago
    The 80-bit floats were still in use right through the 2000s; I know because I had to work out what option to use to get reproducible fp rounding on 64-bit doubles in 32-bit C. I've not had occasion to look at the details of amd64 fp.
- edmccard 11y ago
  >Java choosing IEEE754 floating point. Which isn't natively supported on x86. IEEE754 was based on the design of the 8087, and it's been native on x86 since the 80387. The problem with Java choosing IEEE754 was, according to the paper you linked, not that it wasn't supported on all hardware, but that Java didn't follow the spec completely, "Later we shall see why Java’s expanded market would be served better by actual conformity to the letter and spirit of IEEE Standard 754"
habitue 11y ago
The point is you are supposed to avoid undefined behavior, precisely because these things can be different between compilers. In theory, this lets the compilers optimize better for a specific platform/cpu, while avoiding changing the meaning of the programmer's code. In practice, most platforms and compilers have done the same exact thing with the same "undefined" behavior, that a large body of code relies on that defacto standard.
- mcguire 11y ago
  "In practice, most platforms and compilers have done the same exact thing with the same "undefined" behavior, that a large body of code relies on that defacto standard." All compilers on the same platform have done the same exact thing with the same "undefined" behavior. At the moment, all platforms are x86. Previously, all platforms were SPARC, and before that, VAX.
  - krallja 11y ago
    > At the moment, all platforms are x86 My iPhone, Raspberry Pi, Chromecast, Xbox, and PlayStation disagree with you.
    - beefhash 11y ago
      Additionally, the Nintendo 3DS uses a ARM9 and an ARM11; the Nintendo Wii uses PPC-based CPUs. Non-x86 are still present.

kuschku 11y ago

Or you use a subset of C where the compiler bans using undefined behavior and doesn’t compile with it?

Kristine1975 11y ago
Assume p is a pointer. Then this is possibly invoking undefined behavior, unless the compiler can prove that p will never be NULL: *p;
- kuschku 11y ago
  Then you require that either the programmer checks if the pointer is null, or the compiler can infer that it isn’t null, or that you add an annotation for that. (Either an annotation for a method parameter to require it not to be null, or an annotation that marks it as nullable, or an annotation that disables these warnings. It’s what we do in Java, too.
- scott_s 11y ago
  The real problem is when compilers make assumptions based on such uses. For example, optimizing C compilers will see that, and assume that p must not be NULL, because otherwise it would be undefined. That can lead to dangerous results. John Regehr is a computer science professor at the University of Utah, and has written about this extensively: http://blog.regehr.org/archives/213 http://blog.regehr.org/archives/213
  - qb45 11y ago
    This optimization exists for a reason. With macros, operator overloading or templates it's very easy to generate code like this: if (!p) { return -1; } else { do something; } if (!p) { return -1; } else { do something else; } if (!p) { return -1; } else { do even more; } ... And now, you want the compiler to remove all these redundant checks. Moreover, you very likely don't want warnings here.
    - scott_s 11y ago