strangest systems I've sent email from

[Mouse]

> 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).

> 		http://blog.regehr.org/archives/[...]

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