On 12/13/25 07:34, Even Rouault via Tiff wrote:
I was wondering if anyone could provide some historical context for
why the API is this way. And as a followup, if it would be something
we could consider changing to make the API and the internal
implementation safer and cleaner.
I've no historical context on that either. I'm wondering how practical
a change is at that point of history given that it impacts API as
well. I suspect that there might part of the code base where the
signedness would be relied on, typically for loops (e.g. "tmsize_t i =
stride; for (; i < cc - 3; i += 4)" at line 371 of tif_predict.c that
would not run correctly on unsigned type if cc < 3), and switching to
unsigned could introduce bugs. Not a strong opinion though, just a
remark that the benefit vs risk at that point of time isn't
immediately obvious to me.
I am also unaware of the historical context behind tmsize_t but agree
that it is normally safer and more intuitive as an unsigned type. If we
can have a build mode/option where tmsize_t is based on uint64_t (or
even size_t if applicable), then that would help flush out issues with
using an unsigned type. It seems that it does not really impact the C
ABI, but impacts languages like C++ which embed knowledge of types.
I do see this useful comment in tiffio.h:
* NB: tsize_t -> deprecated and replaced by tmsize_t
* is signed and not unsigned because some functions
* return -1.
This comment was already present in the initial repository history
(which became v3.5.7).
Bob
_______________________________________________
Tiff mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/tiff
