> Good, you can read manuals. It takes an int, which ISO C says must
> either represent the value EOF, or else a value in the range of the
> unsigned char type (0 to UCHAR_MAX).

I'm writing C++, not C.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 24.02.2022 um 23:46 schrieb Kaz Kylheku:
>>>
>>>> You don't want to pass wide characters or other junk into isdigit!
>>>
>>> isdigit takes an int.
>>>
>>>> Even char is not safe, because it can be signed and exhibit negative
>>>> values that are not EOF.
>>>
>>> As the boundary between signed and and unsigned ints doesn't fall
>>> within >= '0' and <= '9' it isn't a problem that isdgit takes an int.
>>
>> You are missing the point. It's undefined.
>
> There's nothing undefined here. It doesn't matter if the digits I
> handle to isdigit are sign-expanded or not because '0' ... '9'
> falls into the unsigned range.

Again, that's not the point. Your C++ can be instantiated with wchar_t,
whose values may be outside of the range permitted /as arguments/ to any
of these testing functions.

--
Ben.

Am 25.02.2022 um 21:27 schrieb Ben Bacarisse:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> Am 24.02.2022 um 23:46 schrieb Kaz Kylheku:
>>>>
>>>>> You don't want to pass wide characters or other junk into isdigit!
>>>>
>>>> isdigit takes an int.
>>>>
>>>>> Even char is not safe, because it can be signed and exhibit negative
>>>>> values that are not EOF.
>>>>
>>>> As the boundary between signed and and unsigned ints doesn't fall
>>>> within >= '0' and <= '9' it isn't a problem that isdgit takes an int.
>>>
>>> You are missing the point. It's undefined.
>>
>> There's nothing undefined here. It doesn't matter if the digits I
>> handle to isdigit are sign-expanded or not because '0' ... '9'
>> falls into the unsigned range.
>
> Again, that's not the point. Your C++ can be instantiated with wchar_t,
> whose values may be outside of the range permitted /as arguments/ to any
> of these testing functions.

C++ honors possible table-driven implementations with a small table
for unsigned chars and EOF. But implementing it that way would be
stupid because this would be slower than the two "bound"-checks.
So you can safely assume that there is no implementation that does
it differnently.

On Fri, 25 Feb 2022 20:27:48 +0000, Ben Bacarisse wrote:

> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> Am 24.02.2022 um 23:46 schrieb Kaz Kylheku:
>>>>
>>>>> You don't want to pass wide characters or other junk into isdigit!
>>>>
>>>> isdigit takes an int.
>>>>
>>>>> Even char is not safe, because it can be signed and exhibit negative
>>>>> values that are not EOF.
>>>>
>>>> As the boundary between signed and and unsigned ints doesn't fall
>>>> within >= '0' and <= '9' it isn't a problem that isdgit takes an int.
>>>
>>> You are missing the point. It's undefined.
>>
>> There's nothing undefined here. It doesn't matter if the digits I
>> handle to isdigit are sign-expanded or not because '0' ... '9' falls
>> into the unsigned range.
>
> Again, that's not the point. Your C++ can be instantiated with wchar_t,
> whose values may be outside of the range permitted /as arguments/ to any
> of these testing functions.

In case Bonita doesn't make the connection...

You use isdigit() /because/ you do not know if the argument represents
a digit or not. This means that you (potentially) pass isdigit() an
argument that distinctly does /NOT/ represent a digit. And, some of those
argument may exceed the limitations of isdigit() by having a value that
is neither EOF nor between (int) 0 and (int) UCHAR_MAX.

--
Lew Pitcher
"In Skills, We Trust"

Kaz Kylheku <480-992-1380@kylheku.com> writes:
> On 2022-02-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On Friday, 25 February 2022 at 12:02:56 UTC, Bonita Montero wrote:
>>> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>>>
>>> > std::use_facet<std::ctype<char>>(std::locale()).is(std::ctype_base::digit, c)
>>> And _digit_-checking needs no locales for sure.
>>>
>> In Arabic, whilst they use Arabic numerals (of course), the glyphs are very
>> different from the ones used in the West.
>
> Is't not clear, however, whether the ISO C isdigit and iswdigit
> functions are allowed to detect those.

It's clear that they're *not* allowed to detect digits other than '0' to '9'.

N1570 7.4p2 does say that the behavior is*() functions is affected by
the current locale, but isdigit() "tests for any decimal-digit character
(as defined in 5.2.1)", and 5.2.1 refers only to the 10 decimal digits.

> The requirement is that they only report true for the ten decimal digits
> of the basic execution character set.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 25.02.2022 um 21:27 schrieb Ben Bacarisse:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>>
>>>>> Am 24.02.2022 um 23:46 schrieb Kaz Kylheku:
>>>>>
>>>>>> You don't want to pass wide characters or other junk into isdigit!
>>>>>
>>>>> isdigit takes an int.
>>>>>
>>>>>> Even char is not safe, because it can be signed and exhibit negative
>>>>>> values that are not EOF.
>>>>>
>>>>> As the boundary between signed and and unsigned ints doesn't fall
>>>>> within >= '0' and <= '9' it isn't a problem that isdgit takes an int.
>>>>
>>>> You are missing the point. It's undefined.
>>>
>>> There's nothing undefined here. It doesn't matter if the digits I
>>> handle to isdigit are sign-expanded or not because '0' ... '9'
>>> falls into the unsigned range.
>>
>> Again, that's not the point. Your C++ can be instantiated with wchar_t,
>> whose values may be outside of the range permitted /as arguments/ to any
>> of these testing functions.
>
> C++ honors possible table-driven implementations with a small table
> for unsigned chars and EOF. But implementing it that way would be
> stupid because this would be slower than the two "bound"-checks.
> So you can safely assume that there is no implementation that does
> it differnently.

I hope you don't write code that runs in pacemakers, nuclear power
plants or even just in cars.

--
Ben.

In article <svbd4k$ne4$4@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Good, you can read manuals. It takes an int, which ISO C says must
>> either represent the value EOF, or else a value in the range of the
>> unsigned char type (0 to UCHAR_MAX).
>
>I'm writing C++, not C.
>

And posting to the wrong newsgroup.

Maybe you are using "Google Groups" to post to Usenet, and are suffering
from the limitation of GG that prevents people from posting to
comp.lang.c++ (It truncates the ++ and, erroneously, sends the post to
comp.lang.c).

--
In the corner of the room on the ceiling is a large vampire bat who
is obviously deranged and holding his nose.

gazelle@shell.xmission.com (Kenny McCormack) writes:
>In article <svbd4k$ne4$4@dont-email.me>,
>Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Good, you can read manuals. It takes an int, which ISO C says must
>>> either represent the value EOF, or else a value in the range of the
>>> unsigned char type (0 to UCHAR_MAX).
>>
>>I'm writing C++, not C.
>>
>
>And posting to the wrong newsgroup.
>
>Maybe you are using "Google Groups" to post to Usenet, and are suffering
>from the limitation of GG that prevents people from posting to
>comp.lang.c++ (It truncates the ++ and, erroneously, sends the post to
>comp.lang.c).

He's posting from eternal-september, which seems quite apropos.

Bonita Montero <Bonita.Montero@gmail.com> writes:

> Am 24.02.2022 um 23:46 schrieb Kaz Kylheku:
>
>> You don't want to pass wide characters or other junk into isdigit!
>
> isdigit takes an int.

So? The standard imposes some requirements on the value of the int that
isdigit() in order for that function to have defined behavior. values
smaller than 0 (other than EOF) or larger than UCHAR_MAX are not allowed.

>> Even char is not safe, because it can be signed and exhibit negative
>> values that are not EOF.
>
> As the boundary between signed and and unsigned ints doesn't fall
> within >= '0' and <= '9' it isn't a problem that isdgit takes an int.

"The header <ctype.h> declares several functions useful for classifying
and mapping characters. 214) 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." (7.4p1)

Why shouldn't you be worried about the possibility of your code having
undefined behavior?

On Friday, February 25, 2022 at 3:10:50 PM UTC-5, Bonita Montero wrote:
> My code is C++ and C++ specifies isdigit as a normal function.

I suspect you're referring to
> Names that are defined as functions in C shall be defined as functions in the C ++ standard library. 166
(16.1.5.2p7).

and Footnote 166:
> This disallows the practice, allowed in C, of providing a masking macro in addition to the function prototype. The only
> way to achieve equivalent inline behavior in C ++ is to provide a definition as an extern inline function.

So what? The possibility, allowed in C, of isdigit() being a
function-like macro doesn't play any role in the fact that isdigit(c)
has undefined behavior if c violates the restrictions of 7.4p1.

The ONLY thing the C++ standard says about the behavior of isdigit() is:
> The contents and meaning of the header <cctype> are the same as the C
> standard library header <ctype.h>.
> See also: ISO C 7.4

So the contents of section 7.4 of the C standard are very relevant to
the behavior of isdigit() in C++ code.

On Friday, February 25, 2022 at 3:33:52 PM UTC-5, Bonita Montero wrote:
> C++ honors possible table-driven implementations with a small table
> for unsigned chars and EOF. But implementing it that way would be
> stupid because this would be slower than the two "bound"-checks.
> So you can safely assume that there is no implementation that does
> it differnently.

If that argument were valid, it would apply equally well to C. However,
on my system, at least, in C isdigit() is defined as follows:

/* These are defined in ctype-info.c.
The declarations here must match those in localeinfo.h.

In the thread-specific locale model (see `uselocale' in <locale.h>)
we cannot use global variables for these as was done in the past.
Instead, the following accessor functions return the address of
each variable, which is local to the current thread if multithreaded.

These point into arrays of 384, so they can be indexed by any `unsigned
char' value [0,255]; by EOF (-1); or by any `signed char' value
[-128,-1). ISO C requires that the ctype functions work for `unsigned
char' values and for EOF; we also support negative `signed char' values
for broken old programs. ...
....
*/
# if __BYTE_ORDER == __BIG_ENDIAN
# define _ISbit(bit) (1 << (bit))
# else /* __BYTE_ORDER == __LITTLE_ENDIAN */
# define _ISbit(bit) ((bit) < 8 ? ((1 << (bit)) << 8) : ((1 << (bit))
>> 8))
# endif

51 enum
{ ....
_ISdigit = _ISbit (3), /* Numeric. */
....
};

extern const unsigned short int **__ctype_b_loc (void)
__THROW __attribute__ ((__const__));
....
# define __isctype(c, type) \
((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
#elif defined __USE_EXTERN_INLINES
# define __isctype_f(type) \
__extern_inline int \
is##type (int __c) __THROW \
{ \
return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int)
_IS##type; \
}
#endif

# define isdigit(c) __isctype((c), _ISdigit)

Why would they take such an approach if two bound checks were in fact so
much better of an approach?

Am 26.02.2022 um 05:34 schrieb James Kuyper:

> So? The standard imposes some requirements on the value of the int that
> isdigit() in order for that function to have defined behavior. values
> smaller than 0 (other than EOF) or larger than UCHAR_MAX are not allowed.

It doesn't matter that isdigit is specified to work only with unsigneds
and EOFs. isdigit uses the simplest implementation one can imagine and
there's no reason to do it differently since a table-driven approach
would be slower.
And there are for sure a lot of people using isdigit for wchars and the
writers of standard libraries honor that and if they would breakd that
silent agreement in your sense a lot of applications wouldn't run.

Rest of your nonsense unread.

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 26.02.2022 um 05:34 schrieb James Kuyper:
>
>> So? The standard imposes some requirements on the value of the int that
>> isdigit() in order for that function to have defined behavior. values
>> smaller than 0 (other than EOF) or larger than UCHAR_MAX are not allowed.
>
>It doesn't matter that isdigit is specified to work only with unsigneds
>and EOFs. isdigit uses the simplest implementation one can imagine and
>there's no reason to do it differently since a table-driven approach
>would be slower.

As usual, you are wrong.

SVR4/Unixware and derivatives:

#define isalpha(c) ((_ctype + 1)[c] & (_U | _L))
#define isupper(c) ((_ctype + 1)[c] & _U)
#define islower(c) ((_ctype + 1)[c] & _L)
#define isdigit(c) ((_ctype + 1)[c] & _N)
#define isxdigit(c) ((_ctype + 1)[c] & _X)
#define isalnum(c) ((_ctype + 1)[c] & (_U | _L | _N))
#define isspace(c) ((_ctype + 1)[c] & _S)
#define ispunct(c) ((_ctype + 1)[c] & _P)
#define isprint(c) ((_ctype + 1)[c] & (_P | _U | _L | _N | _B))
#define isgraph(c) ((_ctype + 1)[c] & (_P | _U | _L | _N))
#define iscntrl(c) ((_ctype + 1)[c] & _C)
#define isascii(c) (!((c) & ~0177))
#define _toupper(c) ((_ctype + 258)[c])
#define _tolower(c) ((_ctype + 258)[c])
#define toascii(c) ((c) & 0177)

Linux:

#ifndef __cplusplus
# define __isctype(c, type) \
((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
#elif defined __USE_EXTERN_INLINES
# define __isctype_f(type) \
__extern_inline int \
is##type (int __c) __THROW \
{ \
return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int) _IS##type; \
}

# define isalnum(c) __isctype((c), _ISalnum)
# define isalpha(c) __isctype((c), _ISalpha)
# define iscntrl(c) __isctype((c), _IScntrl)
# define isdigit(c) __isctype((c), _ISdigit)
# define islower(c) __isctype((c), _ISlower)
# define isgraph(c) __isctype((c), _ISgraph)
# define isprint(c) __isctype((c), _ISprint)
# define ispunct(c) __isctype((c), _ISpunct)
# define isspace(c) __isctype((c), _ISspace)
# define isupper(c) __isctype((c), _ISupper)
# define isxdigit(c) __isctype((c), _ISxdigit)
# ifdef __USE_ISOC99
# define isblank(c) __isctype((c), _ISblank)
# endif

Am 26.02.2022 um 18:37 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 26.02.2022 um 05:34 schrieb James Kuyper:
>>
>>> So? The standard imposes some requirements on the value of the int that
>>> isdigit() in order for that function to have defined behavior. values
>>> smaller than 0 (other than EOF) or larger than UCHAR_MAX are not allowed.
>>
>> It doesn't matter that isdigit is specified to work only with unsigneds
>> and EOFs. isdigit uses the simplest implementation one can imagine and
>> there's no reason to do it differently since a table-driven approach
>> would be slower.
>
> As usual, you are wrong.
>
> SVR4/Unixware and derivatives: ...

.... is dead.

On 2/25/22 14:12, Kaz Kylheku wrote:
> On 2022-02-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> On Friday, 25 February 2022 at 12:02:56 UTC, Bonita Montero wrote:
>>> Am 25.02.2022 um 12:46 schrieb Ben Bacarisse:
>>>
>>>> std::use_facet<std::ctype<char>>(std::locale()).is(std::ctype_base::digit,
>>>> c)
>>> And _digit_-checking needs no locales for sure.
>>>
>> In Arabic, whilst they use Arabic numerals (of course), the glyphs
>> are very
>> different from the ones used in the West.
>
> Is't not clear, however, whether the ISO C isdigit and iswdigit
> functions are allowed to detect those.

ISO C says nothing about glyphs - that's outside the scope of the
standard. All it says is about the encoding, and that's entirely
implementation-defined. An implementation of C must identify ten
character values representing the digits 0-9 for the source character
set, and a possibly different set of ten for the execution character
set. Nothing it says in the C standard prohibits an implementation from
using characters that get displayed with the Arabic glyphs rather than
the western ones. However, it must be consistent on that point - if
different characters display with the western glyphs, those characters
must not compare equal to '0' through '9', and only those characters are
allowed to have isdigit() return a non-zero value.

Am 26.02.2022 um 18:37 schrieb Scott Lurndal:
> #ifndef __cplusplus
> # define __isctype(c, type) \
> ((*__ctype_b_loc ())[(int) (c)] & (unsigned short int) type)
> #elif defined __USE_EXTERN_INLINES
> # define __isctype_f(type) \
> __extern_inline int \
> is##type (int __c) __THROW \
> { \
> return (*__ctype_b_loc ())[(int) (__c)] & (unsigned short int) _IS##type; \
> }

#include <cctype>

__attribute((noinline))
int myIsdigit( int ch )
{ return isdigit( ch );
}

g++ 11.0 / libstdc++:

subl $48, %edi
xorl %eax, %eax
cmpl $9, %edi
setbe %al
ret