[tex-k] Precision warnings

[Tomas Rokicki]

Yeah, all of these are worth fixing.  The trick is, after fixing all of
them, we need to test and
make sure no new bugs were introduced and this is tricky.

The fixes need to be standards-compliant and system-independent (even
though 32-bit
platforms are pretty much going away . . .) getting this exactly right can
be challenging.

-tom

On Sat, Oct 26, 2019 at 12:11 PM Doug McKenna <doug at mathemaesthetics.com>
wrote:

> After a successful port of the kpsewhich tool and the kpathsea source code
> to XCode's IDE, the compiler tells me that there are about 40 places in the
> source files where there are assignments of 64-bit (typically size_t)
> integers to local variables of type |int| or |unsigned|, which are both
> 32-bit.  30 of these instances involve assigning the result of strlen() to
> an unsigned int.  Most of the rest involve passing pointer expressions to
> subroutines that take ints.  A couple of final warnings are where system
> library routines delivers ssize_t answers, assigned to ints, or size_t
> answers assigned to unsigned.
>
> Each represents a formal loss of precision, but of course we all know that
> no path string is ever going to breach a signed |int| in length, so in
> practice, nothing bad happens.
>
> I'm happy to take the time to report the exact positions of where these
> warnings are and how I've adjusted my ported code to make them all go
> away.  But I don't really know what other official TeX utility maintainers'
> policy is on the subject, because it involves overriding the compiler with
> casts in most cases, which is (again, formally) not a good thing to do.
>
>
> Doug McKenna
>


-- 
--  http://cube20.org/  --  http://golly.sf.net/  --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20191026/08ccd85d/attachment.html>