Unclear semantics of integer and float constants

[lerno]

There are basically two possible approaches for C2:

1. Distinguish between integer types, so that an integer constant may have a specific bit width. In order to affect this we must explicitly either cast or have suffixes 1.0f, 10uL etc.
2. Say that integer constants are handled as BigInts (we already borrow that functionality from llvm), and that floating point are always folded as highest available precision (f128 or f64). At the final step, it is then rounded to the correct precision / size.

For the second alternative, if we have the following code:

i32 a = 2 * 1000;
f32 b = 2 * 1000.0;
i8 c = 3;
i32 d = 600 + a + 10000 * c

Expressing the above in C++:

int32_t a = (BigInt(2) + BigInt(1000)).toSigned32();
float b = (float)(2.0 * 1000.0);
i8 c = 3;
i32 d = 600 + a + 10000 * (i32)c;

An overflow, for example:

i8 a = 2 * 127;
u8 b = 255 + 1;

Would be detected and flagged as error at runtime.

However, this would not be flagged:

i8 b = 2;
i8 a = b * 127;

Nor would this:

i8 a;
....
u16 b = 65535 + a + 65535;

Only directly folded constants have the error.

I think we should go for (2), since tagging constants with suffixes is a drag and create those incredibly annoying errors when you turn on strict type checking.

[bvdberg]

for Integers: when parsed, numbers are arbitrary size integers. Currently these (APInt) numbers can be added/multiplied etc at analysis time. When assigned, they must fit the type or an error occurs.

For floats, we could use the same principle, just use the Float64 to do calculations and round to float32 if needed.
I dont want to annoy developers with suffixes, they can be removed completely.

[lerno]

What about f128? Should we support that where available?

[lerno]

I've opened an issue #87 for this. The only open question is if we use f128 when available.

[lerno]

In C3 I decided to not implement f128 in the end. Overall this should probably be closed?

[chqrlie]

@lerno the issue #87 has been closed already. I don't think we want f128 either, but the semantics of integer constants is still an open issue.
How do you deal with sizeof(0x80000000) and sizeof(2147483648) in C3? The latter is 8 in C when the former is 4?
How about 0x80000000 << 1 and 2147483648 << 1 ? Again a very different value in C.

[lerno]

I experimented with untyped literals and found that rather bad. I took the plunge initially because Andrew Kelley (of Zig) swore he had had zero problems with that. Turns out that was a lie.

So I went back to C semantics roughly:

1. For hex and binary, assume they are unsigned int. However, if the number of characters exceed that which is needed for 32 bits (if that's int), then assume it's 64 bit instead. So 0x80000000 would be unsigned int, but 0x180000000 would be unsigned long.
2. For decimal numbers: by default assume signed int. If it exceeds int32 max, then assume the long and so on. C3 supports int128 types, so that's the max signed allowed.
3. If it has a U prefix, then in the decimal case assume unsigned int instead.
4. L suffix will give 64 bits, but there are u8, u16, u32, u64, u128 and i8, i16, i32, i64, i128 suffixes as well.

This makes the sizes well defined.

[lerno]

Oh and for the last one: in C3 semantics is always wrapping, so a shift will shift according to the (well defined) type picked.

There are some other things around conversions to smaller integer types from literals with wider types.

You can look at this: https://c3-lang.org/language-fundamentals/basic-types-and-values/#integers