>int
>long
>DWORD
>__int32
>int32_t
>_BitInt(32)

so much this

>>105572058 (OP)
>byte
>hword
>word
>dword
>qword
>flt
>dflt

#if defined(_WIN32) || defined(WIN32)
typedef signed char int8;
typedef signed short int16;
typedef signed int int32;
typedef signed __int64 int64;
typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned int uint32;
typedef unsigned __int64 uint64;
#else
typedef signed char int8;
typedef signed short int16;
typedef signed int int32;
typedef signed long long int64;
typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned int uint32;
typedef unsigned long long uint64;
typedef unsigned int DWORD;
typedef unsigned short WORD;
#endif

>>105572058 (OP)
dword and qword be gemmy with it albeit

>>105572058 (OP)

cat /usr/include/ctype.h

>>105572058 (OP)
>Number

>>105572117
Rust has like 20 times the TROONS though its crazy, one of the most TROON infested communities and that says a lot considering almost every community is infested by them these days.

>>105572117
Wtf is "unsigned long int" and how is it different from "unsigned long"?

>>105572117
C is actually portable, not a two architecture chump like rust.

>>105572272
Lol! Two architecture chump, I really really like that, mind if I copy/paste it?

>>105572237
they're identical, it's just an alias for the same type

>>105572237
They are defined as different types with different minimal values according to the standard.

>>105572328
>they're identical
There is no such guarantee according to the C standard.

>>105572272
Actually, C has no guaranteed support. GCC targets are all equivalent to Rust Tier 3 support. There is no automatic hardware testing as it is in these two architectures in Rust you mentioned.

>>105572187
Rent free

>>105572378
>There is no such guarantee according to the C standard.
long and long int are identical

>>105572378
*rolls eyes*
I'll use my void main() and call it a day

>>105572389
Ah you are right. I misread and thought you meant 'long int' vs 'int'

>>105572378
They are absolutely 100% guarantee to be identical in every single meta representation and behavior. Literally defined in C89.

>>105572416
Yup see >>105572411

>>105572378
>Actually, C has no guaranteed support. GCC targets are all equivalent to Rust Tier 3 support
gcc != c my retarded friend

Oh, it's just a rustranny thread. The unnatural and astroturfed promotion of that language should prove it glows in the dark.

Go buy your CryptoAG while you're at it.

>>105572701
OP here, I hate rusttroons and I hope they choke on their dilator and die

>>105572701
OP here, I'm trans btw

>>105572501
If you haven't noticed, I made a clear distinction between C and GCC in my post.

int used to be 16bit

>>105572058 (OP)
type is not needed bc i am not a npc of pokemon world.

>>105572237
"int" is the default in C, and can be omitted when other type specifiers are present (e.g. "register n;" is the same as "register int n;"). The modifiers "unsigned" and "signed" and "long" and "short" can appear in any order, so these are all fine:
unsigned long x;
long unsigned x;
long int unsigned x;
unsigned int long x;
And "long" can appear twice, again in any order, so you can have declarations like:

long unsigned int long x;

And that's the same as "unsigned long long".

>>105574704
Don't know how I messed up the code box, sorry. I thought I formatted it right.

volatile long my_penis;

>>105574780
Still can't believe this guy created linux

>>105572272
Let me guess. You ""need"" more.

int and DWORD are all I use. I think it would be better to call it DWORD/QWORD/etc. by default

>.word is 4 bytes in gas regardless of architecture

>>105572089
>nword

>>105572184
based

>>105576650
This is why I always avoid that terminology. It's been coopted to mean "32-bit", so I'd rather just say "32-bit" or "Pointer sized".

>>105572117
I don't get why Rustroons claim it's more "readable" than the C family when it takes away basic English keywords and replaces them with those shorthand versions. It's also a lot less effort to type tokens with just letters like "int" or "char" from the home row than it is to type something with both letters and numbers like "i16" or "u32". It sounds like a silly thing to nitpick about but when you're typing lots of code, that extra strain between constantly switching between the home row and the number row can tire out your fingers much quicker.

>>105579152
>he thinks there aren't 16bit pointers

>>105574704
Thank you for your explanation. Very helpful! I have a book on this but I can't be arsed to read it all. It's little snippets of knowledge that I come on /g/ for, thanks.

>>105580418
Like this*

>>105576650
>The GNU Assembler, commonly known as gas or as
What the actual fuck is wrong with freetards?

>>105579705
Because "integer" is vague, i32 is not.

>>105572272
Relatively speaking, yes.

>>105581052
I concur
and i32 is still easier than int32

char[N]

>>105581052
D's solution of just making ints guaranteed 32 bits etc works pretty well.

long long long long long long long long long long long long int

>>105581473
Nobody uses D
Nobody

>>105581576
yeah but it has some good ideas

var nigger = 1488