[tex-k] Precision warnings

[Doug McKenna]

Tom - 

How can changing 

unsigned len = strlen(path); 

which the compiler properly warns about to 

unsigned len = (unsigned)strlen(path); 

introduce a new bug? They both do the exact same thing, yes? The only difference is that the compiler issues a possible loss-of-precision warning in the first case and not in the second. 

What I did was add the following to lib.h and then used them everywhere the compiler was issuing a warning (and only in those places): 

/* For suppressing assignments of path string lengths as long |size_t|s to |unsigned|s */ 
/* Only use these if you are super sure that a path string is not going to be longer than */ 
/* the largest value of a signed or unsigned int. */ 
#define U_STRLEN(str) ((unsigned int)strlen(str)) 
#define I_STRLEN(str) ((int)strlen(str)) 

/* For providing long pointer arithmetic answers to subroutines taking ints/unsigneds */ 
#define U_PTR_EXPR(expr) ((unsigned)(expr)) 
#define I_PTR_EXPR(expr) ((int)(expr)) 

If you really wanted to be formally correct about it, these could be turned into (inline) procedures that actually test for overflow. Plus it makes it easy to search for exactly those instances where the cast has been introduced. 

The alternative is to go through all the code everywhere and slowly change a bunch of |unsigned|s to |size_t|s and |int|s to |ssize_t|s. That would be best in the very long run, I suppose, assuming the remote possibility of a path string (or path element string) ever reaching 2 billion bytes in length. 

- Doug McK. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://tug.org/pipermail/tex-k/attachments/20191026/42f05b0a/attachment.html>