>> 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 <mouse at 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 mouse at rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>
--
4.4 > 5.4