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

22nd Century C

procedural.github.io

Post reply on HN
Print view View original

41–50 of 106 posts

Re: 22nd Century C

#41

Post by lgieron »

tbirdz wrote: post #21
mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

C's normal integer types work the closer to the way you want. When you say you're returning an int, you're not really specifying the exact size at all. For those who don't know, C's char, short, int and long data types aren't really "fixed size". The standard defines their order: sizeof(char) Now you may be thinking "sure the standard says they could be different, but they aren't really, a char is 8bit, a short is 16…

Is there any advantage in practice to using these loosely defined types (char, short, int, long) vs their precise counterparts?

Re: 22nd Century C

#43

Post by lake99 »

adrianN wrote: post #37
lake99 wrote: post #33

Earlier quoted context omitted.

> How do you port it to a machine without a 16-bit type? The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating. > The stuff about communicating with the outside world is quite different. I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is…

How does it make portability worse if you write your code in a way that doesn't assume anything about the size of your ints? If you don't know that your ints are 16 or 32 or 27 bits long you have to be more careful with checking for overflows, but if the code does that I don't see what problems you'll have when you port it to a platform with a different int size.

You can only check for overflows if you err in favour of larger architectures and declare all integers as "long int", and then check for overflows. Even the 8-bit compilers I have seen will allocate 32-bits for long int. And doing that will let the code remain compatible on smaller architectures, but it will hammer your CPU and memory usage. It's not a pleasant situation when you're struggling to save bytes.

Re: 22nd Century C

#44

Post by grive »

Mathnerd314 wrote: post #11

Too little too late. Rust is already taking over, by the 22nd century C will be dead.

Too little? That wasn't even an attempt, that's just shitty coding from someone having very bad habits in the language.

That's a blimp, a shitty blimp.

So it's not even touching on the subject of the competition with Rust.

Re: 22nd Century C

#45

Post by bprieto »

hellofunk wrote: post #36
pjmlp wrote: post #32

Earlier quoted context omitted.

On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that. On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.

When you consider how truly distant into the future -- in technological time frame -- 2100 is, you can wonder if Unix will even be around at that time. 2100 is double the lifetime of Unix from now.

Nassim Nicholas Taleb has an interesting point that for human creations the expected lifespan is the same as their previous life[1]. If a book is read 10 years after it's published, you can expect that it will be read for another 10 years.

So for C this would be 44 more years from now, but it gets another extra year for every year it survives, so it isn't far fetched to think C will be around in 2100.

[1] https://en.wikipedia.org/wiki/Lindy_effect

Re: 22nd Century C

#47

Post by TheNewAndy »

lake99 wrote: post #33
TheNewAndy wrote: post #23

Earlier quoted context omitted.

I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. Y…

> How do you port it to a machine without a 16-bit type? The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating. > The stuff about communicating with the outside world is quite different. I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is…

If you use "int", you know you have at least 16-bits to play with. Take some correct code that works with int16_t, and replace the "int16_t" with plain "int". What breaks?

1. If you are dumping it out to file or similar (i.e. assuming the layout in memory) then your code is no longer portable between different endian machines.

2. If you are relying on overflow behaviour, then your code is broken already (this doesn't apply to unsigned types, but using minimum width types and explicit mods/masks is likely going to be clearer code anyway).

3. The one place where you can't replace int16_t with int is in the case where you make use of the assumption that an int16_t can represent -0x8000 and you then port to a machine that doesn't use two's complement and int is 16-bits... I'm not aware of any such machine, but that is about the extent of it.

What type to use for a 29-bit CAN identifier? A "long" will do just fine. It is guaranteed to be at least 32-bits wide, and also to exist. Would you suggest a uint29_t?

Re: 22nd Century C

#48

Post by TheNewAndy »

lake99 wrote: post #43
adrianN wrote: post #37

Earlier quoted context omitted.

How does it make portability worse if you write your code in a way that doesn't assume anything about the size of your ints? If you don't know that your ints are 16 or 32 or 27 bits long you have to be more careful with checking for overflows, but if the code does that I don't see what problems you'll have when you port it to a platform with a different int size.

You can only check for overflows if you err in favour of larger architectures and declare all integers as "long int", and then check for overflows. Even the 8-bit compilers I have seen will allocate 32-bits for long int. And doing that will let the code remain compatible on smaller architectures, but it will hammer your CPU and memory usage. It's not a pleasant situation when you're struggling to save bytes.

You can't ever check for (signed) overflows in C - you can only prevent them. I'm not sure if I'm drawing a distinction you weren't intending to make (if so, then my apologies).

When you are adding signed integers in C, you need to prove that doing so can't overflow - knowing the exact width doesn't really help you here - just prove it for the narrowest possible width and you have proved it for all of them. In practice this isn't hard because either it is trivial to prove (e.g. incrementing a variable which is known to be small, or just plain modifying the code to put in explicit saturation/other logic for the cases where things get hairy)

Of course an 8-bit compiler is going to allocate 32-bits for a long int - the language requires that a long is at least 32-bits wide. If you had a compiler that didn't do this, then it isn't a C compiler.

Re: 22nd Century C

#49

Post by wott »

mieko wrote: post #14
lake99 wrote: post #12

Earlier quoted context omitted.

Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work. > Notice how smooth the 32-bit to 64-bit transition went? There are many reasons for that. For most PC work, a 32-bit int is more than large en…

> Looks like you haven't worked on embedded systems. I've deleted a defensive technical response to point out that these dismissive assumptions (usually unjustified) are pretty prevalent on HN, and I don't think it promotes level-headed discussion. It reads like "Let me discredit a stranger's background that I don't know, and then argue my opposing view." It creates a defensive mindset off the bat. Edit: I mean, your…

You shouldn't have worried: his points are not valid at all. Using fixed-width types across various embedded (as in "small and exotic") platforms is a nightmare for portability. There is no reason not to use standard integer types, providing you understood their definition. Use fixed-width types only when absolutely really needed; don't use standard types when you need fixed-width width, assuming they will be an exact size, and everything will be fine.

Re: 22nd Century C

#50

Post by TheNewAndy »

CamperBob2 wrote: post #35
TheNewAndy wrote: post #23

Earlier quoted context omitted.

I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. Y…

You have an int16_t? How do you port it to a machine without a 16-bit type? Hint: you're being done a favor by being forced to think about that.

Ok, now lets suppose you have done the job of thinking about it, and you are now up to actually acting on your thinking. What do you write?

You want:

- A single code base

- The code be compiled on the "I don't have a 16-bit type" machine, as well as on your amd64 machine and x86 machine. Having it work on a 24-bit machine might be nice too if you want bonus points.

- You don't want to waste memory on the crappy embedded chips where memory is scarce

As far as I'm aware, you can either: 1) Use fixed 32-bit types everywhere (you lose both 24-bit compatibility and waste memory... possibly not the end of the world) 2) Use non-fixed width types and tick all the boxes.

You don't really gain anything by using the 32-bit types (who cares if you know exactly how big it is - you only needed 16-bits anyway), but you do lose things.

Post reply on HN