signed char test

[muta...@gmail.com]

I have this code:

#if ('\x80' < 0) #define CHAR_MIN -128 #define CHAR_MAX 127 #else #define CHAR_MIN 0 #define CHAR_MAX 255 #endif


But it occurs to me that the preprocessor won't
actually know that - that is set by the compiler
proper, right?

Thanks. Paul.

[Bart]

On 04/04/2021 17:27, muta...@gmail.com wrote:
> I have this code:
>
> #if ('\x80' < 0) #define CHAR_MIN -128 #define CHAR_MAX 127 #else #define CHAR_MIN 0 #define CHAR_MAX 255 #endif

(Something weird going on here if you copy&paste this code. Is this your
own encoding?)

>
> But it occurs to me that the preprocessor won't
> actually know that - that is set by the compiler
> proper, right?

Have you tried it? Most compilers (I inserted an #error line into each
branch) have '\x80' as less than zero.

Two (mine and lccwin) have it as unsigned.

So presumably the contents of '...' are treated as a signed value which
is sign-extended to int, which happens even in the preprocessor.

This is why I gave up on my C compiler; I was constantly learning new
things that were non-conforming.

However, why not just use CHAR_MIN/MAX from limits.h? Your hardcoded
values will be wrong when chars are 256 bits; then you will need, for
signed:

#define CHAR_MIN \
-57896044618658097711785492504343953926634992332820282019728792003956564819968
#define CHAR_MAX \
57896044618658097711785492504343953926634992332820282019728792003956564819967

limits.h will have the correct values.

[muta...@gmail.com]

On Monday, April 5, 2021 at 2:53:26 AM UTC+10, Bart wrote:

> > I have this code:
> >
> > #if ('\x80' < 0) #define CHAR_MIN -128 #define CHAR_MAX 127 #else #define CHAR_MIN 0 #define CHAR_MAX 255 #endif

> (Something weird going on here if you copy&paste this code. Is this your
> own encoding?)

I don't know why cutting and pasting from Windows
command prompt sometimes does that.

Cutting and pasting from micro-emacs always fails
and I am forced to use notepad to avoid lots of
spaces in one line.

> > But it occurs to me that the preprocessor won't
> > actually know that - that is set by the compiler
> > proper, right?

> Have you tried it? Most compilers (I inserted an #error line into each
> branch) have '\x80' as less than zero.
>
> Two (mine and lccwin) have it as unsigned.
>
> So presumably the contents of '...' are treated as a signed value which
> is sign-extended to int, which happens even in the preprocessor.
>
> This is why I gave up on my C compiler; I was constantly learning new
> things that were non-conforming.

Smaller C relies on a separately-supplied preprocessor.

I realized that with such a configuration, I would need
them to be on the same page. And that's when I
realized that the whole concept may be illegitimate.

> However, why not just use CHAR_MIN/MAX from limits.h?

This *is* from limits.h in PDPCLIB.

BFN. Paul.

[Bart]

That's rather odd then. You'd think the limits.h file /that comes with
the compiler/ would know if chars were signed or not!

[muta...@gmail.com]

On Monday, April 5, 2021 at 4:28:40 AM UTC+10, Bart wrote:

> >> However, why not just use CHAR_MIN/MAX from limits.h?
> >
> > This *is* from limits.h in PDPCLIB.

> That's rather odd then. You'd think the limits.h file /that comes with
> the compiler/ would know if chars were signed or not!

The person providing the C library can be different
from the person providing the compiler.

The person providing the C preprocessor can be
different from the person providing the compiler.

In one of my situations, all 3 (PDPCLIB, preprocessor,
compiler) are from 3 different people.

However, in my situation, there is modifiable source
for all 3, so that provides some relief. So the
preprocessor could be modified to allow the user
to choose whether to make chars signed or unsigned,
and have warning in the "help" that they need to make
sure the compiler options match. But as I said, the
whole thing could be illegitimate.

BFN. Paul.

[Vir Campestris]

On 04/04/2021 19:28, Bart wrote:
> That's rather odd then. You'd think the limits.h file /that comes with
> the compiler/ would know if chars were signed or not!

-funsigned-char

Let the type char be unsigned, like unsigned char.

(option for GCC)

Andy

[James Kuyper]

Unless the limits.h file gives a value for CHAR_MAX and CHAR_MIN that
correctly reflects whether or not that option is chosen, that limits.h
file and that compiler cannot both be part of the same fully-conforming
implementation of C. That's the most that can be said about such an
implementation, as far as the C standard is concerned.

gcc uses the pre#defined macro __CHAR_UNSIGNED__ give the limits.h file
the information it needs to correctly define CHAR_MAX and CHAR_MIN,
regardless of whether you use -funsigned-char or -fsigned-char.

[muta...@gmail.com]

On Tuesday, April 6, 2021 at 2:26:38 PM UTC+10, james...@alumni.caltech.edu wrote:
> On 4/5/21 4:15 PM, Vir Campestris wrote:
> > On 04/04/2021 19:28, Bart wrote:
> >> That's rather odd then. You'd think the limits.h file /that comes with
> >> the compiler/ would know if chars were signed or not!
> >
> > -funsigned-char
> >
> > Let the type char be unsigned, like unsigned char.
> >
> > (option for GCC)

> Unless the limits.h file gives a value for CHAR_MAX and CHAR_MIN that
> correctly reflects whether or not that option is chosen, that limits.h
> file and that compiler cannot both be part of the same fully-conforming
> implementation of C. That's the most that can be said about such an
> implementation, as far as the C standard is concerned.

Thanks for providing the technical answer to my question.

> gcc uses the pre#defined macro __CHAR_UNSIGNED__ give the limits.h file
> the information it needs to correctly define CHAR_MAX and CHAR_MIN,
> regardless of whether you use -funsigned-char or -fsigned-char.

And thanks for a possible solution.

BFN. Paul.