6 ms·

Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and ma

Actually I look forward for enough momentum to be created in the community, to allow new C standards to change the way undefined behaviors are conceived, and make them as specified as possible, and even when they cannot in reasonable unique ways, to provide reference possible behaviors to select in order to have the least unexpected outcome for the programmer. Especially now that low level programming is abstracting away, exactly but not only because of Rust itself, we need a C that is more C than what it became in recent years. After all we don't really need to change the language, but just the new specifications and the compilers implementations of UB.

hedora 7y ago
Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture. Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).
- Hello71 7y ago
  that's implementation defined
- MereInterest 7y ago
  Undefined behavior does not need to be consistent, either across different programs, or within the same program. It does not need to be consistent within different times that the program is run, and it does not need to be documented anywhere. It does not need to be sensible, does not need to be predictable, and does not need to give any diagnostics to warn the programmer. Undefined behavior means that you have passed outside of the realm governed by the standard, and that HERE BE DRAGONS. Implementation-defined behavior works as you say, where each compiler can define how it responds to certain circumstances.
gpderetta 7y ago
You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor. [1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.
- Symmetry 7y ago
  Surely signed integer overflow is also a big problem. And reads from uninitialized memory.
  - gpderetta 7y ago
    I don't think integer overflow itself is a big deal. Unbounded array access, especially local array acces, is though, and I forgot about it.
  - deleted 7y ago
    [deleted]
- saagarjha 7y ago
  > well, you can today by swapping malloc for a GC-enabled implementation You don't need GC for this (at least, in the sense of "we'll call free for you"), you just need to verify that things passed to free were handed out via malloc.
rumanator 7y ago
> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems. https://en.wikipedia.org/wiki/Undefined_behavior https://en.wikipedia.org/wiki/Undefined_behavior
- rhinoceraptor 7y ago
  This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.
  - rumanator 7y ago
    > This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve. And then complain about the consequences.
    - masklinn 7y ago
      > If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Yeaaaah not really: #include <stdio.h> #include <stdlib.h> #include <string.h> static char a[128]; static char b[128]; int main(int argc, char *argv[]) { (void)argc; strcpy(a + atoi(argv[1]), "owned."); printf("%s\n", b); return 0; } compiles with no warning using clang (8), even with -Weverything And that’s a super easy case, it’s not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn’t check its input pointer which only became occasionally null years later.
infamouscow 7y ago
It would also be nice if Rust had a specification. Without a spec it's impossible to build a correct alternative Rust implementation.
- steveklabnik 7y ago
  We're still working on it. In the meantime, there is at least one alternative implementation. It doesn't implement the borrow checker, but can successfully bootstrap a bit-identical rustc. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
- alharith 7y ago
  Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.
  - steveklabnik 7y ago
    We are not oblivious. First of all, we are not really trying "to replace C." Second, a tremendous amount of work has been put into specifying Rust. It's just also a tremendous amount of work. Like, "the EU has given grants of millions of Euro towards working on it but we're still not done" amounts of effort. C did not have a standard for 18 years, it was first created in 1972, and ANSI C didn't appear until the spring of 1990. I'm not suggesting that it took them 18 years to write a spec, it's that it wasn't really needed for a long time. Expecting Rust to have one after five years is aggressive. Some languages have done this! I think we'll end up somewhere between what C did and what C# did, in this regard.
    - earthboundkid 7y ago
      Go has a spec, which has been used to make gccgo. I'm not very familiar with other specs: is it fair to say that the Go spec is less detailed and so was able to be completed before 1.0? Is it "not a real spec" compared to ANSI C, ECMA, etc.?
deleted 7y ago
[deleted]
pjmlp 7y ago
WG 14 doesn't seem that interested in improving C's security story. Right now I see more efforts coming out Microsoft and static analysis tool vendors than any WG 14 mailing.

hedora 7y ago

Last I checked UB was undefined by the standard, but compilers still need to define their behavior on each architecture. Dictating that all architectures implement UB the same way would have significant overhead, since it would force programs that don’t rely on UB to run in emulation on all but one architecture (at best).

Hello71 7y ago
that's implementation defined
MereInterest 7y ago
Undefined behavior does not need to be consistent, either across different programs, or within the same program. It does not need to be consistent within different times that the program is run, and it does not need to be documented anywhere. It does not need to be sensible, does not need to be predictable, and does not need to give any diagnostics to warn the programmer. Undefined behavior means that you have passed outside of the realm governed by the standard, and that HERE BE DRAGONS. Implementation-defined behavior works as you say, where each compiler can define how it responds to certain circumstances.

gpderetta 7y ago

You are never going to get any guaranteed sensible behaviour for a double free or an use after free [1]. In comparison to those giant issues, all other instances of UB are minor. [1] well, you can today by swapping malloc for a GC-enabled implementation, but the fact is that almost nobody does.

Symmetry 7y ago
Surely signed integer overflow is also a big problem. And reads from uninitialized memory.
- gpderetta 7y ago
  I don't think integer overflow itself is a big deal. Unbounded array access, especially local array acces, is though, and I forgot about it.
- deleted 7y ago
  [deleted]
saagarjha 7y ago
> well, you can today by swapping malloc for a GC-enabled implementation You don't need GC for this (at least, in the sense of "we'll call free for you"), you just need to verify that things passed to free were handed out via malloc.

rumanator 7y ago

> allow new C standards to change the way undefined behaviors are conceived, Of all the potential issues that might be attributed to C, undefined behavior (UB) is the one that creates few to no problems at all. To me, complaining about UB is like complaining about the quality of a highway once they intentionally break through the guard rails and start racing through the middle of the woods. The reason why some behavior is intentionally left undefined is to enable implementations to do whatever they find best in a given platform. This is not a problem, it's a solution to whole classes of problems. https://en.wikipedia.org/wiki/Undefined_behavior https://en.wikipedia.org/wiki/Undefined_behavior

rhinoceraptor 7y ago
This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. C is not unsafe if you only write safe code. But humans are fallible, and "just don't write unsafe code" is not a solution.
- rumanator 7y ago
  > This is like saying there's nothing dangerous about guns, because it takes a human to make them dangerous. If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you... You still decide that yes, what you want to do is to shoot yourself in the foot because that is exactly what you want to achieve. And then complain about the consequences.
  - masklinn 7y ago
    > If you want to go with that analogy, UB is a kin of you intentionally pointing your gun to your foot, taking your time to aim it precisely on your foot, and in spite of all the possible warnings and error messages that are shouted at you… Yeaaaah not really: #include <stdio.h> #include <stdlib.h> #include <string.h> static char a[128]; static char b[128]; int main(int argc, char *argv[]) { (void)argc; strcpy(a + atoi(argv[1]), "owned."); printf("%s\n", b); return 0; } compiles with no warning using clang (8), even with -Weverything And that’s a super easy case, it’s not a use after a dynamic callback somewhere freed a pointer it did not own, or a function 5 levels deep (or worse in a dll) didn’t check its input pointer which only became occasionally null years later.

infamouscow 7y ago

It would also be nice if Rust had a specification. Without a spec it's impossible to build a correct alternative Rust implementation.

steveklabnik 7y ago
We're still working on it. In the meantime, there is at least one alternative implementation. It doesn't implement the borrow checker, but can successfully bootstrap a bit-identical rustc. https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc
alharith 7y ago
Just pains me that the Rust team is so oblivious to the fact that they need a spec if they ever hope to have a chance to replace C.
- steveklabnik 7y ago
  We are not oblivious. First of all, we are not really trying "to replace C." Second, a tremendous amount of work has been put into specifying Rust. It's just also a tremendous amount of work. Like, "the EU has given grants of millions of Euro towards working on it but we're still not done" amounts of effort. C did not have a standard for 18 years, it was first created in 1972, and ANSI C didn't appear until the spring of 1990. I'm not suggesting that it took them 18 years to write a spec, it's that it wasn't really needed for a long time. Expecting Rust to have one after five years is aggressive. Some languages have done this! I think we'll end up somewhere between what C did and what C# did, in this regard.
  - earthboundkid 7y ago
    Go has a spec, which has been used to make gccgo. I'm not very familiar with other specs: is it fair to say that the Go spec is less detailed and so was able to be completed before 1.0? Is it "not a real spec" compared to ANSI C, ECMA, etc.?

deleted 7y ago

[deleted]

pjmlp 7y ago

WG 14 doesn't seem that interested in improving C's security story. Right now I see more efforts coming out Microsoft and static analysis tool vendors than any WG 14 mailing.