Discussion:
[tex-k] Wrong constant value?
Douglas McKenna
2017-12-05 01:26:35 UTC
Permalink
In the kpathsea header file "c-minmax.h" the line

#define SCHAR_MAX 128

seems to me to be incorrect. I would think it should be

#define SCHAR_MAX 127

assuming it's supposed to be defined in a manner similar to the other integer limits in that file for shorts or ints, which is to say the highest signed legal integer value given the number of bits (8 bits = 127, 16 bits = 32767, 32 bits = 2147483647, 64 bits = 9223372036854775807).

It has never mattered in kpathsea, I suppose, because no other kpathsea source files appear to use the constant that I can tell.

But I mention this on the list because some other code that includes this header file might rely on it. Which might be bad or lead to unexpected results.


Doug McKenna
Akira Kakuto
2017-12-05 08:45:44 UTC
Permalink
Dear Douglas,
Post by Douglas McKenna
In the kpathsea header file "c-minmax.h" the line
#define SCHAR_MAX 128
seems to me to be incorrect. I would think it should be
#define SCHAR_MAX 127
Probably, absolute values of MIN and MAX are reversed ;-
#define SCHAR_MIN (-127)
#define SCHAR_MAX 128
--->
#define SCHAR_MIN (-128)
#define SCHAR_MAX 127

Similarly
#define SHRT_MIN (-32767)
--->
#define SHRT_MIN (-32768)

#define INT_MIN (-2147483647)
--->
#define INT_MIN (-2147483648)

The are all unused in Kpathsea.

Best,
Akira
Doug McKenna
2017-12-05 15:01:40 UTC
Permalink
Akiro -

TeX's code avoids treating the most negative twos-complement value for an integer as legal, so that any integer value can be negated safely.

Which could be why the "MIN" constants in this header file are all 1 higher than the actual most negative minimum value. I'm not advocating changing those minimums, it's just that the maximum value for signed 8-bit bytes is 127, not 128, whereas the other maximums are not analogously overflowed.

Onward, into the fog ...

Doug McKenna


----- Original Message -----
From: "Akira Kakuto" <***@fuk.kindai.ac.jp>
To: "Douglas McKenna" <***@mathemaesthetics.com>, tex-***@tug.org
Sent: Tuesday, December 5, 2017 1:45:44 AM
Subject: Re: [tex-k] Wrong constant value?

Dear Douglas,
Post by Douglas McKenna
In the kpathsea header file "c-minmax.h" the line
#define SCHAR_MAX 128
seems to me to be incorrect. I would think it should be
#define SCHAR_MAX 127
Probably, absolute values of MIN and MAX are reversed ;-
#define SCHAR_MIN (-127)
#define SCHAR_MAX 128
--->
#define SCHAR_MIN (-128)
#define SCHAR_MAX 127

Similarly
#define SHRT_MIN (-32767)
--->
#define SHRT_MIN (-32768)

#define INT_MIN (-2147483647)
--->
#define INT_MIN (-2147483648)

The are all unused in Kpathsea.

Best,
Akira
Akira Kakuto
2017-12-05 19:59:41 UTC
Permalink
Dear Douglas,
Post by Doug McKenna
TeX's code avoids treating the most negative twos-complement
value for an integer as legal, so that any integer value can
be negated safely.
Which could be why the "MIN" constants in this header file are
all 1 higher than the actual most negative minimum value.
Thank you very much for pointing out that.
Completely agreed.

Akira
Karl Berry
2017-12-05 23:32:14 UTC
Permalink
#define SCHAR_MAX 127

Indeed. Fixed, thanks.

It has never mattered in kpathsea, I suppose, because no other kpathsea
source files appear to use the constant that I can tell.

grep reports that SCHAR_MAX (and SCHAR_MIN) is used in web2c-parser.y
(and nowhere else in TL's source tree). I suspect there are a
combination of reasons why the error has never mattered. One being that
on (I suppose) all modern systems, <limits.h> defines the values so the
kpse values are never used. They are only there as a fallback.

TeX's code avoids treating the most negative twos-complement value for
an integer as legal, so that any integer value can be negated safely.

Judging by my comments in c-minmax.h, I guess I was looking at some
standard for ANSI C (ca.1992) which specified the lowest/highest
acceptable values. I doubt I had the brains or memory to compare with
TeX. But I suppose ANSI C eschewed the most-negative number for the same
reason as TeX, since as far as I can recall it wasn't supposed to
require twos-complement machines ... --thanks, karl.

Loading...