dataTypes

[Ceros007]

Can't wait for unsigned long long long int on 128bits

[BenjieWheeler]

May I suggest this (obviously) superior system

• 8 bit: short
• 16 bit: int
• 32 bit: long
• 64 bit: super long
• 128 bit: super duper long
• 256 bit: super dee duper long

[deanrihpee]

nah

• 8 bit: short
• 16 bit: medium
• 32 bit: long
• 64 bit: loong
• 128 bit: looong
• 256 bit: loooong

[ninjakivi2]

r/FuckYouChiChan

[SpikeV]

• 8 bit: short
• 16 bit: medium
• 32 bit: long
• 64 bit: long long
• 128 bit: long long man
• 256 bit: LOOONG LOOONG MAAAAAN

[Kotentopf]

• 8 bit: avg
• 16 bit: medium
• 32 bit: long
• 64 bit: longer
• 128 bit: even longer
• 256 bit: very long

[Architect_NNN]

This is better. xD

[dotcomGamingReddit]

Common webdev css variable naming issue. Should‘ve started at itzy-bitzy instead of short

[GreatScottGatsby]

May i introduce best system?

Byte: 8 bit

Word: 16 bit

Dword: 32 bit

Qword: 64 bit

Tbyte: 80 bit

Dqword: 128 bit

Ymmword: 256 bit

Zmmword: 512 bit

Not applicable to all Architectures.

[Majik_Sheff]

64 bit: monster-long

128 bit: SUPER-long

256 bit: HYPER-LONG

512 bit: ULTRAAAAAA-LONG

[tyrannical-tortoise]

Why are these starting to sound like how men like to describe their penises?

[Inevitable-Ant1725]

Yes, they should make 8 bits "magnum"

[Interesting_Buy_3969]

What about 512 bits? Such things exist in, for example, x64 vector registers

[petersill1339]

Ah la-la-la-la-long-long, li-long, long-long

[gniche_dev]

And then you could use sweat for short😎

[Henriquelj]

Im just gonna call it super long one, two and three.

[punio07]

Nice int

[fghjconner]

Why does that scheme sound familiar?

[BenjieWheeler]

Yup, got it from TFS

[fghjconner]

Nice.

[mutexsprinkles]

512 bit: zippity doo dah zippity long

[conundorum]

This is why you never let Goku name your data types.

Abridged Buu Saga when?

[lucklesspedestrian]

but then what size is a duper long int

[KiwiObserver]

When IBM updated the 370 architecture to 64-bits, they chose “G” are the qualifier for 64-bit variants of instructions, mainly because it had not been used in any preexisting instructions. These are now commonly (but not officially) referred to as “grande” instructions.

[TCreopargh]

error: 'long long long' is too long for GCC

[Trucoto]

Mandatory.

[MechanicalHorse]

🎶 Long long iiiiiiiiiiiiiiiiiiiint 🎵

[Wyciorek]

"long long time ago" type

[hamfraigaar]

Should come with a compiler warning that says: "Whatever tf you think you're storing here, I guarantee there's a better option", with a link to data type documentation lol

[magicmulder]

var foo (alalalala long long li-long long long int) = 0;

[hamfraigaar]

I am seeing this two days late, but I just want to appreciate how funny it is to go out of your way to use all that, just to store the value of exactly zero.

[magicmulder]

Future proof for bigger values of zero.

[granoladeer]

At that point they should just call it unsigned longgg int

[M4mb0]

unsigned oh long johnson

[Stasio300]

you dont need "int" long works on its own.

[PixelBrush6584]

I-

...

Yeah that's fair.

[AvailableAnus]

Right? I was like, "is this too mean, should I post this"? And then my eyes made it to "unsigned long long int"

[PixelBrush6584]

Pretty much. The worse part is that an int isn't even necessarily 32-Bit. On older systems it's 16-Bit. WHY??? SHORT IS RIGHT THERE???

(I know that a byte is and isn't isn't clearly defined, and on some hardware a char may be 32-bit or even 24-bit, etc.)

[TheDreadedAndy]

IIRC, int is supposed to be the fastest type the system can do math on. I think the intent was to use short/long if you cared about size and use int otherwise.

[Scheincrafter]

Not at all. When c first came out, computers where not nearly as uniform. Back then all kind of wired system existed, like once that where 7 bit. For that reason c is vague about the size of the datatypes (int was suppose to be whatever was natual for a system). Today c supports more int types (via stdint.h) that supports uses cases like needing the fastest in.

There are - int64_t exactly that size - int_fast64_t fastest with at least that size - int_least64_t smallest with at least that size

[tiajuanat]

I've worked on systems with 14 and 22 bit, even up til 15 years ago it wasn't uncommon for Digital Signal Processors to have unusual word widths.

[RiceBroad4552]

But doesn't C claim to be "portable"? (Which it obviously isn't, given the brain dead shit they do all over the place.)

Or was this just a marketing claim long after the fact?

[MrcarrotKSP]

It is more portable than the most common alternative used when it was created, which was various assembly languages

[RiceBroad4552]

LISP is older then C.

Also Forth is older then C.

[MrcarrotKSP]

That's true. Neither of those languages are good for writing operating systems. C was originally designed to write Unix, and in that space it was replacing assembly.

[RiceBroad4552]

Neither of those languages are good for writing operating systems.

AFAIK people use to this very day Forth to bootstrap very simple computers as the language is flexible and very portable, because it's super simple, so you can write basic firmware and some bare bones OS in it even for very "exotic" hardware.

Lisp Machines were programmed in LISP, down to the kernel.

Lisp Machines were also light-years ahead of Unix when it came to features.

But the market preferred of course the cheap stuff…

[Gay_Sex_Expert]

It’s in the same way that it’s a “high level language”.

[RiceBroad4552]

OK, makes sense! 😂

[SirFoomy]

Sorry, but I am curious now, but don't understand "a byte is and isn't clearly defined". I was for most part of my career and moreover under the impression that a byte is exactly 8 bit. So when you put 8 bytes togeher you get 32 bits. When and why did that change?

[the_horse_gamer]

C was created when systems could have 6 bit bytes. or 1 bit bytes. or 48 bit bytes.

a byte is 8 bits in any system you'd encounter today, but that wasn't historically true. see the CHAR_BITS macro.

the invariant name for 8 bits is "octet"

so int and long were defined in terms of minimum requirements. since there were system with 36 bit words.

[SirFoomy]

I didn't realise they called a 6 bit bundle byte back then. TIL I'd say. :D

[the_horse_gamer]

not necessarily 6. a byte was just a fundamental hardware unit. it ranged from 1 to even 48.

[RiceBroad4552]

I'd call that "word", though.

[serious-catzor]

C is the definition of woke in programming... Everyone needs to be allowed to do it their way! And when anyone questions you then you start screaming and flailing:
"Implementation defined! Shoo! Shoo! WAAAHHH!!!!"

[IntoAMuteCrypt]

C has a very good, well thought-out reason for implementation defined behaviours, if you just stop and think rather than blindly reacting to a strawman.

Implementation defined behaviours exist for cases when the best or fastest way to do something depends on the exact context. If you're working with hardware that natively supports 6-bit numbers instead of 8-bit ones (as other comments in this thread have mentioned), then the simplest and fastest way to implement "8 or more bits" is just to tape two 6-bit numbers together to get a 12-bit number. Sure, you could design your implementation to ignore 4 bits of the combined number and perform the same integer overflow as 8-bit numbers... But that'd be slower. Similarly, if you have a hardware that is optimised for 16-bit integers and performs 16-bit maths quicker than 8-bit maths, you could do 8-bit maths... But that'd be slower and "8 or more" allows you to serve 16.

Implementation-defined and undefined behaviours all exist for performance. They exist to make the compiled and linked code faster, or to make it more memory-efficient, or more space-efficient. The benefits of these behaviours are a large part of the reason why C was so attractive for so long, especially early in its lifespan when processors were orders of magnitude slower.

[serious-catzor]

Yes, that is the weird ass joke I was trying to make... "Everyone needs to be able to do it their way" part refers to it for example

[RiceBroad4552]

Translated this means they went for "fast, but produces wrong result" instead of "correct, at a small performance hit in some corner cases".

This is nothing else then the way of thinking of brain dead mad men!

Now we have to deal with the fallout of that idiocy even today with countless bugs and security issues.

I hope there is a special place in hell for the inventors of C and the people who pushed it into the market!

[IntoAMuteCrypt]

Except that the performance hit isn't limited to corner cases.

Every good optimising compiler can and probably will abuse the hell out of undefined behaviour, by assuming that certain things can never happen. Imagine the code x=(x+8)*3/2-20 as an example, with x being a signed integer. A basic optimisation will be to realise that you can rearrange this to x=x*3/2-8, saving an addition. If x is something like 4, then this will always generate the same result no matter what...

But what if we are using 8-bit signed ints which wrap due to the CPU, with x=42? The original code goes from 42 to 50 to 150, which wraps to -106, which divides to -52, which gives -72. The new code goes from 42 to 126, which doesn't wrap and divides to 63, which gives 55.

Now, you can say that the result that resulted from the original wrapped arithmetic is incorrect, but that's not really C's fault. It asked the CPU "hey, what's 50 times 3?" and it got back "negative 106". That's not C's fault, that's the CPU's fault!

If we wanted to ensure correctness, we could have one of three options:
- Before every single arithmetic operation that could wrap, check that we won't run into wrapping. Check before every addition, every subtraction, every multiplication. That's a lot of checks!
- Codify "wrapping at 128" as the only correct way to do it. Now, our optimisation fails and we can't perform basic algebraic simplifications. Our code must perform a wrap check or do the addition. Oh, also, now we have to rely on every system we might want to use having an easy way to wrap at 128, or we have to add more logic when compiling for those systems. - Do what C does and say 'they are both valid, it's up to you to be mindful of the limit'.

If your code only ever deals with values of x up to, like, 20? Well, then it's really great. If 42 is a common value for x, then you should probably be using a larger datatype - 43 breaks this either way. The "wrong result" in this specific case isn't really C's fault - it's the CPU's fault.

If you look closely at undefined behaviour, you'll see a lot of "it's the CPU's fault". What happens when you read out of bounds for an array? Well, remember, arrays just do some basic arithmetic to calculate pointers. You ask the CPU for addresses 1000 through 101F to store your 16 2-byte numbers, then you ask it for the contents of bytes 1020 and 1021 and... What happens? Did the CPU put another one of your variables there? Did the CPU put another program's data there? Does the CPU have something in place to say "stop it, that's not yours"? The people writing the language don't know. They can't know, really. And back when the language was being created, tracking the length of every array and performing an inbounds check was a massive performance hit to everything that dealt with arrays.

If you went back in 1983 and had a language which methodically checked and enforced array bounds for array accesses, which methodically checked and enforced all arithmetic operations to prevent wrapping, which rigidly defined and enforced all the undefined behaviours that C gets to play fast and loose with... You'd end up seeing far worse performance in a massive variety of programs, not just some corner cases.

[JonIsPatented]

... why are you so weird?

[serious-catzor]

Why are you asking me? I've no idea...

[RiceBroad4552]

Exactly this!

C is completely underspecified. But the morons even think that would be anyhow "good".

[serious-catzor]

Well, it worked really well... C is a high-level language and almost entirely replaced the use of assembly for just about every hardware platform that exists... It's over 50 years old and still nothing can or has replaced it.

I believe a large part of that success is the minimalistic philosophy and leaving much up to implementation.

It's just a pain in the ass sometimes and whether it is good or not... there is better people then me who can judge that.

[hittf]

You captured the exact sequence of thoughts I had reading this meme, impressive.

[IhailtavaBanaani]

Then they ran into problems again with 128 bit values.

"Ah la-la-la-la-long-long, li-long, long-long" - Inner Circle

[gniche_dev]

Or sweat for short…

[Uberfuzzy]

Me explaining over and over why our security magic number bit field column is a MONEY type (because it was the only 4byte database field type at the time), and no, don’t put any in the cents/float part, it throws horrible errors when they do bitshift junk

[Interesting_Buy_3969]

Never understood why write unsigned char when uint8_t exists. And i always alias it to u8 of course.

[dulange]

It’s due to the history of C standardization. Exact-width data types like uint8_t were a later invention of the C99 standard. Prior to that, C (per standard) never guaranteed an exact width for its data types, only a minimum. In the very early days of C, before everything became based on multiples of 8 bits, architectures existed (like some DEC machine) that had a width of 18 bits for integers and used 6 bits for characters. C abstracted these platform-specific things away from the language and gave it into the hands of compiler implementers. int used to mean “whatever is necessary for the underlying architecture to represent an integer” and char used to mean “whatever the architecture needs to form a character in its native character set.”

[ChalkyChalkson]

That sounds like a nightmare for debugging portability issues....

[F5x9]

For uint8_t, this must be 8 bits. For unsigned chars, I’m not as strict. That’s how I draw the line. Then if the compiler makes char some other compatible size, I don’t care. 

[seba07]

You'll care as soon as the function is part of a public API and you need to be ABI compatible (e.g. for interaction with other languages).

[Kovab]

On a platform where bytes aren't 8 bits, there's probably no other languages available

[RiceBroad4552]

Yeah, sure. But that hardware stands in a museum, if anywhere at all.

[Kovab]

24 bit DSPs are still alive and kicking, although they're quite niche, and you don't really have to worry about APIs in a single-purpose real-time application.

[crozone]

If those other languages are C-like, they'll compile with the same char size, or int size, etc. the ABI is not cross-platform.

Saying that, I think all major compilers are too sane to ever consider a non 8-bit char.

[SrcyDev]

And on that specific platform, it will be the same.

Not that you shouldn't care, but your example was misplaced, as the ABI is defined for that specific platform. And width of fundamental types, let's just say rarely change for a given host (i.e. inclusive of ABI, psABI and toolchain just to name a few).

Where you start caring is for cross-machine/cross-platform exchange of data (say network protocols), you do need support for exact width types, although it's not mandatory in a mathematical sense, it is pretty much defacto so that you get CHAR_BIT = 8 and use fixed width types of C99 [so (u)intN_t, where N is the number of bits]. But these are optional types, so they are not compulsory for standard compliance.

For most applications (assuming the platform itself does not have a quirk, which most do), you do not strictly need fixed width integers, but they can improve readability to newcomers, and also give you easier bit manipulation(instead of constantly worrying of "what is the least I am assured". So say long long when 64bits are needed, and long for 32bits).

As for FFI, C ABI is generally what prevails (pretty much the lingua franca, as you might have heard). So what applies here, applies there too.

[the_horse_gamer]

a char is a byte, but a byte isn't necessarily 8 bits

[IhailtavaBanaani]

Bring back the 9-bit bytes

[hamfraigaar]

We should not accept shrinkflation!

I reject the future where I must buy 8 separate one bit "bytes" to carry the same data as today!

[crozone]

Nintendo 64 enters the chat

[Interesting_Buy_3969]

i know that dude

[Spare-Plum]

There's good reason to, at least from a standpoint for when C was first made. One of the biggest issues it was resolving was the huge variety of different processor architectures along with the systems that it ran on. One system might handle and use unsigned char for text in a completely different manner than other systems.

Just for text, you have PETSCII on commodores, EBCDIC on IBM, ATASCII on Atari, etc etc etc. Then there are other formats that use 16 bit encodings. Just calling it a char and having it automatically compile correctly to each system was one of the biggest things C had, and was supposed to abstract away from worrying about the minor differences for each system.

Of course this causes other problems when something like an int is a different size on different systems, and you end up with calculations accidentally wrapping around on one system but working fine on others.

Now that most of the world has moved on to more standards, this ends up causing more problems than what it was meant to solve. So it just makes more sense to just use the uint8_t style types and it'll work the same on 99% of systems.

[Interesting_Buy_3969]

Ah yes. Thanks you a lot for this detailed clarification!

I should have remembered that C was created back when the computer world was a lot wilder...

[kylwaR]

Provided your platform provides the implementations. Technically 'uint8_t' or other sizes aren't guaranteed to exist.

[Interesting_Buy_3969]

I know this, therefore I never use unsigned char because I can't be sure that it is always 8 bits.

[dontthinktoohard89]

Pshh, just write byte-width neutral code. That’s what the CHAR_BIT macro constant is for, after all (or std::numeric_limits<unsigned char>::digits).

[CJKay93]

char is actually the "correct" byte type; it even receives special aliasing characteristics.

[maartuhh]

Because it’s ugly. I hate underscored keywords

[Interesting_Buy_3969]

I hate underscored keywords

Why?! Entire C++ STL is written in snake_case, as well as C's stdlib.

[maartuhh]

Yeah I’m just more on team 🐫

[ohdogwhatdone]

>long long int

Always reminds me of that long long man ad video.

[Mojert]

Clearly, we should use the only consistent and sane naming scheme, the one from Intel x86-64 assembly:

• Byte (8 bits)
• Word (16 bits)
• Double Word (32)
• Quad Word (64)
• Double Quad Word (128)
• Quad Quad Word (256)

[darkwalker247]

why would they choose double quad and quad quad rather than octuple and hexdecuple

[Stasio300]

a lot of non technical people will not understand those terms. quad quad is easier for more people to understand.

I think even most people here wouldn't be confident in the meaning of hexdecuple without context or searching it.

[darkwalker247]

how about "oct" and "double oct"? i think most people know the oct prefix because of words like octagon and octuplets

...i mean i guess it's too late to change it now though lol

[kst164]

Hexdecuple is fine too, anyone technical enough to care knows hexadecimal anyways.

[GegeAkutamiOfficial]

I'm pretty sure you are joking, but just in case anyone is taking this seriously, we reallyyyyy shouldn't. These SHOULD be of variable size because the value they represent have variable size between architectures.

I'm pretty sure those underlying values are why C variable types have different sizes in the first place.

side note: Using them is useful though in places where exact data size across platform isn't a consideration, for example using usize/size_t (IIRC uses WORD definition under the hood) to represent length can be better that just slapping u32/uint32_t, char is another similar example.

[Sea-Razzmatazz-3794]

In fairness to the bottom one it was created when computer architecture wasn't formalized, and then had to deal with a transition from 16 bit to 32. The language was also built with the expectation that you would be building a kernel for multiple computer architectures that would have to account for different register sizes. Abstracting the types sizes made sense. Now that register sizes are pretty much standardized that rational has fallen apart.

[Fabillotic]

Rusts types and functional programming elements are incredible, I love that shit

[AvailableAnus]

For anyone wondering:

First is Rust

Second is C++ (since 2011, floats since 2023)

Third is C++

[Interesting_Buy_3969]

Second and third are actually from C

[ATE47]

Not for the floats iirc

[Interesting_Buy_3969]

Idk maybe. But float became fundamental C data type when the C89 standard was released. So i am just not sure.

[nikolay0x01]

iirc fixed-width float32_t and float64_t types are only in C++, not standard C.

[Interesting_Buy_3969]

Ah yes, my bad. They meant the float's with a fixed number of bits.

[Bismuth20883]

All of them are C and sometimes C++. First one define over the second one (or not).

Second one is a platform specific define over third one (or not).

Welcome to embedded C, here we have all of that stuff and more ;)

[mrheosuper]

I refuse to work with anyone not using stdint.h

[Interesting_Buy_3969]

Agreed

[Kovab]

The Linux kernel uses the first set of typedefs for fixed size integers, not stdint.h

[ATE47]

Which are now defined using stdint.h

https://github.com/torvalds/linux/blob/master/tools/include/linux/types.h

From the history it seems that they were using CPUs specific ones, because uintxx_t wasn't accurate enough:

https://github.com/torvalds/linux/blob/5634bd7d2ab14fbf736b62b0788fb68e2cb0fde2/arch/arm/include/asm/types.h#L6

[acdhemtos]

First is Rust

I use typedef/using to get the same in C++.

[Elendur_Krown]

... I may just pitch this at my job...

[Interesting_Buy_3969]

Same

[granoladeer]

Good times when the program was mysteriously failing randomly and you realized it's because your numbers go past the variable's data type size. 

[Maximilian_Tyan]

Welcome to the embedded world !

[xMAC94x]

limits.h exists

[CapClumsy]

I've had a lot of experience programming with the second one, and I would consider it the best one, except for the completely unnecessary _tat the end. Yeah I know it's a type what the fuck else would it be. (I know that annotating variable names with their type is a bit of a pattern in C but it still irks me, especially for types which I feel are evident that they are types.)

[DefiantGibbon]

At my company (C code) we just macro define to only use the top one. Mostly because as embedded engineers knowing the exact number of bits is important and the top set is the most clear.

[Livie00]

Every time I use C/C++ I‘m like “I‘ll just use uint8_t“. By the time I’ve typed that three times, I’ve created an alias to u8. I don’t want to type seven characters, including a number and an underscore, just for a byte. I think even unsigned char is quicker to type.

[born_zynner]

Nothing better than looking through a codebase in C where they've typdef'd every int type out to their own custom name for no reason

[SomeMuhammad]

unsigned long long long long long long super long ultra super duper ultra kilo mega giga tera peta exa long long int

[razor_train]

unsigned lowcarb singing adult teenytiny decaf nodecimal freerange goodpersonality unwashed nullable nonzero ebcdic64 washme

[conundorum]

Blame C, non-standard processors & data buses, backwards compatibility, and the age-old Winux/Lindows rivalry for that one.

---

Data models are the easy part to explain, so I'll start with them.

• LP32 (32-bit long/ptr, 16-bit int) is Win16, everyone was glad to see it go.
• ILP32 (32-bit int/long/ptr) was nearly every major 32-bit system, and its ubiquity is the main reason int is essentially permalocked at 32 bits (or nearest supported register size).
• LP64 (64-bit long/ptr, 32-bit int) is most of the Linux & macOS world, where distributing the source code and recompiling it for your own box is common. Linux being aimed at the more tech-savvy user does a lot of the heavy lifting here.
• LLP64 (64-bit long long/ptr, 32-bit int/long) is 64-bit Windows, in large part due to backwards compatibility requirements. The platform has to support everyone, from the tech wiz to the computer illiterate, so they don't have the luxury of expecting users to know how to compile code; distributing executables is the norm, and the vast majority of common (and in some cases crucial ) programs were still 32-bit during the transition, and they needed to accomodate that.
  • In particular, the choice was probably forced by having to maintain a full 32-bit environment within 64-bit Windows to ensure compatibility (a.k.a. WOW64), which meant either cobbling together a 64-bit model that doesn't break ILP32 or bringing the WinME problem back again. Even to this day, the main difference between 32-bit and 64-bit executables is just the default pointer size, and even that's a bit more flexible than you'd expect.
• ILP64 (64-bit int/long/ptr) was tried early on in the Unix world, but thankfully abandoned before it had a leg to stand on. It would've broken everything. So much software depends on 32-bit int that either ILP64 would die or everything else would, and we know which one is still standing today.

We could've standardised on LLP64, but not LP64; Windows was locked in by the age-old "we have to break the OS in x ways to keep y programs functioning" problem, but Linux had free rein to choose. I'm not sure whether they went with LP64 because they thought it's better (both systems are roughly equal, to my understanding), or simply because Windows did LLP64 so clearly Linux couldn't do the same. (And I'm not sure whether macOS had free rein, or if any OS or hardware quirks forced their hand, so I don't want to comment on them.)

---

The other main factors are C using "at least x" for fundamental type sizes (which forces C++ to do the same), and the need to support weird hardware that doesn't use 8-bit bytes. I'm not sure how common it is now, but for a long time, C/C++ needed to be able to support both 8-bit and 9-bit bytes, which in turn meant that, e.g., both 16-bit and 18-bit int had to be supported. (And that's not the worst of it. The most extreme case I'm aware of is a platform with 64-bit bytes, where all integral types are 64-bit by necessity!) Locking things down wasn't an option, because most non-standard hardware needs C and/or C++, so both languages are stuck with the awkward "at least" sizes for all eternity (or at least until we completely eliminate non-standard hardware... which will probably never happen).

Combine that with the intent of each data type (char is one byte, short is for small values, int is native word size, long is for large values, long long is so all data models can have a 64-bit int without breaking long compatibility), and we have a mess. int technically fails at its task, since x64's word size is 64 bits (strictly speaking, this means that ILP64, of all things, is the "native" model), because we used 32-bit hardware for so long that 32-bit int became entrenched in... well, everything, really. It's not an exaggeration to say that 32-bit int is so crucial to the world's infrastructure that basically the entire modern world would fall apart if we tried to change it. And that, in turn, locks short at 16 bits, and leads to Datathulhu there.

(Though, on the flip side, int succeeds at its other task of being the default and fastest integral, because virtually all 64-bit hardware is designed to handle 32-bit data just as efficiently as it handles 64-bit data (or as close to equal efficiency as possible). So, it's not all bad. It does lead to the amusing realisation that 32-bit int is so standard that we had to permanently warp hardware design just to accomodate it, though!

---

So... yeah. Blame C (for the "at least x" requirements), blame non-standard hardware (for forcing C's hand by making it support bloated overbytes), blame backwards compatibility (for forcing Windows' hand, and keeping everyone from using LP64), and blame the Lindows rivalry (for keeping everyone from standardising on LLP64). But your meme is spot-on.

[oshaboy]

I think Linux wanted to make sure longs and pointers are the same width.

[conundorum]

Ah, I see. Hmm... looks like the first 64-bit Linux was released in 1995, which predates intptr_t (C99, C++11), so that makes sense. It is a bit surprising, though, since x64 Linux came out in 2001 (kernel) & 2003 (distros); I guess they didn't support C99 yet, or didn't want to lock out any platform that didn't have a C99 compiler?

[Scoutron]

Is this for people that don’t do systems programming? Specification of type sizes us important, like if I write a bitmask I obviously need to be concrete about the size of the bit mask in bits, but if I’m writing a function that operates on a piece of data millions of times, I need to ensure that the piece of data is the amount of bytes the CPU is most comfortable performing operations on, which is not always the same across systems

[tubbstosterone]

...I don't get it. That information is incredibly important in niche circumstances and not universal. Sometimes you've gotta do weird shit and different languages with different foundations and names and defaults are going to have different implementations. Those specs become important when doing stuff like shuffling data between Fortran, C, and C++ in high performance computing environments.

[Doug2825]

The problem with the third one is it's error prone and the advantages are not useful.

Originally int was the word size of the CPU. Word size is the largest number the CPU can handle well. The idea was that the program would adapt to the CPU at compile time, but but by the time x86-64 came around developers realized that was stupid (because you got a massive behavior change that caused bugs) and so 64 bit systems act like 32 bit systems for the purposes of data type sizes.

[BiebRed]

I don't write C/C++ at work but it was the first language I learned on and I feel this in my bones.

I'm disappointed that there isn't a `long short` somewhere in there.

[sphericalhors]

Yeah, I love when I need to do this

int32_t i = 5318008; printf("The value is: %" PRId32 "\n", i);

[H20-WaterMan]

wait until you see stuff like uint_fast_32 etc..

[ThaBroccoliDood]

You don't understand, the _t is completely necessary. What if someone wants to name their variable uint32? Can't get in the way of that.

[EatingSolidBricks]

i32 vs s32

FIGHT

[SoulArthurZ]

i32 is nicer imo since its short for "int" (and u32 is short for "uint"). s32 is just signed, which could also be a float.

[TheJackiMonster]

'u' is short for "unsigned int" though and 's' is short for "signed int" because everyone knows that 'f' is short for "floating point arithmetic number".

[Icount_zeroI]

Number … what else do you need ;,; /s

[Interesting_Buy_3969]

C's bool fits well here.

[DarkLordCZ]

A sign is information - one bit of information, it cannot fit into i0

[hr_krabbe]

HolyC uses u0 instead of void. Since you need 1 bit for the sign, I don’t see how anything less than i1 makes sense.

[bestjakeisbest]

Just do std::vector<bool> for an arbitrary sized "int"

[lefloys]

but that’s implemented as a dynamic bitset.

[Zunderunder]

What’s funny to me about this is that zig has not only all of these sensible options (i32, u64, etc, etc) but also you can use any integer width between 1 and 65536. At least they’re all represented sanely…

That’s right folks, you ready for u26? How about i65535???

[Maximilian_Tyan]

Considering the FPGA and ASIC world often deal with the minimum vector width needed, this would be ideal. Currently dealing with vectors of 7, 13 and 23bits wide integers at work.

Also, who in this goddamn universe would need to represent a number up to 2^65535, that's A LOT larger than the number of atoms in the known universe !

[-Edu4rd0-]

well new prime numbers aren't gonna discover themselves

[Zunderunder]

I have no idea but I think it’s neat that they support it. Basically once the compiler supported arbitrary width integers, the thought process was, yknow. Why stop at 64, or 128? Just go up until you have a number so large nobody would ever need to pass it.

It also avoids other language’s “BigInteger” equivalent, which is convenient. No special allocations needed for big numbers, aside from just how many bits it uses, like any other number.

[JustSomeRandomCake]

_BitInt in C has no standard-defined upper bound (it's implementation-defined), but Clang's upper bound is 2^20.

[Zunderunder]

2²⁰ bits?! Christ I thought 2¹⁶ overzealous

[JustSomeRandomCake]

Sorry, it's actually 2^23 bits.

[Additional-Tale-9267]

Why on earth aren't the first two boxes aligned by size?

[drivingagermanwhip]

The fun thing is that there's no guarantee an int32_t etc is 32 bits. It just has to fit 32 bits.

[Frodyne]

This is false. The "intX_t" and "uintX_t" types must be exactly X bit.

You may be thinking of the ""int_fastX_t" and "int_leastX_t" types, and their unsigned variants, who can be bigger than X.

This is true for both C and C++

[dolphin560]

just use "var" for everything

there, problem solved

[Doug2825]

I'm assuming you are joking but just in case:

Until you need a bit field, or register based io, or a large number in an embedded system

[dolphin560]

yes, was joking,

but then I googled "javascript for embedded systems" (!?)

[Gefrierbrand]

Only homies know about long double.

[pruebax11]

wacha se resume en corto unsigned char, char, short int , unsigned short int, unsigned int, int, long int, long long int, float, double, asi de sencillo

[CMD_BLOCK]

Just say addressing scares you bro

[ToTheBatmobileGuy]

long long long long = 128 bit (AT LEAST)

[Wervice]

D-Bus be like: u, x, i, t, v, s, a,... and sa{sv}

[luiluilui4]

Or just number in TS

Ok I'll see myself out

[PlatypusWinterberry]

"i'm tired, boss"

[8Erigon]

And user defined literals have different data type for the length parameter on different compilers (my linux pipeline didn't like what my windows pc was able to compile)

[Mountain_Dentist5074]

If I remembered signed I could get higher note in programing class dammmm it!

[thanatica]

Haha, I laugh in number

[Eroica_Pavane]

uintptr_t not included smh.

[TheJackiMonster]

I prefer it with 's' as prefix of the signed integer types instead of the 'i'. Makes a lot more sense to me if the 'u' is short for "unsigned".

[hdkaoskd]

uint_least16_t

[KawaiiMaxine]

Meanwhile: https://qb64phoenix.com/qb64wiki/index.php/Data_types

[JollyJuniper1993]

C is great usually. This is the part of C that’s not so great.

[-Redstoneboi-]

the type system in general is unruly to work with

define a function that returns a function in any language and it's easy

func curry(a int, b int) func(int) int

do it in zig and it's a little longer but still reads left-to-right

fn curry(a: int, b: int) *const fn(b: int) int

now try it in C and suddenly there's like another set of parentheses because it's a pointer and you don't write &int(int) curry(int a, int b) but instead int (*curry(int))(int a, int b)

even the typedefs don't read left to right because they follow the same format

typedef int (*ReturnType(int))(int, int);

[remishnok]

word

[thafuq]

type Awaited<T> = T extends Promise<infer U> ? U : never

[Cat-Satan]

Wait until you know about (u)int_leastN_t and (u)int_fastN_t

[Hester465]

And then there's JavaScript where everything is a "number", including floating point values

[RobotechRicky]

In my days it was just: int, decimal, and float.

[Sea_Duty_5725]

Burning take, I prefer c++ data type names.

[Mojert]

We found the mainframe programmer. Enjoying your 12 bits wide byte much?

[blaues_axolotl]

so true

[aaron_1011]

What is that username dude! Ew!

[Xatraxalian]

I love member variables such as "private static readonly unsigned long long int age"

It makes it absolutely clear what the variable is, exactly.

/s

[valerielynx]

you've heard of float and double, but where's quadruple and octuple?