Re: oops? read/write vs type of length parameter

[Stefan Monnier]

> If the code is well-defended against passing negative sizes,
> then we can remove the checks entirely; they're not needed.
> They were meant only as a stopgap in case the callers were
> buggy.  (Also please see below.)

The old approach of being somewhat permissive worked well for decades,
I see no reason to change it.

> Any compiler that will warn about conversions to size_t will
> warn about hundreds of other places in Emacs.  These warnings
> are more trouble than they're worth, and we shouldn't worry
> about them.

I hate casts and generally hate unsigned integers as well, so please
don't introduce changes that add uses of casts or unsigned integers
unless absolutely necessary.

>>> with the goal of removing the runtime checks once we have
>>> carefully checked that they aren't needed.
>> Which will never happen, so these aborts will stay in the code
>> forever.
> I can do it, in the next day or two.  It shouldn't be a problem.

That's not how it works: Emacs will keep being changed in the future.

> I'm sorry if there are hurt feelings about this, but size_t is
> clearly the better choice for buffer sizes;

No, it's not.  Maybe it's your favorite and it probably is the standard
in the C API, but that doesn't make it "clearly the better choice".
E.g. it's a choice I strongly dislike.  The only cases where I like to
use unsigned integers is when we treat them as bitvectors, all other
cases end up creating errors because they eventually meet with signed
types introducing unexpected behaviors.  This is particularly true in
the context of Emacs where most/many integer values go through Elisp
where they are always signed.


        Stefan