Hacker News Reader

Comment by hardlianotion | Hacker News Reader

I think the answer is probably to try to conform to the standard, instead.

I have a small program which uses an undefined behavior. How would you rewrite this so as to not do so, but maintain all existing defined behaviors?

    #include <stdio.h>

    int main() {
        int a, b, c;
        printf("Please enter two numbers: ");
        scanf("%d %d", &a, &b);
        c = a + b;
        printf("The sum of the numbers you entered is %d\n", c);
        return 0;
    }

This is the problem. There is no non-trivial C code that doesn't use some undefined behavior somewhere. And it works just fine, right now. But who says it will on the next version of the compiler?

What's the UB here?

consider what happens if the input numbers are INT_MAX and 1

That doesn't make the program incorrect, it just means that you can't provide that particular input to the program.

Yes, but the "can't" really is a "shouldn't".

Point taken; unfortunately I can't edit anymore…

a program which has undefined behaviour on some inputs is an incorrect program by definition

I'll have to disagree with you there: you cannot fully control the range of inputs that you are provided at all times, or perform verification of input. But you can clearly document what conditions the input must satisfy for the program to be well-defined.

The problem is that UB is invoked on runtime for particular inputs... And it silently makes program unreasonable after this point.

That is not good. It's hard to reason about such a program, in other words can you trust results of such a program? How do you know whether your input caused Ub at some point or not?

The burden of sanitizing the input is on the user (either programmer or the data provider).

Checking this is usually a performance tradeoff, so it was decided not to be done by default.

That's a documentation/sanitization problem, rather than a one involving the question of whether this program is well-formed. My response was that it is, given the input obeys the rules you've stated. How you enforce that is a different concern (or whether you dislike the preconditions and think this code could be more robust and have a wider domain, because it certainly could).

Unless the undefined behaviour is hidden in printf or scanf, this code exhibits none. Variadic functions are reasonably well defined and no type aliasing takes place.

(And you're missing a few error checks.)

Can the people downvoting this comment provide a reason why? It seems perfectly reasonable to me.

Integer overflow is undefined behaviour so an input for instance of 2147483647 and 1 makes the program invalid.

Sure, but the program is well-defined on inputs that do not cause it to overflow. It does not perform undefined behavior in those cases, so it's correct given those preconditions.

> I have a small program which uses an undefined behavior. How would you rewrite this so as to not do so, but maintain all existing defined behaviors?

in this precise case, (in C++ because I can't be arsed to search the modifier for int64), fairly easily :

    #include <fmt.h>
    #include <cstdio>

    int main() {
        int a{}, b{};
        int64_t c{};
        fmt::print("Please enter two numbers: ");
        scanf("%d %d", &a, &b);
        c = a + b;
        fmt::printf("The sum of the numbers you entered is {}\n", c);
        return 0;
    }

in the case where a, b, were also of the largest int type available, you could do :

    #include <stdio.h>

    int main() {
        int a, b, c;
        printf("Please enter two numbers: ");
        scanf("%d %d", &a, &b);
        if(__builtin_add_overflow(a, b, &c)) 
        { 
          printf("The sum of the numbers you entered is %d\n", c); 
        }
        else 
        {
          printf("You are in a twisty maze of compiler features, all different"); 
          exec("/usr/bin/0ad");
        }
        return 0;
    }

but you could also use the more portable macros provided in emacs (100 % independent of any other code) : https://github.com/jwiegley/emacs-release/blob/adfd5933358fd...

John Regehr wrote a post about checking for signed overflow a few years ago:

https://blog.regehr.org/archives/1139

HN discussion:

https://news.ycombinator.com/item?id=7665254

Your first suggestion is similar to his checked_add_1(). The Emacs macros are similar to his checked_add_4(). Presumably builtins are optimal, performance wise, for a given compiler.

With regard to your first version: I had this vague feeling that the usual arithmetic conversions state that if the operands are of the same type, then no conversion is performed, and apparently this is so. If so, then would not the expression a + b potentially overflow, regardless of what it is being assigned to?

FWIW, I tried this example:

  #include <stdio.h>
  #include <limits.h>
  #include <stdint.h>

  int main () {
    int64_t  x;
    int a = INT_MAX, b = 1;
    x = a + b;
    printf( "%lu %lu %d %lld\n", sizeof(x), sizeof(a), a, x);
    return 0;
  }

After compiling gcc -std=c11 -fsanitize=undefined -Wall -Wpedantic -Wextra (getting no warnings), on running I get

  c-undef.c:8:9: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
  8 4 2147483647 -2147483648

Also with -O0 and -O3.

At least according to the answer in [1], signed (but not unsigned) integer overflow is undefined behavior (unless C and C++ have diverged on this matter, but I get the same result when the same source code is compiled as C++17.)

This may seem to be pedantic (if it is not just wrong), but the point is that you have to be unremittingly pedantic to avoid undefined behavior.

[1]https://stackoverflow.com/questions/16188263/is-signed-integ...

> I had this vague feeling that the usual arithmetic conversions state that if the operands are of the same type, then no conversion is performed

that's 100% correct, nice catch.

I like the idea of your first try, but it's not guaranteed to work on all implementations, even with the type promotion fixed. The problem is that the C standard doesn't specify a maximum size for int. It could be a 128 bit type.

"Portable C" doesn't exist.

> I like the idea of your first try, but it's not guaranteed to work on all implementations,

in C++ you'd just add

    static_assert(sizeof(int) < sizeof(int64_t), "fix your types");

to be safe about this

The compiler will not break this example, because it cannot put restrictions on the values of a and b. The only thing it can do is assume that a + b < INT_MAX, in which case the program will work as expected.

No. It can check whether the operands will cause overflow and issue an error instead of silently giving a bogus result.

It's a performance hit though.

I don't think you'd want a banking app written with assumption that you'll never have more than MAXINT amount of dollars, and adding few more will roll you back to 0 or even put you in debt... silently... because well it works this way, and designer didint think you'll hit the limit. If it ever happened you'd like a siren to go off.

> It can check whether the operands will cause overflow and issue an error instead of silently giving a bogus result.

Yes, and it could also decide to wipe your hard drive because of the latitude given to it by the C standard. Many compilers have an option to enable some sort of special behavior when a signed integer overflows, but such extensions are non-standard.

Nobody has mentioned that scanf has undefined behavior on numeric overflow. If INT_MAX is 2147483647 and the user enters 2147483648, the behavior is undefined. (That doesn't just mean you can get an arbitrary value for a and/or b. It means that the standard says nothing at all about how the program behaves).

Reference: N1570 (C11) 7.21.6.2 paragraph 10: "If this object does not have an appropriate type, or if the result of the conversion cannot be represented in the object, the behavior is undefined."

strtol() avoids this problem.

Reply on news.ycombinator.com