The Problem with C (2020)

Re:The Problem with C (2020) by foldr on Tuesday February 01, 2022 @04:03AM (#30160190)

Would it change the meaning of existing valid programs? C's "type inference" algorithm is to assume that everything is an int by default. So

    auto x = 7;

is equivalent to

    auto int x = 7;

which is equivalent to

    int x = 7;

(since "auto" is the default storage class). If the C standard folks do things right, then the only change will be to allow some previously invalid code like the following:

    auto str = "foo";

Such code will compile on a C compiler (hopefully with a warning!) but won't have a defined behavior. I guess a more problematic case would be

    auto x = 9999999999999L;

Where the value will be truncated in C but will be inferred as a long in C++ (assuming typical sizes for int and long int). Again, though, I am not sure if truncation of signed constants has a defined behavior in the standard.

[ Parent | on HN ]

Re:The Problem with C (2020) by colonwqbang on Tuesday February 01, 2022 @06:34AM (#30161215)

A simple example would be

  auto pi = 3.14;
  double result = 2 * pi;
  printf("the circumference of the unit circle is %g\n", result);

When interpreted as C89 program, this computes the value 6. Compiled with a C++ compiler it computes 6.28. This is exactly due to that both languages have an auto keyword, but they mean different things.

This situation is perhaps not so likely to occur in real usage, but I think it could and should have been avoided.

[ Parent | on HN ]

Re:The Problem with C (2020) by foldr on Tuesday February 01, 2022 @06:44AM (#30161290)

Ah good point. I was forgetting that implicit conversion from double to int is defined.

[ Parent | on HN ]