Hacker News Reader

Comment by smallstepforman | Hacker News Reader

C’s biggest sins (also inherited by C++):

- unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.

- aliasing pointers being restricted by default (ie an alias keyword should have been added). Performance matters. All these benchmarks which show something beating C or C++ are mostly due to dealing with aliasing pointers. C++26 still doesnt have standardised restrict keyword.

There are more but I understand the logic/usability/history behind them. The above points should have been addressed in the 80’s.

View on HN

Not the error "handling"? The array implementation? The weak type system? The barebones-macro-system? The nearly unuseable standard-library? The standard itself, a 750-page-tome you have to memorize, lest C is allowed to erase your hard drive?

C is sin incarnated.

In my opinion error handling in C is great. It forces you to actually think about it, deal with them as close as possible and makes you write it in a forward compatible way. Much better than exceptions were you never no what one might throw in another version.

> The barebones-macro-system?

The CPP is a different language and designed that way so you can use another language that suits you better, most don't do that, because the default is fine.

Arrays decaying to pointers is probably the biggest non-platform specific design oversight.

As you said, it's easy to see where it came from, but it should've been fixed long ago.

> but it should've been fixed long ago.

Is 27 years for you not long ago enough? That's more than a generation away and closer to the invention of the language than today.

Worse than that, lets remember that WG14 rejected Dennis Ritchie proposal for fat pointers, and the C authors decided it was more fun to keep their own way with other programming languages than try to improve C from WG14.

https://www.nokia.com/bell-labs/about/dennis-m-ritchie/varar...

I think we are talking past each other. I was saying that passing an array with a size to a function was standardized 27 years ago, asking if that isn't long enough. Sure, some may don't like how it was standardized, but it is possible.

Beside the sibling comment about this specific proposal, I also think that fat pointers don't belong in the C standard. There is nothing in the C standard that says that pointers on the abstract C machine don't come with the allocated size, in fact the behaviour is described as if they do. Pointers are essentially scoped by allocation. All that is missing is code for that in a C implementation, the language allows that just fine.

I read through the RFC and I think it's fair it was rejected, because this was ultimately a half-measure, with severe usability restrictions.

Fat pointers are clearly a way to deal with arrays (and also get "slices" and non-zero terminated strings for free!), but it's just not possible to retrofit them into the language without breaking existing code.

Which systems in the 70s or even 90s would have had good hardware support for all these lengths? I think overall perhaps its better that the thing named int works on both the arduino and my amd64 otherwise we might needlessly need to rename all types for each platform to fit the most natural type lengths there. Imagine the 32 bit to 64 bit transition under those conditions.

All of them, through software implementation, as assembly programmers have done since forever.

You simply choose the integer type that your problem or task requires. If the hardware genuinely can‘t cope with it (performance), you reevaluate your requirements, define new constraints and choose new types. This is basic requirements engineering, which C only made more convoluted.

I think overall it's better to provide "natural" default types but also have had something like stdint.h. But then again mandatong even a stdint.h that early would have made writing implementations quite difficult. I think it was and is an alright tradeoff.

But it doesn't work. You use an int to hold milliseconds, it works on your machine, and when compiled for Arduino (16–bit int) it wraps around every minute.

We have stdint in modern systems so when the length of a type is a hard requirement then we can use whatever type or software emulate a larger word. Otherwise I think keeping the default types for things like eg number of elements seems alright.

So you've backtracked from most variables, to number of elements.

For number of elements there's size_t. So again, when are "natural types" the right answer?

When the C was invented? I feel it'd have been much more burdensome and inhibited the authors of various compilers if they had to write software or otherwise emulation of all these lenghths on the archs of the time. Still today I'd say, you cited size_t, I think that's the most important type, otherwise we shouldn't make most uses of integers as named fixed lengths unless we are specifically performing some mathematical operation like finite field arithmetic where the bit length matters or as you noted you know your problem size might be large enough that some archs machine words are too small. Otherwise I don't see why we shouldn't just default to natural lengths. Otherwise we need to write different int types for each arch and that doesn't sound nice unless we explicitly see a reason to.

So you write a timer app that counts in milliseconds in an int variable, and it works on your machine where that's 32 bits. I compile it for Arduino, and I can't set a timer for longer than 32 seconds in the future. Isn't that a problem? You shouldn't have used int — you should have declared a maximum time value (99:59:59) and how many bits are needed to store that value.

In what situation is plain int sufficient? If your values always fit in 16 bits, it works, but what's special about 16? A value that goes from 0 to 100 only needs 7 bits, so int is not efficient there either, you should have asked for 7 bits which would round up to 8 on most platforms. Arduino is an 8–bit platform that requires several instructions to add 16 bits to 16 bits — int isn't the most efficient type.

A ms beat in arduino sounds a bit demanding, idk how much a software based 32 bit would eat into the beats budget but I did say if we know the bounds of the problem explicitly that's a valid case for known fixed bit lengths.

The Arduino framework has a millisecond timer always running unless you turn it off.

Tbh I am finding it a bit hard to think of a use of integers that either isn't a length or a mathematical operation, so I gotta say it does narrow things down.

Bit fields? (Assuming one's not using a struct)

Good point. Yes if we need more than 8 flags we might need to consider one of the fixed length types.

Why 8? Some computers have smaller types. C has smaller types, as bitfields, but they're second–class. Why not just always specify the bits you need?

If you think 16 is probably enough and don't want to calculate, then specify 16.

The length of a type is always a hard requirement.

> - unspecified default type sizes. Should have had i8, u16, i32, u64, f32, f64 from the beginning.

I strongly disagree. The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have. Does this variable represent the size of an object, an address, a difference or just a random positive integer? Then use size_t, uintptr_t, ptrdiff_t and unsigned int respectively. Why should I care what exact sizes these are? I hate that modern (system) languages completely throw away that concept. "I want a unsigned integer" "oh, you mean u32" "No! I really mean an unsigned integer."

Also when I do want e.g. 32 bit available, there is no reason, I need to use a suboptimal 32 bit wrapping behaviour when I don't need it. The correct type to use for computation for that would be uint32_fast_t and the implementation chooses what makes sense to use for this.

How will you know if your integer type is adequate for the problem at hand, if you don‘t know its size?

Choosing the right type is a function of signedness, upper/lower bound (number of things), and sometimes alignment. These are fundamental properties of the problem domain. Guesstimating is simply not doing the required work.

C specifies minimum sizes. That's all you need 99% of the time. I'm always annoyed by the people who assume int is 32-bits. You can't assume that in portable code. Use long or ensure the code works with 16-bit ints. That is how the type system was meant to be used. int was supposed to reflect the natural word size of the machine so you could work with the optimum integral type across mismatched platforms. 64-bit platforms have mostly abandoned that idea and 8-bit never got to participate but the principle is embedded in the language.

This doesn't really agree with this OP statement:

> The programmer should rather prescribe intent and shouldn't constantly think about what size this should exactly have.

You still have to constantly think about size! Except now you have to think about _minimum_ size, and possibly use a too big data type because the correctly sized one for your platform had a guaranteed minimum size that's too small for what you want to do.

It does agree with what I intended to say. The values a type needs to be able to represent are very much part of the intent of a variable. What the programmer doesn't need to specify, is with what bit pattern and what exact bits these values are going to be represented. There are use cases where you in fact do want to do that, but then that implies that you actually care about the wrapping semantics and are going to manipulate bit patterns.

The idea is mostly that we shouldn't worry. The user of the lib on an arduino will feed it arduino sized problems and the amd64 user will likewise larger problems. Again I think just think of the transition from 32 to 64 bit. Most ranges are "input"/"user " dependent and it would have been needlessly messy to have to even with automatic conversion help rewrite say every i32 to i64 or which ones to convert.

That's size_t. What about counting milliseconds?

As I said, today when it really matters we can use stdint. But I feel it would have been too burdensome to mandate on the standard in the early days of C.

Like fucking what? If you do any TS.. you just use unsigned whatever fastest type you have on targeting platform, and you do NOT care. 16bit? wrapping at 1 min? Thats eternity even on 2MHz 6502... You just count and substract to get difference. Usually you are <1000ms range.. so wrapping is not a problem..

If you target about 32bit and 16bit, you either think about and using long (on 16 bit is more costly) or you just count seconds.. Or ticks.. or whatever you need.

cool, it's an app that lets me set a 2 minute timer and counts in milliseconds, oh what's that, it doesn't work right on Arduino

Then use long.. Does Arduino CPU cannot do 16bit add/sub with carry? wtf?

I'm not writing the app. The app was written according to your preferred design and I'm compiling it for Arduino. You say to just use int because it always has enough bits, then you say to sometimes use long because int might not have enough bits.

I dont know the indented use. If you need delay or difference, 16bit is more than enough. If you writting generic clock w/ ms accuracy, it will be not enough. You either split it or use larger storage. Its not rocket science...

There is a platform where int has less than the prescribed 16 bits? How much does it have then, just 8bit or something weird?

Arduino has 16-bit int, so the timer app will work up to 32.767 or 65.535 seconds, that is less than two minutes.

When you choose unsigned int for that type, you compare against UINT_MAX and return an EOVERFLOW, ENOMEM, EOUT_OF_RANGE or whatever you like when someone sets a timer greater than that. Or you choose another type, i.e. unsigned long which is guaranteed to take values to at least 4294967295. I happen to program for the Arduino platform recently and milliseconds in the Arduino API are typed unsigned long.

If your decision is that you really want to store all 32-bit values then you use uint_least32_t or uint_fast32_t depending if you are also resource constrained.

Right, so you can't just use int.

Your problem demands a certain number of bits. Counting milliseconds in a month needs 32 bits. It's not just a random number.

Then you use an integer type that has at 32-bits? uint32_fast_t for computation, uint32_least_t for storage, if you are resource constrained.

This is never not the case. You always need to specify the number of bits.

Reply on news.ycombinator.com