22 May
2016
22 May
'16
6:09 a.m.
I'd wager that most C code is written *assuming*
2's complement and 0
NULL pointers (and byte addressable, but I didn't ask for that 8-).
Well, yes. I'd go further: I'd wager most C code is written assuming
everything works just the way the developer's system does; most people
I interact with don't seem to realize that "try it and see how it
works" is not a valid way to find out how C (as opposed to "C on this
particular version of this particular implementation on this particular
system") works.
"[W]rite a VM with minimal bytecode and that
uses 1s'
complement and/or sign-magnitude. Implement a GCC or LLVM
backend for it if either of them has nominal support for that,
or a complete C implementation if not. [...]
Personally, I would *love* to see such a compiler (and would actually
use it, just to see how biased existing code is).
I've often thought about building a C implementation that goes out of
its way to break assumptions like "integers are two's complement with
no padding bits" or "floats are IEEE" or "nil pointers are
all-bits-0"
or "all pointers are the same size and representation" or etc.
I'm not even sure
size_t foo = (size_t)-1;
is legal,
In C++, I don't know. In C, I'm fairly sure it's legal.
or even does what I expect it to do (namely---set foo
to the largest
size_t value possible (pre C99).
I'm not sure it does that. If you want that, I think you want
size_t foo = -(size_t)1;
To me, I see 2's complement as having "won
the war" so to speak.
At present, yes, I agree. I am not convinced that will not change.
There was a time when "little endian, no alignment restrictions"
appeared to have won the war (in the form of the VAX and, later, the
x86). These days, ARM's star is on the rise and others may follow,
breaking the "no alignment restrictions" part (and possibly the "little
endian" part - I forget whether ARM is big- or little-endian).
Yeah, I've read some of his writings.
I disagree with him. I think C needs to fork. It seems to me there is
need for two languages: an unsafe one, the "high level assembly
language" C is regularly called, which is suitable for things such as
hardware interfacing or malloc() implementation, and a safer one,
closer to what blog.regehr.org seems to want, for...well, I'm not quite
sure what he thinks this language would be better for. Application
layer stuff, I guess?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B