On 12/3/20 2:02 PM, Bruno Haible wrote:
For this reason I see the choice of a signed type as an_implementation_ detail.
It's a crucial detail and it belongs in the API. I not not want to waste time worrying whether idx_t is signed in any code that uses idx_t, as signed-vs-unsigned problems are endemic to C and part of the point of using ptrdiff_t is so that I *don't* have to worry about this stuff. For example, if I have an int value I and an idx_t value N and I happens to be negative, and I don't want to have to worry about the possibility that the expression I < N might fail to be true. Expressions like that happen quite a bit in generic code and this is a real problem.
If we're going to leave open the possibility that this type might be unsigned, I'd rather not use the type in canonicalize.c now. Maybe in a decade or three if the C language evolves well in this area, but now's not the time (and I have my doubts about whether it'll evolve well).
