>> 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;
While I think that size_t foo = (size_t)(-1); is what C would interpret as being meant. What the size of the thing that by default, in this implementation, -1 would be stored in. On 22 May 2016 at 14:09, Mouse <mo...@rodents-montreal.org> wrote: > > 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 mo...@rodents-montreal.org > / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B > -- 4.4 > 5.4