Enhancement: isascii() was deprecated in POSIX.1-2008 and removed in POSIX.1-2024 but we still use it

[xexyl]

Is there an existing issue for this?

• I have searched for existing issues and did not find anything like this

Describe the enhancement

Recently I learnt that the isascii() was deprecated and I just found out it was removed in POSIX.1-2024. I should have known the latter at least and I might have and not worried about it (for what I needed it for but I certainly did not know it was removed in POSIX.1-2024) but we perhaps should get rid of it and instead when doing the is*() or to*() cast to an unsigned char.

I was considering doing this but too many changes are made right now (bug fix and also the copyright date from some hours ago).

Thus I am opening this issue instead for it to be dealt with later on.

Relevant images, screenshots or other files

No response

Relevant links

https://www.gnu.org/software/gnulib/manual/html_node/isascii.html

Anything else?

I have done this in jparse but I have not yet committed it. I want to do a clearer check later on though make prep works.

I'm pretty sure there are other repos that have this unfortunate issue.

[xexyl]

Although I might actually go ahead and do this before the judging closes I am not doing it for now. I MIGHT commit to jparse today but that's far from clear.

The following repos do use isascii() incidentally:

• cpath
• pr

... and unfortunately this repo uses it a lot even besides jparse which when I commit it'll be taken care of (once synced).

But not now.

[xexyl]

Another place it is used is in soup/rule_count.c which would mean that only you or @SirWumpus could edit it.

[SirWumpus]

Another place it is used is in soup/rule_count.c which would mean that only you or @SirWumpus could edit it.

The code that uses isascii() is wrapped in #ifdef ASCII_ONLY, which was never in the original code I supplied. The original test used was simply:

#ifdef ASCII_ONLY
		if (128 <= ch) {

Also the code is disabled ...

/* ISO C11 section 5.2.1 defines source character set, specifically:
 *
 *	The representation of each member of the source and execution
 *	basic character sets shall fit in a byte.
 *
 * Note however that string literals and comments could contain non-ASCII
 * (consider non-English developers writing native language comments):
 *
 *	If any other characters are encountered in a source file (except
 *	in an identifier, a character constant, a string literal, a header
 *	name, a comment, or a preprocessing token that is never converted
 *	to a token), the behavior is undefined.
 *
 * Probably best to leave as-is, count them, and let the compiler sort it.
 */
#undef ASCII_ONLY

However with the clear support for UTF8 now, means that code (which has never been enabled), could be considered dead and removed.

[xexyl]

Another place it is used is in soup/rule_count.c which would mean that only you or @SirWumpus could edit it.

The code that uses isascii() is wrapped in #ifdef ASCII_ONLY, which was never in the original code I supplied. The original test used was simply:

#ifdef ASCII_ONLY
		if (128 <= ch) {

Also the code is disabled ...

/* ISO C11 section 5.2.1 defines source character set, specifically:
 *
 *	The representation of each member of the source and execution
 *	basic character sets shall fit in a byte.
 *
 * Note however that string literals and comments could contain non-ASCII
 * (consider non-English developers writing native language comments):
 *
 *	If any other characters are encountered in a source file (except
 *	in an identifier, a character constant, a string literal, a header
 *	name, a comment, or a preprocessing token that is never converted
 *	to a token), the behavior is undefined.
 *
 * Probably best to leave as-is, count them, and let the compiler sort it.
 */
#undef ASCII_ONLY

However with the clear support for UTF8 now, means that code (which has never been enabled), could be considered dead and removed.

I saw that #if guard yes.

I don't mind either way obviously. That one is up to you and Landon. Thanks for your feedback!

[xexyl]

As for undefined that was another reason I brought this up. These functions require that the arg is representable in EOF or an unsigned char. So in my view it would probably be better if it was removed but again that is not up to me.

Nonetheless I think the rest of the code should be changed regardless of this one.

[SirWumpus]

These functions require that the arg is representable in EOF or an unsigned char.

What you talk'n about Willis?

All the ctype macros and function take an int argument so that EOF and char can be represented. And all my ch and next_ch are declared as int. So I see no issue on that point.

[xexyl]

These functions require that the arg is representable in EOF or an unsigned char.

What you talk'n about Willis?

All the ctype macros and function take an int argument so that EOF and char can be represented. And all my ch and next_ch are declared as int. So I see no issue on that point.

I thought the same thing but ...

The header <ctype.h> declares several functions useful for classifying and mapping characters.202)
In all cases the argument is an int, the value of which shall be representable as an unsigned char
or shall equal the value of the macro EOF. If the argument has any other value, the behavior is
undefined.

From 7.4 Character handling <ctype.h>.

[xexyl]

... and no it doesn't particularly make sense to me either.

[lcn2]

Please consider submitting a PR, @xexyl, to resolve this issue, so that the PR may be considered after the winners of IOCCC29 are published.

[xexyl]

Please consider submitting a PR, @xexyl, to resolve this issue, so that the PR may be considered after the winners of IOCCC29 are published.

I suppose we could use -funsigned-char to help out too?

Anyway I'll not work on any code at least until after the current pull requests are open. I know you've replied to other issues .. not really feeling up to it. Only replying to this as I saw it in email. I actually need to leave for the day.

But what do you think about the compiler option? Of course...it would not resolve the issue that the function is used. It would not solve the problem that data that is not unsigned char (or EOF) might be passed to the functions that are still 'valid' either. But it might in some cases help? Then again it might not: perhaps there are times where we don't want to force it. I haven't looked at the code in quite some time so I couldn't say, though it appears that in jparse it did not cause any problem (test suite works fine).