What Every C Programmer Should Know About Undefined Behavior
1–10 of 14 posts
Re: What Every C Programmer Should Know About Undefined Behavior
#2customer journey mapping https://twilio.com/flex
Re: What Every C Programmer Should Know About Undefined Behavior
#3Nice read, I recommend the 3 articles of the series.
One thing that I find artificial in the examples is to use signed integers for loops. I always have seen unsigned integers in practice. In general I try to avoid signed integers like plague for big values storage and only use them for error propagation, with negative values for errors like the libc does.
Re: What Every C Programmer Should Know About Undefined Behavior
#4Nice read, I recommend the 3 articles of the series. One thing that I find artificial in the examples is to use signed integers for loops. I always have seen unsigned integers in practice. In general I try to avoid signed integers like plague for big values storage and only use them for error propagation, with negative values for errors like the libc does.
The benefit of using signed integers these days is that compilers can utilize signed integer overflow to trap, which is helpful in debugging, since it's undefined behavior whereas unsigned overflow is well defined.
Re: What Every C Programmer Should Know About Undefined Behavior
#5Nice read, I recommend the 3 articles of the series. One thing that I find artificial in the examples is to use signed integers for loops. I always have seen unsigned integers in practice. In general I try to avoid signed integers like plague for big values storage and only use them for error propagation, with negative values for errors like the libc does.
The benefit of using signed integers these days is that compilers can utilize signed integer overflow to trap, which is helpful in debugging, since it's undefined behavior whereas unsigned overflow is well defined.
Signed integral operations are often faster too, since the well-definedness of unsigned overflow can require additional instructions esp. if the width of the unsigned integral is not the same as the architecture word width.
Re: What Every C Programmer Should Know About Undefined Behavior
#6Nice read, I recommend the 3 articles of the series. One thing that I find artificial in the examples is to use signed integers for loops. I always have seen unsigned integers in practice. In general I try to avoid signed integers like plague for big values storage and only use them for error propagation, with negative values for errors like the libc does.
I don't know whether the standard guarantees you can index into arrays with large unsigned ints (it says "integer type”. I don’t know whether that means it will support both without silently converting them, or whether that means an implementation can pick one)
Also, I don’t know whether it (¿still?) is valid C, but I’ve used negative indexes in the past in graphics applications, where it is convenient to have an 'array' with indices that dont start at zero. One-dimensional example:
#define N 100
char a[2 * N + 1];
char * b = a + 100;
...
for(int x = -N; x Re: What Every C Programmer Should Know About Undefined Behavior
#7Earlier quoted context omitted.
The benefit of using signed integers these days is that compilers can utilize signed integer overflow to trap, which is helpful in debugging, since it's undefined behavior whereas unsigned overflow is well defined.
Signed integral operations are often faster too, since the well-definedness of unsigned overflow can require additional instructions esp. if the width of the unsigned integral is not the same as the architecture word width.
Interesting, so that would mean that `int` would be faster than `unsigned int` in tight loops because the compiler would not have to check for overflow and do the wrapping (if the upper bound is unknown so that it cannot be optimized out).
I think that in Rust the unsigned types do not wrap by default, so that the compiler does not have to introduce these checks at runtime. If one wants wrapping, they have to directly use the wrap types instead which would be more instruction-heavy.
I wonder if there is a way in C to reproduce this mechanism in order to not generate any check instructions as well for unsigned types.
Re: What Every C Programmer Should Know About Undefined Behavior
#8Earlier quoted context omitted.
Signed integral operations are often faster too, since the well-definedness of unsigned overflow can require additional instructions esp. if the width of the unsigned integral is not the same as the architecture word width.
Interesting, so that would mean that `int` would be faster than `unsigned int` in tight loops because the compiler would not have to check for overflow and do the wrapping (if the upper bound is unknown so that it cannot be optimized out). I think that in Rust the unsigned types do not wrap by default, so that the compiler does not have to introduce these checks at runtime. If one wants wrapping, they have to directl…
> I wonder if there is a way in C to reproduce this mechanism in order to not generate any check instructions as well for unsigned types.
Correct me if I'm wrong (I probably am, don't trust me) but simply using `unsigned` as the type gives you the most optimal signed unsigned integer type for the system.
Re: What Every C Programmer Should Know About Undefined Behavior
#9Earlier quoted context omitted.
Signed integral operations are often faster too, since the well-definedness of unsigned overflow can require additional instructions esp. if the width of the unsigned integral is not the same as the architecture word width.
Interesting, so that would mean that `int` would be faster than `unsigned int` in tight loops because the compiler would not have to check for overflow and do the wrapping (if the upper bound is unknown so that it cannot be optimized out). I think that in Rust the unsigned types do not wrap by default, so that the compiler does not have to introduce these checks at runtime. If one wants wrapping, they have to directl…
I am not sure if this generalizes to non-64 bit platforms, but in my experience using size_t gives you unsigned integer indexing without requiring overflow checks (as it's normally a 64 bit quantity).
Re: What Every C Programmer Should Know About Undefined Behavior
#10And the counterpoint, [What Every Compiler Writer Should Know About Programmers][0] (PDF only, unfortunately).
Also for further reading see much of John Regehr's blog, e.g. [Taming Undefined Behavior in LLVM][1].