@neko @Suiseiseki quoth ISO/IEC 9899:1999 6.7.2.1.13, it is technically legal,
A pointer to a structure object, suitably converted,
points to its initial member (or if that member is a bit-field,
then to the unit in which it resides), and vice versa. There
may be unnamed padding within a structure object,
but not at its beginning.
but please refer to picrel:
@icst @sam as much as i would like this to be the case, it is not. just look at the vulnerabilities from openssl or any other codebase with a bunch of manually written assembly, it’s always the c parts. c exclusively has numerous terrible design decisions that it forced upon others, that were originally not found in any other languages and were forced upon them due to compatibility. (i wasnt talking about performance. sam was probably talking about something else, like janky cross compilation support)
for GC free high performance languages, there’s a lot of experimental languages that employ the notion of linear types, rust uses a restricted variant of it called affine types, thats how it guarantees ownership and memory integrity. if you disregard them as “memelangs”, i have no words for you. [counterargument 1, unsafe rust: you can also write *(volatile int *)0=0;
in c, this is not an argument. you cant really catch this in c either if it was slipped in unless you actually run it or spend hours on valgrind. rust just makes it obvious from the beginning that you could be doing something wrong. also safe rust basically means it’s mathematically proven to not cause memory errors (memory leaks on the other hand are very hard to define, this is for later). counterargument 2, hardware failures: sure, but we do rely on the notion that hardware runs correctly 99.999% of the time, don’t we?]
g*lang is also terrible, just because some people were too dumb to understand runtime.Gosched()
doesn’t mean they needed to make threads forcibly preempt every 10ms with no option to disable it