Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unsigned sizes: A five year mistake

c3-lang.org

Post reply on HN
Print view View original

111–120 of 153 posts

Re: Unsigned sizes: A five year mistake

#111

Post by tialaramex »

uecker wrote: post #108
tialaramex wrote: post #105

Earlier quoted context omitted.

Was this last part added or did I just miss it? Huh. > And the rust design with unsigned type where subtraction does not return a signed type but may fail at return or silently produce the wrong results, seems the worst possible design imaginable to me. You can ask for whatever you meant, and indeed asking for what you meant is crucial here because if we express ourselves we get the desired results. For example u8::b…

It was added, but immediately after the rest. I was just quickly refreshing my memory on what Rust was doing. I think it is a terrible design. If you want special function which protects you from errors in specific scenarios it is easy enough to do this in C. But I do think the C defaults are actually ok and having all the wrapper functions and boiler plate has its downsides too (What I would admit is bad in C are th…

Thanks for clarifying.

I cannot imagine we will end up agreeing, but it's good to understand why you made that edit

Re: Unsigned sizes: A five year mistake

#112

Post by pjmlp »

jstimpfle wrote: post #102
pjmlp wrote: post #48

Earlier quoted context omitted.

Java doesn't have unsigned as primitive types, because James Gosling did a series of interviews at Sun among "expert" C devs, and all got the C language rules for unsigned arithmetic wrong. Yes I miss them in Java as primitives, however there are utility methods for unsigned arithmetic, that get it right.

The way he conducted those interviews, and the conclusions he drew from them, may have been flawed. Because the situation now is that C has unsigned types and Java mostly has not. And despite all pitfalls especially around mixing signed and unsigned in C, unsigned types are very useful, I'd in fact say that for low-level programming they are essential.

Doesn't seem to affect the extent Java is used across the industry, including many workloads that in the last century companies would use C instead.

Books like Yourdon Structured Method were mainly targeted to business C back in the day.

Re: Unsigned sizes: A five year mistake

#114

Post by throwaway894345 »

uecker wrote: post #88
throwaway894345 wrote: post #81

Earlier quoted context omitted.

> The source of confusion is that unsigned is a terrible name. Unsigned does not mean non-negative. Its 100% complete valid to assign a negative value to an unsigned, it just fails silently. C’s implicit casts are tripping you up. Unsigned ints can’t be negative, but C will happily let you assign a negative signed int to an unsigned int variable, but the moment it is assigned it ceases to be negative. In serious prog…

In C your compiler can help you with conversions and if not, please use a better one. In this regard, C is a very pragmatic language, and hence for actual work it is a more "serious" programming language than programming languages which are based on some idealistic theory that pedantic typing will fix all your problems, but actually keep you from doing your job.

Sentence 1: The C compiler can help you catch implicit conversion errors.

Sentence 2: Catching implicit conversion errors is idealistic, pedantic, and prevents you from doing your job.

Great stuff. 10/10. No notes.

Re: Unsigned sizes: A five year mistake

#115

Post by Chinjut »

uecker wrote: post #87
jltsiren wrote: post #66

Earlier quoted context omitted.

I find it the opposite. Unsigned integers are intuitive, while signed integers are unintuitive and cause a lot of tricky bugs. Especially in languages, where signed overflow is undefined behavior. It's pretty rare to have values that can be negative but are always integers. At least in the work I do. The most common case I encounter are approximations of something related to log probability. Such as various scores in…

It is interesting that you find unsigned integers more intuitive. My experience (also with students, but also analysis of CVE give plenty of evidence) is that the opposite is true: signed integers in C are a model of integers which have a nice mathematical structure which people learn in elementary school. Yes, this breaks down on overflow, but for this you have to reach very high numbers and there is very good tooli…

The fixed-size signed types of C etc are no more the actual integers, and no less modular arithmetic, than the fixed-size unsigned types. They both implement the exact same modular arithmetic for +, -, and *. It's only for other operations (ordering comparisons, or / and % which in turn are defined in C in terms of ordering structure, as in rounding towards zero) where they differ. And in either case, that ordering structure is not one commonly encountered anywhere outside of the context of fixed size computer arithmetic.

Ask an ordinary person what 3 * (1/3) or 3 * (-1/3) should come to, and they aren't going to say any of the results that you get in C for either signed or unsigned int types.

Re: Unsigned sizes: A five year mistake

#116

Post by Chinjut »

jltsiren wrote: post #100
uecker wrote: post #87

Earlier quoted context omitted.

It is interesting that you find unsigned integers more intuitive. My experience (also with students, but also analysis of CVE give plenty of evidence) is that the opposite is true: signed integers in C are a model of integers which have a nice mathematical structure which people learn in elementary school. Yes, this breaks down on overflow, but for this you have to reach very high numbers and there is very good tooli…

I work in bioinformatics. The numbers are typically large enough that you either have to think about numeric limits all the time if you use 32-bit integers (or bit-packed arrays), or you end up wasting (tens of) gigabytes with 64-bit integers. I've also done a lot of succinct data structures, data compression, and things like that. When you manipulate the binary representation directly, it's easier to connect represe…

Signed ints are also integers modulo 2^n, as concerns +, -, and *. Both unsigned and signed ints have the exact same modular arithmetic structure, for +, -, and *. It is only for other operations (ordering comparisons, or / and %) where they differ, and on these operations, neither signed nor unsigned ints have any convenient algebraic structure commonly encountered elsewhere.

Re: Unsigned sizes: A five year mistake

#117

Post by Chinjut »

AlotOfReading wrote: post #110
uecker wrote: post #87

Earlier quoted context omitted.

It is interesting that you find unsigned integers more intuitive. My experience (also with students, but also analysis of CVE give plenty of evidence) is that the opposite is true: signed integers in C are a model of integers which have a nice mathematical structure which people learn in elementary school. Yes, this breaks down on overflow, but for this you have to reach very high numbers and there is very good tooli…

Modulo arithmetic is taught to American students as clock arithmetic in elementary school as well. Signed integers are better described as truncated 2-adics, which are definitely an advanced topic. It's basically a Greenland/Iceland situation. The complicated, difficult one is given a friendly name to trap naive programmers.

Signed ints are no more and no less truncated 2-adics than unsigned ints. Signed ints and unsigned ints are isomorphic as rings; they are both the ring of integers modulo some 2^n. It is only on other operations (ordering comparisons, or the / and % of C) where they differ, and in neither case do these operations have anything to do with 2-adics.

Re: Unsigned sizes: A five year mistake

#118

Post by rowanG077 »

uecker wrote: post #87
jltsiren wrote: post #66

Earlier quoted context omitted.

I find it the opposite. Unsigned integers are intuitive, while signed integers are unintuitive and cause a lot of tricky bugs. Especially in languages, where signed overflow is undefined behavior. It's pretty rare to have values that can be negative but are always integers. At least in the work I do. The most common case I encounter are approximations of something related to log probability. Such as various scores in…

It is interesting that you find unsigned integers more intuitive. My experience (also with students, but also analysis of CVE give plenty of evidence) is that the opposite is true: signed integers in C are a model of integers which have a nice mathematical structure which people learn in elementary school. Yes, this breaks down on overflow, but for this you have to reach very high numbers and there is very good tooli…

In Germany I learned module arithmetic at something like 13 years old in high school. I also find unsigned much more intuitive and in my code only use sized signed when I absolutely have to. Which is not often. Only in languages that offer automatic big Ints I just use ints, like Python and Haskell.

Re: Unsigned sizes: A five year mistake

#119

Post by uecker »

ncruces wrote: post #109
uecker wrote: post #92

Earlier quoted context omitted.

For signed overflow we have sanitizers, and for conversions C compilers warnings in C. Bounds checking can also be done with sanitizers (but is a bit more tricky). So no, I do not think the undefined behavior is really a big problem. In fact, it helps us find the problem because every overflow can be considered a programming error. Error due to unsigned wraparound are a much bigger issue, because the lead to subtle i…

Do you always run with those sanitizers in place? Just this week I've had a C compilers silently delete me an entire function call because of UB (infinite loop without side effects). Took me a day to figure out. So that's a problem for me. I don't think I've ever had an hard to debug issue in Go because of signed/unsigned wrap around. Particularly a memory issue. If anything, and there I guess I agree with the articl…

That depends. But some sanitizer are cheap enough that you can usually always run them.

Regarding infinite loops, C++ and C differ with C++ being more aggressive. But also compilers differ with clang being more aggressive. https://godbolt.org/z/Moe6zYKqo

In general, I do not recommend to use clang if you worry about UB. gcc is a bit more reasonable and also has better warnings.

Re: Unsigned sizes: A five year mistake

#120

Post by lucas_t_a »

pseudohadamard wrote: post #91
flohofwoe wrote: post #90

Finally a language doing the right thing :) My two ruls of thumb for C code are: 1. use signed integers for everything except bit-wise operations and modulo math (e.g. "almost always signed") 2. make implicit sign conversion an error via `-Werror -Wsign-conversion` The problem with making sizes and indices unsigned (even if they can't be negative) is that you'd might to want to add negative offsets, and that either r…

But a blog doing the wrong thing. Who decided that light grey on white was a great way to present text? For anyone else struggling to read it, Ctrl-A will make it legible.

it did decide that javascript is necessary to enable correct contrast
Post reply on HN