Thread: char detail detection

Making some kernel safe code and was struggling with how to check limits safely when GCC's documented predefines are unavailable, this is what I've come up with for CHAR* macros when no equivalent macros can be detected:

Code:

...
#define __UCHAR_MAX__ (0U | -('\x1'))
...
#define __SCHAR_MAX__ (0 | (__UCHAR_MAX__ >> 1))
...
#define __SCHAR_MIN__ ((-__SCHAR_MAX__)-1)
...
/* Bitwise is a workaround for integer promotion */
#define __CHAR_SIGNED__ (__SCHAR_MAX__ > ('\0' | __UCHAR_MAX__))
...
#elif __CHAR_SIGNED__
#define __CHAR_UNSIGNED__ 0
#else
#define __CHAR_UNSIGNED__ 1
...

Just wanted to know if anyone sees a problem with these?
Still working on figuring out __CHAR_BIT__ should these be fine

Originally Posted by john.c

I don't understand what you expect bitwise-oring something with 0 to do?

To maintain signedness in preprocessor

Originally Posted by john.c

remember that character constants (like '\x1') are ints in C.

If that's the case what's the point in the wide character variants like L'\x1'?

Originally Posted by john.c

It looks like pretty much all your macros are making ints (or unsigned ints).

As you will note via the __CHAR_SIGNED__ fallback this signedness is vital for it

Originally Posted by john.c

I'm not sure if there's a way to do this. In glibc limits.h they just hardcode the specific values.

That's an absolute last resort, I'd rather not have to detect the CPU and system more than necessary

john.c is right and it is easy to demonstrate:

- Your UCHAR_MAX symbol could be defined as:

Code:

#define __UCHAR_MAX__ ((unsigned char)-1)

ORing with 0 can be discarded by the optimizer.

- You can force, by casting, __SCHAR_MAX__ and __SCHAR_MIN__ to by signed (no ORing needed)...

- I believe you can't implement a macro to get the size of a char in bits, like CHAR_BITS, but you can do programmatically.

- the sizeof '\1' is always the same as sizeof(int) -- In fact, 6.4.4 §10 of ISO 9989:1999 says explicitly: "An integer character constant has type int..."

Code:

$  gcc -xc -include stdio.h - <<< 'void main(){printf("%zu\n",sizeof('\1')); }'; ./a.out
4

The wchat_t type is usually the same size as int type as well:

Code:

$ gcc -xc -include stdio.h -include wchar.h - \
<<< 'void main(){printf("%zu\n",sizeof(wchar_t)); }'; ./a.out
4

But you can make it shorter with GCC option -fshort-wchar (good compilers will allow this as well):

Code:

$ gcc -xc -include stdio.h -include wchar.h -fshort-wchar - \
<<< 'void main(){printf("%zu\n",sizeof(wchar_t)); }'; ./a.out
2

Another example... This is valid (the compiler will issue an warning, but the standard accept this construction):

Code:

int x = 'abcd';
printf("%#x\n", x );

Will print: 0x61626364

Originally Posted by john.c

Read this about character constants in C:
character constant - cppreference.com

On my computer your __CHAR_SIGNED__ macro gets the wrong value (unless 0 is supposed to mean signed). Have you tested any of this?

If it was possible to do what you are trying to do then why don't they do it in glibc?

I had naively thought that characters would be treated as char (as common sense dictates), I did not realise the C committee was this stupid, were it not for annoyingly hard to implement side of converting code to binary I would be severely tempted to write my own compiler with a new language that is C like but without certain crap like no standard
predefines or non-guaranteed llong (even if it has to be supported via a long[2] array).

Just gonna fire an error when __CHAR*__ macros can't be forcefully defined then

Why it is "stupid" to store a character in multiple bytes? If you use charsets as UTF-8, for exeample, one single character can be stored in 1 to 6 bytes:

Code:

$ man 7 utf8

If you are dealing with a single byte charset (examples: ASCII and ISO-8859-1), how do you test for EOF on functions as fgetc()?

Originally Posted by flp1969

Why it is "stupid" to store a character in multiple bytes? If you use charsets as UTF-8, for exeample, one single character can be stored in 1 to 6 bytes:

Code:

$ man 7 utf8

If you are dealing with a single byte charset (examples: ASCII and ISO-8859-1), how do you test for EOF on functions as fgetc()?

Remember those integer promotion rules? Where an integer is only promoted if the integer in question goes beyond the default size? That should've applied to characters too, instead they made a mashup of it by fixing the size of it at something bigger than it should be.

It applies to char type too. But you are talking about "promotion", defined as "the act of raising to a higher position or rank". What happens, the other way around, is a demotion... Or, are you saying this should be prohibited?

Code:

char c = -1;

Just accidentally deleted my own post, the code your mentioning is runtime which is unrelated to the preprocessor, also the demotion stuff is unaffected by a change to default size of character constants

I'm showing that an int literal is demoted to a char type by the compiler without any problem in response for your promotion question and "certain crap as language standard"...