Linux 5.13 Lands Support For Randomizing Stack Offsets Per Syscall

[Weasel]

In the context of a C compiler targeted for a typical x86_64 platform, what is the type of the numeric literal 0x123456789 and why? A question like this should be easy for a know-it-all like you, right...?

Fine, I'll amuse you, but only because this kind of thing actually can lead to security vulnerabilities (especially in 64-bit code).

To be fair, the answer does depend on the platform. That's because on Windows, Microsoft decided that "long int" is still 32-bit even for x86_64, so if you build with e.g. MinGW, it will be a "long long int". On (most?) other platforms it will probably be a "long int". And all of this because it doesn't fit into 32 bits of course, and no unsigned suffix.

[oiaohm]

To be fair, the answer does depend on the platform. That's because on Windows, Microsoft decided that "long int" is still 32-bit even for x86_64, so if you build with e.g. MinGW, it will be a "long long int". On (most?) other platforms it will probably be a "long int". And all of this because it doesn't fit into 32 bits of course, and no unsigned suffix.

https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

There are 5 64 bit data models that have ever been used. Out of those 5 data models only 2 have long int as 32 bit. LLP64 is only windows and ILP32 that is lInux x32 and arm64ilp32 ABI so ILP32 is only Linux thing.

LP64 for number of OS using is the most common. Yes Android devices and Mac OS in 64 bit are using LP64. The other 2 that have a long int as 64 bit
SILP64 being classic UNICOS I would hope no one would be still using that today in anything needing new software.
ILP64 was only used in one particular port of Solaris to SPARC.

Yes newer UNICOS and all other versions of Solaris are LP64.

Interesting point is across the 3 64 bit data models you can expect in usage LLP64, LP64 and iLP32 long long, int and short all line up on size.

Uncle H has asked you a C specification question Weasel that you have just got wrong. To be correct its a evil question C/C++ that lead to ANTI-PATTERN questions that really has nothing with the correct answer that leads to data size, Endianness and undefined compiler behaviour and standard behaviour that have nothing todo with the question asked.

Weasel GNU Multiple Precision Library (GMP) is a requirement of GCC because its legal to perform maths in the C standard on literals int larger than the data model of the system as long as that will generate a literal at build time. Sometimes C standards is what the hell.

what is the type of the numeric literal 0x123456789 and why< The correct answer under C standard is that is "literal int". Yes literal int is not int, not long, not a long long... by the C standard its own beast. He did not ask what happens when you assign that to a long or a long long. Literal int by C standard has no max size.

Yes the "In the context of a C compiler targeted for a typical x86_64 platform" is a total detraction part of the question you fell for hook line and sinker has almost no bearing on the answer. Yes the for typical x86_64 platform can be dropped. In the context of a compiler C the answer is the same no matter the platform because all the C standards define a literal int the same way.
Yes performing maths on a literal int at build time there is a catch output has to be a const "const short x = 0x123456789- 0x123456789;" is valid. I could have done more complex maths instead of just give a O. The literal ints could be like 10000 numbers long that when divided by each other give the result 2 and that would be valid be the value in the const.

Literal int with C is jump into wacky and explains why gcc need GNU Multiple Precision Library to handle int of any size at build because the C standard says literal ints can be any size and you can perform maths on those huge over sized literal ints as long as the maths are resolved in the compiler stage to produce a resulting const that is back inside the normal data int structure sizes if not you have undefined behaviour that can be a error or simple truncation at the compiler own choice.

[Weasel]

You didn't explain why though. What are the relevant sections of the ISO C spec?

I did. It doesn't fit into a 32-bit data type (which is what int is), so the next one is used (except stuff smaller than ints, because everything smaller gets promoted to int). I'm not gonna look up exactly where in the C spec this is mentioned, because I'm not a google script kid, I just know this because I actually code for a living. (no, I don't know exactly where in the spec it's mentioned off the top of my head, nor do I care)

[Weasel]

https://en.wikipedia.org/wiki/64-bit...it_data_models

There are 5 64 bit data models that have ever been used. Out of those 5 data models only 2 have long int as 32 bit. LLP64 is only windows and ILP32 that is lInux x32 and arm64ilp32 ABI so ILP32 is only Linux thing.

LP64 for number of OS using is the most common. Yes Android devices and Mac OS in 64 bit are using LP64. The other 2 that have a long int as 64 bit
SILP64 being classic UNICOS I would hope no one would be still using that today in anything needing new software.
ILP64 was only used in one particular port of Solaris to SPARC.

Yes newer UNICOS and all other versions of Solaris are LP64.

Interesting point is across the 3 64 bit data models you can expect in usage LLP64, LP64 and iLP32 long long, int and short all line up on size.

Uncle H has asked you a C specification question Weasel that you have just got wrong. To be correct its a evil question C/C++ that lead to ANTI-PATTERN questions that really has nothing with the correct answer that leads to data size, Endianness and undefined compiler behaviour and standard behaviour that have nothing todo with the question asked.

Are you dumb? He said x86_64. I didn't know about some other obscure archs, but from your list, Windows is literally the only LLP64 for x86_64 (not for x32 or other CPU archs).

[oiaohm]

Are you dumb? He said x86_64. I didn't know about some other obscure archs, but from your list, Windows is literally the only LLP64 for x86_64 (not for x32 or other CPU archs).

Windows 10 in WSL1 has LP64 because it emulating Linux and never did x32. So like it or not Windows is more than 1. The most common data model to be able to find is LP64. LLP64 of windows is the second most common with x32 coming in third.

As you said he said x86_64 not x86_64 windows. This should have been warning side this was a trap question and should not presumed that he was asking question where windows is relevant. Yes the OS was not relevant to his question because it was a question about the C standard with garbage around it and you fell hook line and sinker for the garbage.

[Weasel]

You know nothing about C if you don't have a copy of the spec to hand and the ability to quickly reference it.

That's kinda ironic because if you have to reference it then you actually don't know anything. Looking up things doesn't mean you know them, in fact it shows the opposite.

Coding for a living proves nothing - Sturgeon's law applies to professional programmers just as much as it does to amateurs and, to be honest, "90%" is a massive underestimation.

Oh, I agree, but generally not to C programmers.

You've also failed to state how exactly I was "wrong", although to be honest I no longer care to hear about it, since you've proven yourself to be an irrelevant midwit...

The conclusion I can draw from this is that you're the typical copy-paste developer. Looking up stuff other people wrote/google-fu must be your specialty. The script kiddie analog.

[Weasel]

Windows 10 in WSL1 has LP64 because it emulating Linux and never did x32. So like it or not Windows is more than 1. The most common data model to be able to find is LP64. LLP64 of windows is the second most common with x32 coming in third.

I think this is the first time someone actually referred to WSL as "Windows" as a platform. Like, legit, you're that special.

I'm guessing all the "Linux" userland you install there must be compatible with Windows platform (without using Wine), since WSL = Windows.

As you said he said x86_64 not x86_64 windows. This should have been warning side this was a trap question and should not presumed that he was asking question where windows is relevant. Yes the OS was not relevant to his question because it was a question about the C standard with garbage around it and you fell hook line and sinker for the garbage.

I'm not sure what your point is. I answered both for Windows and non-Windows.

Then you come in with "LLP64 is used in other platforms not just Windows" which is bullshit since for x86_64 it's only for Windows.

[oiaohm]

I'm guessing all the "Linux" userland you install there must be compatible with Windows platform (without using Wine), since WSL = Windows.

WSL1 does equal windows and can be used without a Linux userland. What was before WSL1 Windows Services for UNIX for Windows 7 also support LP64 on x86_64.

As long as there has been a 64bit version of windows there has be ways to run LP64 compiler built binaries on Windows.

Some of the reason why the lot of questions about LLP64 being taken for x86_64 windows API windows was the fact that the first 64 bit version of windows(this is not x86) was in fact LP64. There are some fun compatibility crap if you have todo so you can forwards port those application from source.

MS Windows and LP64 has done kind of a wacky dance over the years. All versions of 64 bit version MS Windows there is some way to run LP64 binaries only MS Windows x86_64 bit and arm64 have had LLP64.

You do need to be careful when talking about the Windows Platform over its complete existence.

Then you come in with "LLP64 is used in other platforms not just Windows" which is bullshit since for x86_64 it's only for Windows.

LLP64 has been in the Linux kernel at two point in history it was something that was put in for bridge interfaces with x32 that was latter given up on so 2 particular Linux kernel versions.

So you are like 99.999% right there is a 0.001% wrong here with only for windows but over time there are a handful of exceptions where LLP64 has been used in places outside windows. There are also a few embedded OS that went LLP64 as well. Most common example of LLP64 is windows but its not in fact the only example. Yes embedded OS 64 bit OS built with MSVC you can see where LLP64 come from here right.

[Weasel]

Not being in the habit of referring to the spec means you've probably never done it before.

Actually I do it all the time, especially for C++ since it's beyond complex. Not proud of it, though, unlike you, since it's 0.1% of anything interesting.

Anyone who is an expert in C knows knows for certain that this makes you an intermediate C programmer, at best. You don't realize this simply because of Dunning-Kruger. Sad.

There's a term for such C script kiddies. We call them "language lawyers". Not a proud thing to be, mind you.

Thing is, while C may be the best high level language overall, it's still just a HLL, a tool. You realize I code and especially debug in assembler too, right? Oh, but I mean, that's obviously out of your grasp, considering you just look up books.

[Weasel]

WSL1 does equal windows and can be used without a Linux userland. What was before WSL1 Windows Services for UNIX for Windows 7 also support LP64 on x86_64.

Why are you talking of things you've no clue of? WSL1 emulates the kernel, not the userland. WSL2 virtualizes the kernel (and uses the actual Linux kernel). In fact if it emulated the userland, what would be the point of it in the first place?

As long as there has been a 64bit version of windows there has be ways to run LP64 compiler built binaries on Windows.

Dude you are so fucking clueless.

The compiled binary has no notion of LP64/LLP64, since C types are erased. Assembly instructions have no notion of "long" or "long long" or even "pointer". It only matters in the source code when building for a given platform.

Right. I'm gonna stop wasting time with you.