21–30 of 41 posts
h = (h I suspect the author of the hash function thought this wouldn't add more than 4 bits: h = (h But as one should know, two n-bit numbers can create an n+1-bit result when added due to carry.
Earlier quoted context omitted.
For all its advantages, C is unfortunately so ripe with stuff that any sane guideline would recommend not to do that it can hard to follow through. Though I agree in this case this would never have passed a modern review.
There is a lovely piece of text in the third version of PNG specification: "PNG four-byte unsigned integers are limited to the range 0 to 2^31-1 to accommodate languages that have difficulty with unsigned four-byte values" [0]. Gee, I wonder what languages those may be? [0] https://www.w3.org/TR/2022/WD-png-3-20221025/#7Integers-and-...
Earlier quoted context omitted.
The code isn't making assumptions, the programmer is.
That’s all the same. Then the code the programmer is writing is wrong because the programmer’s assumptions are wrong. Potato, potahto.
If the code is wrong as in undefined behavior, then the compiler can and maybe should try to prevent it. If the programmer is wrong about the code, then the compiler can't and definitely shouldn't try to prevent it.
In short, the compiler can't prevent this
int is_empty(char* s) {
return strlen(s) > 10;
}
is_empty(NULL);ELF is way too complex and not really adapted anymore. We should start to deprecate DT_NEEDED and make dlopen/dlsym/dlclose (maybe, dlvsym) hard symbols in the loader. And game devs should stop using main() as some genius glibc dev did add a new libc_start_main version in 2.34. Namely, any game executable linked with a glibc from 2.34 will refuse to load on system with a previous glibc. Actually, game binaries should…
There is a huge amount of tooling relying on DT_NEEDED for dependency detection. I am not so sure about general purpose Linux, but in the embedded Linux world this would be a disaster. The Yocto system for example would no longer be able to determine the runtime dependencies of generated binaries. For the static library part, this is such a beaten down argument I just will not argue. I hope you enjoy re-installing yo…
Mixing static linking with dynamic linking was not a good idea in the first place, and I mean it.
ELF should be "fixed" about this, but to be sincere and honest, I think a lot could be removed from ELF on modern systems.
Maybe it is not worth to fix ELF, but to go something like NGELF which would be excrutiatingly simpler and cleaner than ELF, namely real and disruptive innovation.
Earlier quoted context omitted.
The code isn't wrong, it's platform dependent. It's the assumption that it that is wrong. The code itself if is fine.
But if the code was written with intention to be platform-independent, and turned out to be platform-dependent... it's the programmer who wrote it is wrong, not the code itself? Or do I misunderstand you completely?
Let's say I know the Swedish language, in which "öl" means "beer", and I travel to Germany to partake in the Oktoberfest celebrations. I arrive and in Germany and immediately try to order a beer and try to say "One Beer Please", but not mastering the language I say "Ein Öl Bitte" (meaning "one oil please"). I don't think the that's a bug in the German language, and the sentence itself is perfectly good German. It just doesn't say what I think it does.
I would like to to beyond my current understanding, which is basically “they’re effectively one-way functions”, and be able to participate in discussions of articles such as this one.
ELF is way too complex and not really adapted anymore. We should start to deprecate DT_NEEDED and make dlopen/dlsym/dlclose (maybe, dlvsym) hard symbols in the loader. And game devs should stop using main() as some genius glibc dev did add a new libc_start_main version in 2.34. Namely, any game executable linked with a glibc from 2.34 will refuse to load on system with a previous glibc. Actually, game binaries should…
The glibc version problem is not new, you have never been able to rely (safely) that a version of glibc exists that works for your compiled program. This is an example of why containers exist, but unfortunately the problem isn't ELF - it's glibc!
And for that matter, glibc also ships the loader. This is the part that's mildly insane.
Earlier quoted context omitted.
There is a huge amount of tooling relying on DT_NEEDED for dependency detection. I am not so sure about general purpose Linux, but in the embedded Linux world this would be a disaster. The Yocto system for example would no longer be able to determine the runtime dependencies of generated binaries. For the static library part, this is such a beaten down argument I just will not argue. I hope you enjoy re-installing yo…
You missed the point: using "shared objects" would have to be explicit with "dlopen/dlsym/dlclose'. Mixing static linking with dynamic linking was not a good idea in the first place, and I mean it. ELF should be "fixed" about this, but to be sincere and honest, I think a lot could be removed from ELF on modern systems. Maybe it is not worth to fix ELF, but to go something like NGELF which would be excrutiatingly simp…
dlopen and friends are function calls that you cannot evaluate build time. Actually not even at runtime as they are by nature dynamic and conditionally dlopen is a thing. Any shared object dependency tracking would be impossible or a new standard would be required.
Also dlopen is a POSIX standard. ELFs are used in many other places non POSIX.
> Mixing static linking with dynamic linking was not a good idea in the first place, and I mean it.
Why was it not a good idea? This happens all the time, especially the code that is at the very first executable address of the elf until some libc prepares things is arguably statically linked.
> [...] but to go something like NGELF [...]
Sounds interesting. Could you paste a link? I could not find it in google.