we talked last week about what can go wrong with floating point numbers, so -- what can go wrong when using integers?
so far I have:
* 32 bit integers are smaller than you think (they only go up to 4 billion!)
* overflow
* sometimes you need to switch the byte order
* ?? (maybe something about shift / bitwise operations? not sure what can go wrong with that exactly)
I'd especially love real-world examples of things that have gone wrong, if you have them!
@b0rk Hmm, don't remember a specific case, though I'm pretty sure I've messed it up. Sticks in my mind because assembler usually has two different right shift instructions, for sign extending or not, and if using an unfamiliar language, I have to figure out which it does.
As https://learn.microsoft.com/en-us/cpp/cpp/left-shift-and-right-shift-operators-input-and-output?view=msvc-170 notes it's actually implementation defined in C/C++ whether right shift sign extends 😱 though AFAIK normal platforms do
@b0rk
It's been a long time since I've worked at that level, but signed integers typically presume a twos-complement representation; unsigned not. That can affect shift operations, arithmetic between operands of different types, and probably other things, depending on how they're implemented.
If you divide by two by shifting right, you want to shift in a zero for unsigned, and repeat the sign bit for signed, for example.
@b0rk @gdinwiddie say you want a signed 31 bit integer and a bool packed into 32 bits.
int x; // the packed 32bits.
x & 0x01; // the bool.
x >> 1; // the int.
More generally, you want that to optimize, for instance, division by powers of two.
@b0rk @gdinwiddie shift is a great cheap divide by 2^n ('cause divides can be *expensive*), but... this in test.c:
#include <stdio.h>
int main(int argc, char **argv) {
printf("%d\n", -4 >> 1);
return 0;
}
$ gcc -o test test.c ; ./test
-2
And Node gives similar results:
$ node
Welcome to Node.js v16.15.0.
Type ".help" for more information.
> -4 >> 1
-2
But Perl....:
$ perl -le 'print (-4 >> 1);'
9223372036854775806
To be fair. That's just pearl doing pearl things.
I recall that the 6502 instruction set has two types of bit shift operators. A rotate, or a pure shift. One just recycles all bits, the other shifts in a zero every time.
Nice. A Google site has an overview.
https://sites.google.com/site/6502asembly/6502-instruction-set/6502-instruction-set-bit-manipulation
@hlangeveld @b0rk
I never programmed the 6502, and find it odd they don't have an ASR (arithmetic shift right) which keeps the sign bit. That's what you need for 2's complement division by powers of 2.
Compare with the 6800 instruction set: http://www.8bit-era.cz/6800.html#ASR
Fair.
The 6502 was a more cost-effective chip compared to the 6800. I don't think integer division was a design target. Low cycle count operations were a strong objective.
@b0rk @gdinwiddie one that has been biting me since the very first time I tried to use Java is that bytes in java are signed. So 0xFF is a negative number, and when you do a right shift with >> it gets promoted to a _negative_ int, then masking back with & 0xFF to get the byte result is incorrect
byte b = (byte) 0xFF;
System.out.println(b); // -1
S.o.println(b >> 1); // -1
S.o.println(b >>> 1); // 2147483647
S.o.println((0xFF & b) >> 1); // 127
i was decidedly nervous when we were allowing a major contractor to reimplement a key accounting application in server-side Java.
In theory we had enough bits ...
(Alas IBM JVM didn't support the AIX Floating Decimal in firmware option, that was only for COBOL and RPG.)
@b0rk @gdinwiddie say you write the following bound check:
if (x < length - 1) { ... }
If you are using usigned, and if legth is zero, then the bound check is busted. This is a common error, and is very likely to pass code review.
How about adding signed versus unsigned.
@b0rk @nelhage it really shouldn't be, given that the practical behaviour is identical on 99% of target ISAs, but here we are.
this undefined status also causes some pretty horrible nightmares with overflow checks being optimised out by the compiler, since to a lot of compiler devs "undefined" means "an excuse for an optimiser pass"
@gsuberland @b0rk @nelhage It's more complex than just how it behaves on target ISAs. If signed-overflow is defined, then the compiler can't tell whether
for (int i = 0; i < max_count; i++) { ... }
will terminate (because i++ might make i smaller!), which blocks certain optimizations. So defining signed-overflow would slow down lots of programs that never overflow (!)
It's a nasty mess with no good way out, like many aspects of C/C++.
@b0rk the only thing that comes up for me regularly is that modulus doesn't work the same way across languages, when you ask for the mod of a negative number
which leads to "what the hell is even happening" type bugs
@b0rk or how floor division can trip people up with negative numbers, as it rounds to the smaller number
>>> -3.5 //2
-2.0
>>> 3.5 //2
1.0
Julia Evans
lo-fi socialist junk
Reed Mideke
Ash
deadalnix
George Dinwiddie
Dan Lyke
Till O'Rly 
John McFarlane
thinkbeforecoding
Henk Langeveld
bazzargh
Bill Ricker
antipode77
Rachel Greenham
Drezil 
Sami Samhuri
bryan newbold
doragasu
Nick Barnes
∴ esoterik ∴
Micah Walter
nelhage
Graham Sutherland / Polynomial
PulkoMandy
Nathaniel J. Smith
Thomas Leeper
Clark Breyman (he/him)
Farce Majeure
tef
Michael Sokolov
Brad
David Radcliffe
Boba Yaga