On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>
>
> True. In C the isdigit function would be much better than a range check.
>

A cute idea, but also a modern accretion. Early C didn't have it
and as much as people like to say comparing a char to it's numeric
value is not a good idea it was quite common at one time. I know,
because I was the one tasked with porting some of this code to
Primix where the chars all had a different numeric value. I don't
know why they did it, but they did.

bill

On 4/23/2023 9:46 AM, bill wrote:
> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>> True. In C the isdigit function would be much better than a range check.
>
> A cute idea, but also a modern accretion. Early C didn't have it
> and as much as people like to say comparing a char to it's numeric
> value is not a good idea it was quite common at one time.  I know,
> because I was the one tasked with porting some of this code to
> Primix where the chars all had a different numeric value.  I don't
> know why they did it, but they did.

Different people may have different definitions of "modern".

isdigit is in C89 so it has been standard for over 30 years.

Arne

On Sun, 23 Apr 2023 09:51:11 -0400, Arne Vajhøj wrote:

> On 4/23/2023 9:46 AM, bill wrote:
>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>> True. In C the isdigit function would be much better than a range
>>> check.
>>
>> A cute idea, but also a modern accretion. Early C didn't have it and as
>> much as people like to say comparing a char to it's numeric value is
>> not a good idea it was quite common at one time.  I know,
>> because I was the one tasked with porting some of this code to Primix
>> where the chars all had a different numeric value.  I don't know why
>> they did it, but they did.
>
> Different people may have different definitions of "modern".
>
> isdigit is in C89 so it has been standard for over 30 years.

It's in the original K&R book, so that's back as far as 1978. Hardly a
'modern accretion'!

On 4/23/2023 9:54 AM, Bob Eager wrote:
> On Sun, 23 Apr 2023 09:51:11 -0400, Arne Vajhøj wrote:
>
>> On 4/23/2023 9:46 AM, bill wrote:
>>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>>> True. In C the isdigit function would be much better than a range
>>>> check.
>>>
>>> A cute idea, but also a modern accretion. Early C didn't have it and as
>>> much as people like to say comparing a char to it's numeric value is
>>> not a good idea it was quite common at one time.  I know,
>>> because I was the one tasked with porting some of this code to Primix
>>> where the chars all had a different numeric value.  I don't know why
>>> they did it, but they did.
>>
>> Different people may have different definitions of "modern".
>>
>> isdigit is in C89 so it has been standard for over 30 years.
>
> It's in the original K&R book, so that's back as far as 1978. Hardly a
> 'modern accretion'!

It is not in Ultrix-11 :-). I assume that also means V7.
Don't remember it in System III. Don't know when it came
about but I was already trying to port a lot of Univ C
programs by 1982. A bit before C89.

bill

On 4/23/2023 9:54 AM, Bob Eager wrote:
> On Sun, 23 Apr 2023 09:46:32 -0400, bill wrote:
>
>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>>
>>>
>>> True. In C the isdigit function would be much better than a range
>>> check.
>>>
>>>
>> A cute idea, but also a modern accretion. Early C didn't have it and as
>> much as people like to say comparing a char to it's numeric value is not
>> a good idea it was quite common at one time. I know,
>> because I was the one tasked with porting some of this code to Primix
>> where the chars all had a different numeric value. I don't know why
>> they did it, but they did.
>
> It's in the K&R book dated 1978. So that's 'modern', then?

Interesting. Says it's in the C library but I don't remember it and
man doesn't return an entry.

bill

In article <kakr5oFq0fdU8@mid.individual.net>, bill.gunshannon@gmail.com
(bill) wrote:

> A cute idea, but also a modern accretion. Early C didn't have it
> and as much as people like to say comparing a char to it's numeric
> value is not a good idea it was quite common at one time. I know,
> because I was the one tasked with porting some of this code to
> Primix where the chars all had a different numeric value. I don't
> know why they did it, but they did.

Wikipedia reckons <https://en.wikipedia.org/wiki/PRIMOS#Data_access> that
the Teletype ASR-33 required the top bit of an 8-bit byte to be 1. So
that was adopted as the standard PRIMOS character code, since basic ASCII
left the top bit undefined.

John

On 4/23/2023 3:38 PM, Dan Cross wrote:
> In article <kakrvrFq0fdU9@mid.individual.net>,
> bill <bill.gunshannon@gmail.com> wrote:
>> On 4/23/2023 9:54 AM, Bob Eager wrote:
>>> On Sun, 23 Apr 2023 09:51:11 -0400, Arne Vajhøj wrote:
>>>
>>>> On 4/23/2023 9:46 AM, bill wrote:
>>>>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>>>>> True. In C the isdigit function would be much better than a range
>>>>>> check.
>>>>>
>>>>> A cute idea, but also a modern accretion. Early C didn't have it and as
>>>>> much as people like to say comparing a char to it's numeric value is
>>>>> not a good idea it was quite common at one time.  I know,
>>>>> because I was the one tasked with porting some of this code to Primix
>>>>> where the chars all had a different numeric value.  I don't know why
>>>>> they did it, but they did.
>>>>
>>>> Different people may have different definitions of "modern".
>>>>
>>>> isdigit is in C89 so it has been standard for over 30 years.
>>>
>>> It's in the original K&R book, so that's back as far as 1978. Hardly a
>>> 'modern accretion'!
>>
>> It is not in Ultrix-11 :-). I assume that also means V7.
>
> It is certainly in V7 and is referenced all over Ultrix-11,
> though curiously, `ctype.h` seems to be missing from the archive
> I have of that. However, it's in v7m.
>
>> Don't remember it in System III.
>
> It was definitely in System III.
>
>> Don't know when it came
>> about but I was already trying to port a lot of Univ C
>> programs by 1982. A bit before C89.

>
> That's very odd. Was that some kind of micro?

Typo. Should have been just Unix C. I was porting
to Primos and Primix.
Mostly stuff from the comp.sources groups. Very little of it was
portable. Even with a lot of massaging. But the charset values
was the biggest killer because so many programs assumed 0-127 as
ordinal value of the ASCII charset.

bill

On Sun, 23 Apr 2023 09:46:32 -0400, bill wrote:

> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>
>>
>> True. In C the isdigit function would be much better than a range
>> check.
>>
>>
> A cute idea, but also a modern accretion. Early C didn't have it and as
> much as people like to say comparing a char to it's numeric value is not
> a good idea it was quite common at one time. I know,
> because I was the one tasked with porting some of this code to Primix
> where the chars all had a different numeric value. I don't know why
> they did it, but they did.

It's in the K&R book dated 1978. So that's 'modern', then?

On 2023-04-22, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> Java has a Character.isDigit method that return true for 350 chars.

And what the hell is the point of _that_ ? :-)

> But I am pretty sure that most Java developers are interested in
> knowing if the char is in 0..9 not whether it is among those 350 chars.
>

Yes, that's what normal people, instead of ivory tower language
designers, want. :-)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

In article <kam0vhFq0fdU11@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 4/23/2023 3:38 PM, Dan Cross wrote:
>>> Don't know when it came
>>> about but I was already trying to port a lot of Univ C
>>> programs by 1982. A bit before C89.
>>
>> That's very odd. Was that some kind of micro?
>
>Typo. Should have been just Unix C. I was porting
>to Primos and Primix.

Got it.

>Mostly stuff from the comp.sources groups. Very little of it was
>portable. Even with a lot of massaging. But the charset values
>was the biggest killer because so many programs assumed 0-127 as
>ordinal value of the ASCII charset.

I can believe that, but I'd imagine it was less the use of
individual code-points as a general assumption that the high-bit
was clear, and that thus one could use a char to index a table
with only 128 entries or something: things like that still trip
up programmers, even in our modern, almost always ASCII or
UTF-8, world (indeed, this used to be a source of frustration
for using the `is*` family, as they did table lookups: one had
to be careful to use `isascii` first before blinding applying
them).

Regardless, the ctype macros were there pretty early on; they
date from when C was still single-digit years old, and certainly
by the early 80s they were well established.

- Dan C.

On 4/24/2023 8:59 AM, Dan Cross wrote:
> In article <kam0vhFq0fdU11@mid.individual.net>,
>> Mostly stuff from the comp.sources groups. Very little of it was
>> portable. Even with a lot of massaging. But the charset values
>> was the biggest killer because so many programs assumed 0-127 as
>> ordinal value of the ASCII charset.
>
> I can believe that, but I'd imagine it was less the use of
> individual code-points as a general assumption that the high-bit
> was clear, and that thus one could use a char to index a table
> with only 128 entries or something: things like that still trip
> up programmers, even in our modern, almost always ASCII or
> UTF-8, world (indeed, this used to be a source of frustration
> for using the `is*` family, as they did table lookups: one had
> to be careful to use `isascii` first before blinding applying
> them).

The is* functions take an int and are required to accept
values that can be stuffed into an unsigned char (plus value
of EOF macro). An is* function using a 128 entry table is broken
on a system with an >7 bit execution char set.

The isascii function is not in the C standard but only in the
POSIX standard (The Open Group Base Specifications).

Arne

Simon Clubley wrote:

> Arne Vajhøj wrote:
>
>> Java has a Character.isDigit method that return true for 350 chars.
>
> And what the hell is the point of _that_ ? :-)

Depends ... if you have a string where Character.isDigit() returns true
for every character, does Integer.parseInt() return the expected
integer. What about mixed writing systems, should the string "٣3३３" be
expected to return the integer 3333?

On 4/24/2023 9:32 AM, Andy Burns wrote:
> Simon Clubley wrote:
>> Arne Vajhøj wrote:
>>> Java has a Character.isDigit method that return true for 350 chars.
>>
>> And what the hell is the point of _that_ ? :-)
>
> Depends ... if you have a string where Character.isDigit() returns true
> for every character, does Integer.parseInt() return the expected
> integer.  What about mixed writing systems, should the string "٣3३３" be
> expected to return the integer 3333?

The documentation explains what is does:

<quote>
public static boolean isDigit(char ch)

Determines if the specified character is a digit.

A character is a digit if its general category type, provided by
Character.getType(ch), is DECIMAL_DIGIT_NUMBER.

Some Unicode character ranges that contain digits:

'\u0030' through '\u0039', ISO-LATIN-1 digits ('0' through '9')
'\u0660' through '\u0669', Arabic-Indic digits
'\u06F0' through '\u06F9', Extended Arabic-Indic digits
'\u0966' through '\u096F', Devanagari digits
'\uFF10' through '\uFF19', Fullwidth digits

Many other character ranges contain digits as well.

Note: This method cannot handle supplementary characters. To support all
Unicode characters, including supplementary characters, use the
isDigit(int) method.
</quote>

But my theory is that most Java programs doing some input verification
really want to check for Iso-Latin-1 digits and anything else should
be considered an error.

And at it is really symmetric. If a program is expecting arab-indic
digits, then Iso-Latin-1 digits should probably be considered an
error.

Arne

In article <u260ak$brdi$1@dont-email.me>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 4/24/2023 8:59 AM, Dan Cross wrote:
>> In article <kam0vhFq0fdU11@mid.individual.net>,
>>> Mostly stuff from the comp.sources groups. Very little of it was
>>> portable. Even with a lot of massaging. But the charset values
>>> was the biggest killer because so many programs assumed 0-127 as
>>> ordinal value of the ASCII charset.
>>
>> I can believe that, but I'd imagine it was less the use of
>> individual code-points as a general assumption that the high-bit
>> was clear, and that thus one could use a char to index a table
>> with only 128 entries or something: things like that still trip
>> up programmers, even in our modern, almost always ASCII or
>> UTF-8, world (indeed, this used to be a source of frustration
>> for using the `is*` family, as they did table lookups: one had
>> to be careful to use `isascii` first before blinding applying
>> them).
>
>The is* functions take an int and are required to accept
>values that can be stuffed into an unsigned char (plus value
>of EOF macro). An is* function using a 128 entry table is broken
>on a system with an >7 bit execution char set.
>
>The isascii function is not in the C standard but only in the
>POSIX standard (The Open Group Base Specifications).

Note the context. We're discuss pre-standard C.

- Dan C.

This thread left the rails so long ago that I don't feel very bad
about including the following slightly related story.

Back in the eighties, I worked on a (FORTRAN) program for digital
logic and fault simulation. Circuits were described in text, and only a
limited character set was allowed. Part of the input parsing involved
detecting invalid characters.

One day we ran some performance analysis (VAXset PCA?), and
discovered that much time was spent in an input-parsing function. A
glance at the code showed why. There was an array of all the legal
characters, and that array was searched sequentially for each character
in the input. (Is it an "A"? Is it a "B" Is it a "C" ...)

Replacing that atrocity with a (256-character) look-up table reduced
the time spent in that function to approximately zero, and, as I recall,
cut about 2% off of the total design-compilation time.

In article <kakrvrFq0fdU9@mid.individual.net>,
bill <bill.gunshannon@gmail.com> wrote:
>On 4/23/2023 9:54 AM, Bob Eager wrote:
>> On Sun, 23 Apr 2023 09:51:11 -0400, Arne Vajhøj wrote:
>>
>>> On 4/23/2023 9:46 AM, bill wrote:
>>>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>>>> True. In C the isdigit function would be much better than a range
>>>>> check.
>>>>
>>>> A cute idea, but also a modern accretion. Early C didn't have it and as
>>>> much as people like to say comparing a char to it's numeric value is
>>>> not a good idea it was quite common at one time.  I know,
>>>> because I was the one tasked with porting some of this code to Primix
>>>> where the chars all had a different numeric value.  I don't know why
>>>> they did it, but they did.
>>>
>>> Different people may have different definitions of "modern".
>>>
>>> isdigit is in C89 so it has been standard for over 30 years.
>>
>> It's in the original K&R book, so that's back as far as 1978. Hardly a
>> 'modern accretion'!
>
>It is not in Ultrix-11 :-). I assume that also means V7.

It is certainly in V7 and is referenced all over Ultrix-11,
though curiously, `ctype.h` seems to be missing from the archive
I have of that. However, it's in v7m.

>Don't remember it in System III.

It was definitely in System III.

> Don't know when it came
>about but I was already trying to port a lot of Univ C
>programs by 1982. A bit before C89.

That's very odd. Was that some kind of micro?

- Dan C.

Steven Schweda <sms.antinode@gmail.com> wrote:
> Replacing that atrocity with a (256-character) look-up table reduced
>the time spent in that function to approximately zero, and, as I recall,
>cut about 2% off of the total design-compilation time.

"A penny's worth of better algorithm is worth thousands of dollars worth
of faster hardware."
-- gus baird
--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-04-23 01:59, Arne Vajhøj wrote:
> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>> True. In C the isdigit function would be much better than a range check.
>>
>> Some other languages have similar functions, but not necessarily
>> doing what the programmer want.
>>
>> Java has a Character.isDigit method that return true for 350 chars.
>> But I am pretty sure that most Java developers are interested in
>> knowing if the char is in 0..9 not whether it is among those 350 chars.
>
> Of course C also got iswdigit - which on my system return true
> for 263 input values.
>
> But I don't think w is that popular in C.

wide chars are such a mess. I won't even try to discuss them. :-)
But I assume that the one i Java in the end is assuming you are dealing
with Unicode, and I would suspect that for the C version as well. And
Unicode is a mess.

Johnny

On 4/26/2023 6:19 PM, Johnny Billquist wrote:
> On 2023-04-23 01:59, Arne Vajhøj wrote:
>> On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
>>> True. In C the isdigit function would be much better than a range check.
>>>
>>> Some other languages have similar functions, but not necessarily
>>> doing what the programmer want.
>>>
>>> Java has a Character.isDigit method that return true for 350 chars.
>>> But I am pretty sure that most Java developers are interested in
>>> knowing if the char is in 0..9 not whether it is among those 350 chars.
>>
>> Of course C also got iswdigit - which on my system return true
>> for 263 input values.
>>
>> But I don't think w is that popular in C.
>
> wide chars are such a mess. I won't even try to discuss them. :-)
> But I assume that the one i Java in the end is assuming you are dealing
> with Unicode, and I would suspect that for the C version as well. And
> Unicode is a mess.

Java got two isdigit - one that accept a char which contains
an UTF-16 code unit and one that accept an int which
contains an Unicode code point.

In general I am OK with Unicode - all those "thingies"
exist - it does not make any sense to pretend that
they do not exist, so they need to be handled.

Using UTF-16 in memory for char and string, UTF-8
on disk and on wire plus NCHAR/NVARCHAR/NCLOB in database
usually works fine for me.

(UTF-16 in memory does not work to well for anything outside
BMP, but in practice most stuff are in BMP)

But Unicode API's sometimes have a few things that bothers
me - one of them is isxxxxx methods that assume I want
to check for all languages.

Arne

On 10/30/2022 6:59 PM, Arne Vajhøj wrote:
> On 9/12/2022 6:58 PM, Arne Vajhøj wrote:
>> I did a little writeup:
>>
>> https://www.vajhoej.dk/arne/articles/vmsipc.html
>
>>      TCP/IP Socket
>>          Concept
>>          Demo
>>          Java API (Java)
>>          C API (C)
>>          Python API (Python, Jython)
>>          Wrapper C API (Fortran, Pascal, Cobol, Basic)
>
> Just added:
>
> HTTP
>     Concept
>     Demo
>     Embedded server (Java, Python)
>     Java API (Java)
>     urllib3 (Python)
>     Curl (C, PHP)
>     Direct socket (C)
>     Wrapper direct socket (Fortran, Pascal, Cobol, Basic)

It now also has:

SOAP Web Service

Concept
Demo
JAX-WS embedded server (Java)
JAX-WS (Java, Groovy, Jython)
Zeep (Python)
SoapClient (PHP)
Spyne embedded server (Python)

XML-RPC Web Service

Concept
Demo
Embedded server (Java, Python)
Apache XML-RPC (Java, Groovy)
xmlrpc module (Python)
xmlrpc encoder and decode (PHP)
XMLRPC and PXMLRPC (C, Pascal)
direct XML + HTTP wrapper (Fortran, Basic)

RESTful Web Service

Concept
Demo
Embedded server (Java)
HttpURLConnection + GSon (Java, Groovy)
request + json (Python)
curl + json_encode/json_decode (PHP)
socket + cJSON (C, Pascal)

Arne