Storing meta information in types?! Preposterous! What's next - a different type to discern a string from a pointer to a single character? A different type to signify a pointer that can be freed? A different type for different encodings? That's rust
C is meant to be simple, only fast and least variants of int allowed
ASM has no types.
We'll use 8 bits for simplicity.
add one to 01111111,
you get 10000000
10000000 has no type. Is it a signed into? Or is it an unsigned int?
Types are a spook invented by programming languages.
2 months ago
Anonymous
>Types are a spook invented by programming languages.
A spook?
If anything they're standards you use to decide what those collections of bits are representing.
Clearly what you did there is decided those 8 bits represent a single number because you could just as legitimately go. >We add 1 to 01111111 and get 01110000+OF
2 months ago
Anonymous
>standards
Standards are spooks.
2 months ago
Anonymous
Don't listen to the other guy. if you add two 8-bit unsigned integers that result in a value greater than 255, the result will wrap around to a value between 0 and 255. This is the default behavior on x86 processors, as opposed to saturating the result to the minimum or maximum value.
The reason for this wrapping behavior is that it is the most efficient way to implement integer arithmetic in hardware. Checking for and handling overflow conditions would add extra complexity and latency to the CPU's arithmetic logic unit. Instead, x86 CPUs simply discard the high-order bits that don't fit in the destination register.
2 months ago
Anonymous
We're talking about signed integer overflow, not unsigned.
1. 255+1 is 0, not "any value"
2. Unsigned integer overflow is NOT undefined behavior in C.
3. Signed integer overflow being UB in C is because ASM has no concept of types.
2 months ago
Anonymous
Wrong again, x86 will happily sets off the V flag when signed overflow happens.
https://en.wikipedia.org/wiki/Overflow_flag
ASM may not have types but it is fully capable of setting flags when necessary.
2 months ago
Anonymous
Setting flags does not change the bits in the register.
It's up to the programmer to do as they wish with the flags.
The programmer can decide to ignore the flag if they want to.
Because `add` is a low level function that doesn't distinguish between signed or unsigned, all of these function signatures are correct:
add :: int -> int
add :: int -> uint
add :: uint -> int
add :: uint -> uint
Hence, types are a spook.
From C's perspective, with signed overflow, it can use add :: int->uint and downcast the results, which leads to a different value than using add :: int->int, hence UB.
2 months ago
Anonymous
>downcast
What does this look like on a bit level?
Also, how does stdckdint fit into this?
2 months ago
Anonymous
>What does this look like on a bit level?
When you add one to 01111111, you get 10000000
Take this meme code for example (pic related).
While `add` doesn't care about types in asm, jump does (also multiplies)
ja/jb for unsigned, jg/jl for signed
mul for unsigned, imul for signed
INT_MAX+1 can be interpreted either as add :: int -> uint or add :: int -> int
This is important because when doing the comparison, the compiler needs to decide whether or not to use ja/jb or jg/jl
When I say "downcast" I really mean "upcast" (it's a subtle difference).
Because `add` is a primitive function with undefined type signature, you can "upcast" all arguments to the comparison, and use ja/jb, thus the expression `INT_MAX + 1 < INT_MAX` is always false (and then you downcast the false truth value to int).
My point is that the hardware is fully capable of expressing to you that a signed integer overflow has happened. It's C's inadequacy that makes it an "UB" within the standard it set for itself.
The hardware sets those overflow flags on unsigned addition as well - and all compilers (including Rust) discard the overflow flags. >When binary values are interpreted as unsigned numbers, the overflow flag is meaningless and normally ignored. One of the advantages of two's complement arithmetic is that the addition and subtraction operations do not need to distinguish between signed and unsigned operands. For this reason, most computer instruction sets do not distinguish between signed and unsigned operands, generating both (signed) overflow and (unsigned) carry flags on every operation, and leaving it to following instructions to pay attention to whichever one is of interest.[2]
The issue is that the type signature of the `add` function is not defined at a low level. So Rust assumes the input type is the same as the output type ( add :: int -> int or add :: uint -> uint ) whereas this is not true in hardware.
2 months ago
Anonymous
>downcast
What does this look like on a bit level?
Also, how does stdckdint fit into this?
Forgot pic
2 months ago
Anonymous
>Because `add` is a primitive function with undefined type signature, you can "upcast" all arguments to the comparison, and use ja/jb, thus the expression `INT_MAX + 1 < INT_MAX` is always false (and then you downcast the false truth value to int).
That's not how the C standard sees it, it has a firm opinion about whether you're doing the comparison using signed or unsigned operands. The problem is the addition, not the comparison.
You can also == INT_MIN if you prefer. Same story. >The issue is that the type signature of the `add` function is not defined at a low level. So Rust assumes the input type is the same as the output type ( add :: int -> int or add :: uint -> uint ) whereas this is not true in hardware.
No, the issue is that the compiler assumes that INT_MAX + 1 won't happen and doesn't take that case into account at all.
2 months ago
Anonymous
>That's not how the C standard sees it, it has a firm opinion about whether you're doing the comparison using signed or unsigned operands. The problem is the addition, not the comparison.
Yes the standard says unsigned integer overflow is UB. Thus the compiler does whatever it wants.
Now I'm trying to tell you *why* it is UB.
The reason is because if you try to "define" the behavior, you lead to the language being "inconsistent" with casting semantics, all stemming from the fact that assembly `add` doesn't have a type signature.
You have to make an *assumption* about what the programmer wants (idempotence of types) in order to make the define the undefined behavior.
The truth is that *all* typed languages are not low-level, because ASM doesn't have types.
2 months ago
Anonymous
I really don't think casting has anything to do with it. Generally hardware has a fairly nailed down concept of signed arithmetic, and already had back then—it's just that there were some holdouts that still had one's complement.
x86 does in fact have an opinion about how signed arithmetic works. You can mix instructions if you want but there's an obvious choice for C (that AFAIK was already the obvious choice for the PDP-11).
2 months ago
Anonymous
>x86 does in fact have an opinion about how signed arithmetic works
Then why don't they add an `iadd` function?
`mul` for unsigned, `imul` for signed
`ja/jb` for unsigned, `jg/jl` for signed
`add` for unsigned... _ for signed
The issue is not "an opinion on how signed arithmetic works" - the issue is "well defined types"
At the end of the day, a signed int is just a *type* of int.
2 months ago
Anonymous
Yes, the add instruction happens to be suitable for both signed and unsigned addition. So what?
C doesn't have int -> uint addition.
2 months ago
Anonymous
No. iadd and add would do slightly different things.
iadd would flip the overflow flag on signed integer overflow whereas add would not
add would only flip the overflow flag on unsigned integer overflow.
In C and most languages, the infix addition operator is a primitive and usually corresponds directly to the typeless asm instruction, and hence it does indeed to int -> uint, because the assembly does exactly that as well (or really it doesn't have any type at all because assembly add has no type signature)
Assembly *could* embed types into the operations, like it does most of the time, but x86 does not do it for addition at the moment.
2 months ago
Anonymous
It doesn't int -> uint. C puts an int in and takes an int out. This is really explicit in the standard.
The assembly is indeed typeless but there's no sense in which it boils down to int -> uint. Certainly the implementation is not permitted to perform unsigned comparison.
Also C has the exact same opinion about multiplication, i.e. that signed overflow is UB while unsigned overflow wraps. Even though the assembly is typed.
2 months ago
Anonymous
C says the result is a signed int so you interpret it as a signed int. What else can you do?
>It doesn't int -> uint. C puts an int in and takes an int out. This is really explicit in the standard
If this were true, then signed integer overflow wouldn't be UB, so you're just wrong.
If there is no overflow, you can trivially fit everything in an int so it's not a problem. >Also C has the exact same opinion about multiplication, i.e. that signed overflow is UB while unsigned overflow wraps. Even though the assembly is typed.
While I sort of agree that "imul" is "typed" - EE/CompEng people (the people that make the hardware) might disagree and just consider it an operation that does something slightly differently.
CS people really need to work with Engineers to make a "typed asm" IMO.
Furthermore, not all hardware has a distinction between multiplication of signed versus unsigned ints.
In principle, a true minimalist RISC instruction set wouldn't have a distinction, since you can always just write a program to do it.
2 months ago
Anonymous
>If this were true, then signed integer overflow wouldn't be UB, so you're just wrong.
Do you want me to dig up the part of the standard that says that addition coerces numerical operands into the same type and evaluates to a result of the same type?
Have you read what the standard has to say about this?
Ultimately this is UB because the standard says so. And I don't think your explanation even matches the original reason for making it UB.
2 months ago
Anonymous
>Do you want me to dig up the part of the standard that says that addition coerces numerical operands into the same type and evaluates to a result of the same type? >Have you read what the standard has to say about this?
And this doesn't apply to overflow. >Ultimately this is UB because the standard says so. And I don't think your explanation even matches the original reason for making it UB.
I'm not sure what their original reasoning was. But it certainly could have been related to types.
The issue of types creates a very real concern of "consistency" in a rigorous mathematical sense.
2 months ago
Anonymous
https://thephd.dev/c-undefined-behavior-and-the-sledgehammer-guideline explains how this came to be. (That post was written by an actual member of the standards committee.) It was originally because of differences between platforms, not because of any undefinedness within a platform. GCC and clang follow the letter of the standard to do something that cannot be justified based purely on hardware behavior but only based on the letter of the standard.
Could you read that post? It'll make things a lot easier.
[...]
By the way, downcasting a uint larger than INT_MAX is also UB in C
Sounds to me directly related to the logic for making overflow UB
IIRC this is implementation-defined and must either produce a value or trap. It's not UB.
2 months ago
Anonymous
>i'm too moronic to describe anything so please click this blogpost
pathetic
2 months ago
Anonymous
I summarized it in that same post and in earlier posts but if we keep going in circles I need to try something different.
>not because of any undefinedness within a platform
I mean, I'm not disagreeing that different machines can do different things.
But the fact that even in the very important x86 architecture, you don't really have a proper definition (because fundamentally, asm lacks types) just further proves the point. >do something that cannot be justified based purely on hardware behavior
I would not call signed-integer overflow well defined in x86. It's a freedom left to the programmer. >IIRC this is implementation-defined and must either produce a value or trap. It's not UB.
Yes my bad, it is implementation-defined. Not much better, and is definitely still related to signed overflow.
You want to put two signed integers in and get one signed integer out. That's what C says. Can we agree on this?
Is there more than one way to do this? Can you sketch out some pseudo-assembly that behaves other than -fwrapv?
2 months ago
Anonymous
>Can we agree on this?
Nope. The standard doesn't specify that this should happen on overflow.
add :: int -> uint seems reasonable enough to me.
2 months ago
Anonymous
>Nope. The standard doesn't specify that this should happen on overflow.
It doesn't specify behavior on overflow. But it specifies that you get a signed integer out. An expression has a single type that's knowable without evaluation. It's independent of the value. This is also the one you get from typeof.
The single type that results is required to be signed. Right? >add :: int -> uint seems reasonable enough to me.
If x is signed and y is signed then typeof (x + y) may not be unsigned. See pic related. The common real type is the type of the result.
2 months ago
Anonymous
>If x is signed and y is signed then typeof (x + y) may not be unsigned.
If x+y will overflow, it's UB.
It is completely valid for a compiler to promote all operands to uint in that case.
2 months ago
Anonymous
This UB happens at runtime. Types are known at compile time. typeof doesn't evaluate its argument at all. This is how static typing works.
But let's take a step back. How would you implement int add(int a, int b) in x86 assembly in such a way that it demonstrates your argument?
2 months ago
Anonymous
With void*
2 months ago
Anonymous
?
2 months ago
Anonymous
>not because of any undefinedness within a platform
I mean, I'm not disagreeing that different machines can do different things.
But the fact that even in the very important x86 architecture, you don't really have a proper definition (because fundamentally, asm lacks types) just further proves the point. >do something that cannot be justified based purely on hardware behavior
I would not call signed-integer overflow well defined in x86. It's a freedom left to the programmer. >IIRC this is implementation-defined and must either produce a value or trap. It's not UB.
Yes my bad, it is implementation-defined. Not much better, and is definitely still related to signed overflow.
2 months ago
Anonymous
>Do you want me to dig up the part of the standard that says that addition coerces numerical operands into the same type and evaluates to a result of the same type? >Have you read what the standard has to say about this?
And this doesn't apply to overflow. >Ultimately this is UB because the standard says so. And I don't think your explanation even matches the original reason for making it UB.
I'm not sure what their original reasoning was. But it certainly could have been related to types.
The issue of types creates a very real concern of "consistency" in a rigorous mathematical sense.
By the way, downcasting a uint larger than INT_MAX is also UB in C
Sounds to me directly related to the logic for making overflow UB
2 months ago
Anonymous
It doesn't int -> uint. C puts an int in and takes an int out. This is really explicit in the standard.
The assembly is indeed typeless but there's no sense in which it boils down to int -> uint. Certainly the implementation is not permitted to perform unsigned comparison.
Also C has the exact same opinion about multiplication, i.e. that signed overflow is UB while unsigned overflow wraps. Even though the assembly is typed.
Another thing about multiplication, a super minimalist CPU architecture would probably not have it at all.
As per ZFC arithmetic, all you need is the increment arithmetic operator.
2 months ago
Anonymous
Yes, the add instruction happens to be suitable for both signed and unsigned addition. So what?
C doesn't have int -> uint addition.
Look, what I'm trying to get at, is that signed integer overflow is "UB" in asm, because (in 8bit representation):
Is 10000000 an unsigned or a signed int8? Is it even an int8 at all?
Sure, the bits are well defined, but your interpretation of the bits is not.
2 months ago
Anonymous
C says the result is a signed int so you interpret it as a signed int. What else can you do?
2 months ago
Anonymous
My point is that the hardware is fully capable of expressing to you that a signed integer overflow has happened. It's C's inadequacy that makes it an "UB" within the standard it set for itself.
2 months ago
Anonymous
>3. Signed integer overflow being UB in C is because ASM has no concept of types.
Yes, but no. The CPU usually uses signed all the time and sets a negative flag based on the highest bit which the program will have to take into account when it is working with signed or unsigned values in the code.
The undefined behavior they talk about in C is that your program may be assuming only positive numbers in the integer, so when it wraps to a negative the program will do something unexpected.
2 months ago
Anonymous
>Instead, x86 CPUs simply discard the high-order bits that don't fit in the destination register.
But most importantly, they also flag the overflow so that your program can handle those higher values.
c has wrapping addition, and addition that can optimize assuming you aren't relying on wrapping behaviour. Pick whichever suits the current situation. This whole "issue" is nocoders not knowing how c works and proceeding to whine endlessly that it should work like their moronic understanding. BTW this is one of several features of c that even the rust morons copied because its literally that obvious.
>c has
Does it? Are you talking about GCC extensions or underspecified casting tricks or the cutting-edge unreleased C23 standard or what?
Or do you mean that unsigned wraps while signed doesn't? This is not obvious and not sufficient and nobody copied it
>Lightweight abstraction isn't zero weight so you should just do everything in Python
Jesus Christ just use whatever language works for you and quit harassing the rest of us.
>In contrast, the C standard says that signed integer overflow leads to undefined behavior where a program can do anything, including dumping core or overrunning a buffer. The misbehavior can even precede the overflow
It really seems the sort of shit they're worried about is, for example, if you are iterating through an array using a signed int for some reason, you could end up going to a negative offset or something.
if you aren't picking which registers are being used, then you aren't close to the hardware at all
register int ebp asm("ebp");
Trannies btfo'd again by the sharpness of the knives.
Works only as input for inline asm and with registers that don't get allocated by the compiler (TLS pointer reigsters).
no. If you tell the compiler -fwrapv it does signed integer over-/underflow as you'd expect.
why can't you people just add a fricking type into your languages saying that this integer is expected to overflow and this other one isn't
>just add ... into your languages
point of C is that it's stable you dumb fricking homosexual
And yet they add things sometimes
Actually they're about to add a solution for this though not in type form but as functions
Storing meta information in types?! Preposterous! What's next - a different type to discern a string from a pointer to a single character? A different type to signify a pointer that can be freed? A different type for different encodings? That's rust
C is meant to be simple, only fast and least variants of int allowed
ASM has no types. So C is closer to the hardware.
zig has wrapping operators, +% and -%, and even saturation operators, +| and -|.
>C is so shit you have to use nonstandard extensions to make it usable in modern software
what if I tell my compiler -fBRAAAP?
Basically, the person in the image is a moron.
No. CPUs do not wrap signed integer overflow.
Mine do
Nope.
What does x86_64 do?
ASM has no types.
We'll use 8 bits for simplicity.
add one to 01111111,
you get 10000000
10000000 has no type. Is it a signed into? Or is it an unsigned int?
Types are a spook invented by programming languages.
>Types are a spook invented by programming languages.
A spook?
If anything they're standards you use to decide what those collections of bits are representing.
Clearly what you did there is decided those 8 bits represent a single number because you could just as legitimately go.
>We add 1 to 01111111 and get 01110000+OF
>standards
Standards are spooks.
Don't listen to the other guy. if you add two 8-bit unsigned integers that result in a value greater than 255, the result will wrap around to a value between 0 and 255. This is the default behavior on x86 processors, as opposed to saturating the result to the minimum or maximum value.
The reason for this wrapping behavior is that it is the most efficient way to implement integer arithmetic in hardware. Checking for and handling overflow conditions would add extra complexity and latency to the CPU's arithmetic logic unit. Instead, x86 CPUs simply discard the high-order bits that don't fit in the destination register.
We're talking about signed integer overflow, not unsigned.
1. 255+1 is 0, not "any value"
2. Unsigned integer overflow is NOT undefined behavior in C.
3. Signed integer overflow being UB in C is because ASM has no concept of types.
Wrong again, x86 will happily sets off the V flag when signed overflow happens.
https://en.wikipedia.org/wiki/Overflow_flag
ASM may not have types but it is fully capable of setting flags when necessary.
Setting flags does not change the bits in the register.
It's up to the programmer to do as they wish with the flags.
The programmer can decide to ignore the flag if they want to.
Because `add` is a low level function that doesn't distinguish between signed or unsigned, all of these function signatures are correct:
add :: int -> int
add :: int -> uint
add :: uint -> int
add :: uint -> uint
Hence, types are a spook.
From C's perspective, with signed overflow, it can use add :: int->uint and downcast the results, which leads to a different value than using add :: int->int, hence UB.
>downcast
What does this look like on a bit level?
Also, how does stdckdint fit into this?
>What does this look like on a bit level?
When you add one to 01111111, you get 10000000
Take this meme code for example (pic related).
While `add` doesn't care about types in asm, jump does (also multiplies)
ja/jb for unsigned, jg/jl for signed
mul for unsigned, imul for signed
INT_MAX+1 can be interpreted either as add :: int -> uint or add :: int -> int
This is important because when doing the comparison, the compiler needs to decide whether or not to use ja/jb or jg/jl
When I say "downcast" I really mean "upcast" (it's a subtle difference).
Because `add` is a primitive function with undefined type signature, you can "upcast" all arguments to the comparison, and use ja/jb, thus the expression `INT_MAX + 1 < INT_MAX` is always false (and then you downcast the false truth value to int).
The hardware sets those overflow flags on unsigned addition as well - and all compilers (including Rust) discard the overflow flags.
>When binary values are interpreted as unsigned numbers, the overflow flag is meaningless and normally ignored. One of the advantages of two's complement arithmetic is that the addition and subtraction operations do not need to distinguish between signed and unsigned operands. For this reason, most computer instruction sets do not distinguish between signed and unsigned operands, generating both (signed) overflow and (unsigned) carry flags on every operation, and leaving it to following instructions to pay attention to whichever one is of interest.[2]
The issue is that the type signature of the `add` function is not defined at a low level. So Rust assumes the input type is the same as the output type ( add :: int -> int or add :: uint -> uint ) whereas this is not true in hardware.
Forgot pic
>Because `add` is a primitive function with undefined type signature, you can "upcast" all arguments to the comparison, and use ja/jb, thus the expression `INT_MAX + 1 < INT_MAX` is always false (and then you downcast the false truth value to int).
That's not how the C standard sees it, it has a firm opinion about whether you're doing the comparison using signed or unsigned operands. The problem is the addition, not the comparison.
You can also == INT_MIN if you prefer. Same story.
>The issue is that the type signature of the `add` function is not defined at a low level. So Rust assumes the input type is the same as the output type ( add :: int -> int or add :: uint -> uint ) whereas this is not true in hardware.
No, the issue is that the compiler assumes that INT_MAX + 1 won't happen and doesn't take that case into account at all.
>That's not how the C standard sees it, it has a firm opinion about whether you're doing the comparison using signed or unsigned operands. The problem is the addition, not the comparison.
Yes the standard says unsigned integer overflow is UB. Thus the compiler does whatever it wants.
Now I'm trying to tell you *why* it is UB.
The reason is because if you try to "define" the behavior, you lead to the language being "inconsistent" with casting semantics, all stemming from the fact that assembly `add` doesn't have a type signature.
You have to make an *assumption* about what the programmer wants (idempotence of types) in order to make the define the undefined behavior.
The truth is that *all* typed languages are not low-level, because ASM doesn't have types.
I really don't think casting has anything to do with it. Generally hardware has a fairly nailed down concept of signed arithmetic, and already had back then—it's just that there were some holdouts that still had one's complement.
x86 does in fact have an opinion about how signed arithmetic works. You can mix instructions if you want but there's an obvious choice for C (that AFAIK was already the obvious choice for the PDP-11).
>x86 does in fact have an opinion about how signed arithmetic works
Then why don't they add an `iadd` function?
`mul` for unsigned, `imul` for signed
`ja/jb` for unsigned, `jg/jl` for signed
`add` for unsigned... _ for signed
The issue is not "an opinion on how signed arithmetic works" - the issue is "well defined types"
At the end of the day, a signed int is just a *type* of int.
Yes, the add instruction happens to be suitable for both signed and unsigned addition. So what?
C doesn't have int -> uint addition.
No. iadd and add would do slightly different things.
iadd would flip the overflow flag on signed integer overflow whereas add would not
add would only flip the overflow flag on unsigned integer overflow.
In C and most languages, the infix addition operator is a primitive and usually corresponds directly to the typeless asm instruction, and hence it does indeed to int -> uint, because the assembly does exactly that as well (or really it doesn't have any type at all because assembly add has no type signature)
Assembly *could* embed types into the operations, like it does most of the time, but x86 does not do it for addition at the moment.
It doesn't int -> uint. C puts an int in and takes an int out. This is really explicit in the standard.
The assembly is indeed typeless but there's no sense in which it boils down to int -> uint. Certainly the implementation is not permitted to perform unsigned comparison.
Also C has the exact same opinion about multiplication, i.e. that signed overflow is UB while unsigned overflow wraps. Even though the assembly is typed.
>It doesn't int -> uint. C puts an int in and takes an int out. This is really explicit in the standard
If this were true, then signed integer overflow wouldn't be UB, so you're just wrong.
If there is no overflow, you can trivially fit everything in an int so it's not a problem.
>Also C has the exact same opinion about multiplication, i.e. that signed overflow is UB while unsigned overflow wraps. Even though the assembly is typed.
While I sort of agree that "imul" is "typed" - EE/CompEng people (the people that make the hardware) might disagree and just consider it an operation that does something slightly differently.
CS people really need to work with Engineers to make a "typed asm" IMO.
Furthermore, not all hardware has a distinction between multiplication of signed versus unsigned ints.
In principle, a true minimalist RISC instruction set wouldn't have a distinction, since you can always just write a program to do it.
>If this were true, then signed integer overflow wouldn't be UB, so you're just wrong.
Do you want me to dig up the part of the standard that says that addition coerces numerical operands into the same type and evaluates to a result of the same type?
Have you read what the standard has to say about this?
Ultimately this is UB because the standard says so. And I don't think your explanation even matches the original reason for making it UB.
>Do you want me to dig up the part of the standard that says that addition coerces numerical operands into the same type and evaluates to a result of the same type?
>Have you read what the standard has to say about this?
And this doesn't apply to overflow.
>Ultimately this is UB because the standard says so. And I don't think your explanation even matches the original reason for making it UB.
I'm not sure what their original reasoning was. But it certainly could have been related to types.
The issue of types creates a very real concern of "consistency" in a rigorous mathematical sense.
https://thephd.dev/c-undefined-behavior-and-the-sledgehammer-guideline explains how this came to be. (That post was written by an actual member of the standards committee.) It was originally because of differences between platforms, not because of any undefinedness within a platform. GCC and clang follow the letter of the standard to do something that cannot be justified based purely on hardware behavior but only based on the letter of the standard.
Could you read that post? It'll make things a lot easier.
IIRC this is implementation-defined and must either produce a value or trap. It's not UB.
>i'm too moronic to describe anything so please click this blogpost
pathetic
I summarized it in that same post and in earlier posts but if we keep going in circles I need to try something different.
You want to put two signed integers in and get one signed integer out. That's what C says. Can we agree on this?
Is there more than one way to do this? Can you sketch out some pseudo-assembly that behaves other than -fwrapv?
>Can we agree on this?
Nope. The standard doesn't specify that this should happen on overflow.
add :: int -> uint seems reasonable enough to me.
>Nope. The standard doesn't specify that this should happen on overflow.
It doesn't specify behavior on overflow. But it specifies that you get a signed integer out. An expression has a single type that's knowable without evaluation. It's independent of the value. This is also the one you get from typeof.
The single type that results is required to be signed. Right?
>add :: int -> uint seems reasonable enough to me.
If x is signed and y is signed then typeof (x + y) may not be unsigned. See pic related. The common real type is the type of the result.
>If x is signed and y is signed then typeof (x + y) may not be unsigned.
If x+y will overflow, it's UB.
It is completely valid for a compiler to promote all operands to uint in that case.
This UB happens at runtime. Types are known at compile time. typeof doesn't evaluate its argument at all. This is how static typing works.
But let's take a step back. How would you implement int add(int a, int b) in x86 assembly in such a way that it demonstrates your argument?
With void*
?
>not because of any undefinedness within a platform
I mean, I'm not disagreeing that different machines can do different things.
But the fact that even in the very important x86 architecture, you don't really have a proper definition (because fundamentally, asm lacks types) just further proves the point.
>do something that cannot be justified based purely on hardware behavior
I would not call signed-integer overflow well defined in x86. It's a freedom left to the programmer.
>IIRC this is implementation-defined and must either produce a value or trap. It's not UB.
Yes my bad, it is implementation-defined. Not much better, and is definitely still related to signed overflow.
By the way, downcasting a uint larger than INT_MAX is also UB in C
Sounds to me directly related to the logic for making overflow UB
Another thing about multiplication, a super minimalist CPU architecture would probably not have it at all.
As per ZFC arithmetic, all you need is the increment arithmetic operator.
Look, what I'm trying to get at, is that signed integer overflow is "UB" in asm, because (in 8bit representation):
Is 10000000 an unsigned or a signed int8? Is it even an int8 at all?
Sure, the bits are well defined, but your interpretation of the bits is not.
C says the result is a signed int so you interpret it as a signed int. What else can you do?
My point is that the hardware is fully capable of expressing to you that a signed integer overflow has happened. It's C's inadequacy that makes it an "UB" within the standard it set for itself.
>3. Signed integer overflow being UB in C is because ASM has no concept of types.
Yes, but no. The CPU usually uses signed all the time and sets a negative flag based on the highest bit which the program will have to take into account when it is working with signed or unsigned values in the code.
The undefined behavior they talk about in C is that your program may be assuming only positive numbers in the integer, so when it wraps to a negative the program will do something unexpected.
>Instead, x86 CPUs simply discard the high-order bits that don't fit in the destination register.
But most importantly, they also flag the overflow so that your program can handle those higher values.
c has wrapping addition, and addition that can optimize assuming you aren't relying on wrapping behaviour. Pick whichever suits the current situation. This whole "issue" is nocoders not knowing how c works and proceeding to whine endlessly that it should work like their moronic understanding. BTW this is one of several features of c that even the rust morons copied because its literally that obvious.
>c has
Does it? Are you talking about GCC extensions or underspecified casting tricks or the cutting-edge unreleased C23 standard or what?
Or do you mean that unsigned wraps while signed doesn't? This is not obvious and not sufficient and nobody copied it
Signed does wrap, but adding two positives and returning a negative is the undefined behavior.
So it doesn't wrap, unless by wrapping you mean -1 <-> 0 which is not how the C standard/abstract machine sees it
>feature
defect*. C23 finally adds checked_add.
x86 has data types.
Least pedantic bruce take
>Lightweight abstraction isn't zero weight so you should just do everything in Python
Jesus Christ just use whatever language works for you and quit harassing the rest of us.
>In contrast, the C standard says that signed integer overflow leads to undefined behavior where a program can do anything, including dumping core or overrunning a buffer. The misbehavior can even precede the overflow
It really seems the sort of shit they're worried about is, for example, if you are iterating through an array using a signed int for some reason, you could end up going to a negative offset or something.
its not that c doesnt wrap ints, its that its undefined behaviour
>all these mental gymastics around C's incapability to check the MSB
Thanks I'm sticking to Rust. It works.