On 2023-04-12 18:26, bill wrote:
> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>> On 2023-04-03 14:31, bill wrote:
>>>> PDP-8, as well as very old PDP-11 software usually also used mark
>>>> parity on all characters. And as far as I know, the ASR-33 variant
>>>> that DEC used did this, which might be the reason for all software
>>>> doing it.
>>>
>>> I am not aware of any PDP-11 operating system where the charsets ASCII
>>> values were 128 to 255 as opposed to 0 to 127.  Certainly none where it
>>> was the hardware forcing it.
>>
>> XXDP (the PDP-11 diagnostics) are the oldest PDP-11 software I have
>> been dealing with. A lot of code in there assumes you are running with
>> mark parity, which basically means all output characters will always
>> have the high bit set.
>
> Yes, but there is a big difference between communications parity and
> memory parity.

Uh? Who mentioned memory parity? Not me.
This has all been communication, as such. But the data as such are
generated already with mark parity by compilers. It's not something
added by any hardware. And the parsing of received data is also done
with the assumption that it was received with mark parity, and that is
never stripped away.

Johnny

Den 2023-04-12 kl. 18:26, skrev bill:

> But that is only during communications.  I am not aware of any program
> that computed the value of a character in transit and cared what that
> value was.  Pr1me set the values in their firmware forcing all programs
> in any language to deal with an ASCII set that had values from 128 to
> 255.

Now, if the highest bit really was a parity bit, you would end up with
values in the whole range 0-255, depending on the number of 1's in the
lower 7 bits.

But maybe that wasn't a real parity bit...

On 4/12/2023 9:37 PM, Johnny Billquist wrote:
> On 2023-04-12 18:26, bill wrote:
>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>> On 2023-04-03 14:31, bill wrote:
>>>>> PDP-8, as well as very old PDP-11 software usually also used mark
>>>>> parity on all characters. And as far as I know, the ASR-33 variant
>>>>> that DEC used did this, which might be the reason for all software
>>>>> doing it.
>>>>
>>>> I am not aware of any PDP-11 operating system where the charsets ASCII
>>>> values were 128 to 255 as opposed to 0 to 127.  Certainly none where it
>>>> was the hardware forcing it.
>>>
>>> XXDP (the PDP-11 diagnostics) are the oldest PDP-11 software I have
>>> been dealing with. A lot of code in there assumes you are running
>>> with mark parity, which basically means all output characters will
>>> always have the high bit set.
>>
>> Yes, but there is a big difference between communications parity and
>> memory parity.
>
> Uh? Who mentioned memory parity? Not me.

I did.

> This has all been communication, as such. But the data as such are
> generated already with mark parity by compilers. It's not something
> added by any hardware. And the parsing of received data is also done
> with the assumption that it was received with mark parity, and that is
> never stripped away.

I thought we were talking about C and it's limitations and the concept
of data types. And then there was the thing about signed and unsigned
chars. And that led to my mentioning a case where not only are chars
(kinda) signed but they always have the high order bit on. And how that
posed a problem porting software because so much of the C software being
moved around (in places like comp.sources.xxx) were written with the
assumption that chars fell in the 0-127 value range.

bill

On 2023-04-12, Johnny Billquist <bqt@softjar.se> wrote:
>
> but I'd say that is less common, and a bad programmer will always manage
> to write bad code, no matter what language. That don't mean the language
> is bad. It is just more unclear, and in C there is no performance
> reason, or anything else giving any reason why you would write 48, when
> '0' is so much clearer what the intent is. And then it also works if you
> use another character set, as long as all the digits have consecutive
> code points.
>

I wonder how the EDCDIC people handle this and your other examples ? :-)

(A-Z is not a contiguous unbroken sequence in EBCDIC.)

Simon.

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

On 2023-04-13, Jan-Erik Söderholm <jan-erik.soderholm@telia.com> wrote:
> Den 2023-04-12 kl. 18:26, skrev bill:
>
>> But that is only during communications.  I am not aware of any program
>> that computed the value of a character in transit and cared what that
>> value was.  Pr1me set the values in their firmware forcing all programs
>> in any language to deal with an ASCII set that had values from 128 to
>> 255.
>
>
> Now, if the highest bit really was a parity bit, you would end up with
> values in the whole range 0-255, depending on the number of 1's in the
> lower 7 bits.
>
> But maybe that wasn't a real parity bit...
>

There's such a thing as mark parity (and space parity) although it
sounds like you've never had the misfortune to come across them... :-)

Simon.

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

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

> Weird? What about under Primos where chars always have the high
> order bit turned on? It was called "mark memory parity" but it
> never made any sense to me when I had to work with it. :-)

You've explained a mystery from 40 years ago. My undergraduate project
was doing animation on a strange colour graphics vector terminal
connected to a Prime 750 running PrimeOS. There were several weeks of
delays while it was got working with PrimeOS, and I never found out why.
It was driven over a serial line and its command language encoded
coordinates in the binary values of ASCII characters. Suddenly, the
problem is obvious.

John

On 4/13/2023 8:16 AM, Simon Clubley wrote:
> On 2023-04-12, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> but I'd say that is less common, and a bad programmer will always manage
>> to write bad code, no matter what language. That don't mean the language
>> is bad. It is just more unclear, and in C there is no performance
>> reason, or anything else giving any reason why you would write 48, when
>> '0' is so much clearer what the intent is. And then it also works if you
>> use another character set, as long as all the digits have consecutive
>> code points.
>>
>
> I wonder how the EDCDIC people handle this and your other examples ? :-)
>
> (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>

I think they do it mostly by not using C. :-)

bill

In article <u18rqh$eb71$1@dont-email.me>,
clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:

> I wonder how the EDCDIC people handle this and your other examples
> ? :-)
>
> (A-Z is not a contiguous unbroken sequence in EBCDIC.)

Linux on IBM Z is an ASCII OS, with no attempt to use EBCDIC.

John

On 4/13/2023 5:12 AM, Jan-Erik Söderholm wrote:
> Den 2023-04-12 kl. 18:26, skrev bill:
>
>> But that is only during communications.  I am not aware of any program
>> that computed the value of a character in transit and cared what that
>> value was.  Pr1me set the values in their firmware forcing all programs
>> in any language to deal with an ASCII set that had values from 128 to
>> 255.
>
>
> Now, if the highest bit really was a parity bit, you would end up with
> values in the whole range 0-255, depending on the number of 1's in the
> lower 7 bits.
>
> But maybe that wasn't a real parity bit...
>

They always referred to it as "Mark Memory Parity". Knowing the
function of parity I never understood just what they thought it did.

bill

On Thu, 2023-04-13 at 21:40 +0100, John Dallman wrote:
> > (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>
> Linux on IBM Z is an ASCII OS, with no attempt to use EBCDIC.

UTF-8 OS, actually.
--
Tactical Nuclear Kittens

On 2023-04-13, bill <bill.gunshannon@gmail.com> wrote:
> On 4/13/2023 8:16 AM, Simon Clubley wrote:
>> On 2023-04-12, Johnny Billquist <bqt@softjar.se> wrote:
>>>
>>> but I'd say that is less common, and a bad programmer will always manage
>>> to write bad code, no matter what language. That don't mean the language
>>> is bad. It is just more unclear, and in C there is no performance
>>> reason, or anything else giving any reason why you would write 48, when
>>> '0' is so much clearer what the intent is. And then it also works if you
>>> use another character set, as long as all the digits have consecutive
>>> code points.
>>>
>>
>> I wonder how the EDCDIC people handle this and your other examples ? :-)
>>
>> (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>>
>
> I think they do it mostly by not using C. :-)
>

Times change. :-) z/OS has a C compiler and now runs open source software.

Simon.

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

On 2023-04-13, John Dallman <jgd@cix.co.uk> wrote:
> In article <u18rqh$eb71$1@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> I wonder how the EDCDIC people handle this and your other examples
>> ? :-)
>>
>> (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>
> Linux on IBM Z is an ASCII OS, with no attempt to use EBCDIC.
>

Actually, I wasn't even thinking of Linux. :-)

I was thinking of z/OS, which does have a C compiler...

Simon.

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

John Dallman writes:
> bill.gunshannon wrote:
>> Weird? What about under Primos where chars always have the high
>> order bit turned on? It was called "mark memory parity" but it
>> never made any sense to me when I had to work with it. :-)
> You've explained a mystery from 40 years ago.

How about PrimeOS handling Control-P specially from the input side?
I heard from Prime Emacs people that was awkward, but there was no
workaround other than "don't do that"

On 4/14/2023 10:09 AM, Lars Brinkhoff wrote:
>
> How about PrimeOS

A minor nit but there is no such thing as PrimeOS.
There is only PRIMOS and PRIMIX.

bill

John Dallman <jgd@cix.co.uk> wrote:
>In article <u18rqh$eb71$1@dont-email.me>,
>clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> I wonder how the EDCDIC people handle this and your other examples
>> ? :-)
>>
>> (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>
>Linux on IBM Z is an ASCII OS, with no attempt to use EBCDIC.

IBM made a few attempts to use ASCII on those machines, with one model
(I want to say the 360/44) having a bunch of ASCII support instructions.
Never seemed to come to much. A number of manufacturers made
sort-of-compatible machines (like the RCA Spectra/70) that used the /360
instruction set but with ASCII so you couldn't really run /360 code on
them.

So I am pleased that IBM has made another attempt at ASCII on that
architecture.
--scott
some add
>
>John

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2023-04-13 13:48, bill wrote:
> On 4/12/2023 9:37 PM, Johnny Billquist wrote:
>> On 2023-04-12 18:26, bill wrote:
>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>> On 2023-04-03 14:31, bill wrote:
>>>>>> PDP-8, as well as very old PDP-11 software usually also used mark
>>>>>> parity on all characters. And as far as I know, the ASR-33 variant
>>>>>> that DEC used did this, which might be the reason for all software
>>>>>> doing it.
>>>>>
>>>>> I am not aware of any PDP-11 operating system where the charsets ASCII
>>>>> values were 128 to 255 as opposed to 0 to 127.  Certainly none
>>>>> where it
>>>>> was the hardware forcing it.
>>>>
>>>> XXDP (the PDP-11 diagnostics) are the oldest PDP-11 software I have
>>>> been dealing with. A lot of code in there assumes you are running
>>>> with mark parity, which basically means all output characters will
>>>> always have the high bit set.
>>>
>>> Yes, but there is a big difference between communications parity and
>>> memory parity.
>>
>> Uh? Who mentioned memory parity? Not me.
>
> I did.

:-)

>> This has all been communication, as such. But the data as such are
>> generated already with mark parity by compilers. It's not something
>> added by any hardware. And the parsing of received data is also done
>> with the assumption that it was received with mark parity, and that is
>> never stripped away.
>
> I thought we were talking about C and it's limitations and the concept
> of data types.  And then there was the thing about signed and unsigned
> chars.  And that led to my mentioning a case where not only are chars
> (kinda) signed but they always have the high order bit on. And how that
> posed a problem porting software because so much of the C software being
> moved around (in places like comp.sources.xxx) were written with the
> assumption that chars fell in the 0-127 value range.

What C says is that the characters used for coding, which means the
basic alphabet, numbers, special characters, and so on, are required to
be positive, no matter what kind of type a char is (signed or unsigned).
For other characters, as well as how many bits a char actually is, is
implementation defined in C. So if you use Latin-1, any of those (extra)
characters might be represented as a negative number in a char, just as
well as a positive number. And they are both correct according to the
standard.

And then you brought up Primos, which appears to have been using mark
parity for characters, and I pointed out that this was also rather true
of old PDP-8 and PDP-11 systems. And then you somehow got that to be
about memory parity, while I was talking about serial communication.

At this point, it feels like we've gotten lost in what the point was.

Johnny

On 2023-04-13 14:16, Simon Clubley wrote:
> On 2023-04-12, Johnny Billquist <bqt@softjar.se> wrote:
>>
>> but I'd say that is less common, and a bad programmer will always manage
>> to write bad code, no matter what language. That don't mean the language
>> is bad. It is just more unclear, and in C there is no performance
>> reason, or anything else giving any reason why you would write 48, when
>> '0' is so much clearer what the intent is. And then it also works if you
>> use another character set, as long as all the digits have consecutive
>> code points.
>>
>
> I wonder how the EDCDIC people handle this and your other examples ? :-)
>
> (A-Z is not a contiguous unbroken sequence in EBCDIC.)

I know. EBCDIC was despised by most back in the 80s for a reason...
Anyway, my examples were dealing with digits, which do have the property
of being a contiguous unbroken sequence even in EBCDIC...

But in general, EBCDIC will require that people do much more coding that
is very character set aware for some problems. Miserable in general.

Johnny

On 2023-04-13 11:12, Jan-Erik Söderholm wrote:
> Den 2023-04-12 kl. 18:26, skrev bill:
>
>> But that is only during communications.  I am not aware of any program
>> that computed the value of a character in transit and cared what that
>> value was.  Pr1me set the values in their firmware forcing all programs
>> in any language to deal with an ASCII set that had values from 128 to
>> 255.
>
>
> Now, if the highest bit really was a parity bit, you would end up with
> values in the whole range 0-255, depending on the number of 1's in the
> lower 7 bits.
>
> But maybe that wasn't a real parity bit...

Depends on what kind of parity you are using...
With even or odd parity and 7 bits of data, you are correct. With mark
or space parity, you are incorrect.

Johnny

On 2023-04-13 21:20, bill wrote:
> On 4/13/2023 5:12 AM, Jan-Erik Söderholm wrote:
>> Den 2023-04-12 kl. 18:26, skrev bill:
>>
>>> But that is only during communications.  I am not aware of any program
>>> that computed the value of a character in transit and cared what that
>>> value was.  Pr1me set the values in their firmware forcing all programs
>>> in any language to deal with an ASCII set that had values from 128 to
>>> 255.
>>
>>
>> Now, if the highest bit really was a parity bit, you would end up with
>> values in the whole range 0-255, depending on the number of 1's in the
>> lower 7 bits.
>>
>> But maybe that wasn't a real parity bit...
>>
>
> They always referred to it as "Mark Memory Parity".  Knowing the
> function of parity I never understood just what they thought it did.

The "memory" part here, makes no sense. This is communication we're
talking about (see your own quote).

But with that said, mark parity do not make much sense, I agree. It
ensures that at least one bit is set in any transmitted byte, and it
helps confirming that you are indeed running at the correct speed, but
that's about all the value it adds.

Johnny

On 4/16/2023 7:55 AM, Johnny Billquist wrote:
> On 2023-04-13 14:16, Simon Clubley wrote:
>> On 2023-04-12, Johnny Billquist <bqt@softjar.se> wrote:
>>>
>>> but I'd say that is less common, and a bad programmer will always manage
>>> to write bad code, no matter what language. That don't mean the language
>>> is bad. It is just more unclear, and in C there is no performance
>>> reason, or anything else giving any reason why you would write 48, when
>>> '0' is so much clearer what the intent is. And then it also works if you
>>> use another character set, as long as all the digits have consecutive
>>> code points.
>>>
>>
>> I wonder how the EDCDIC people handle this and your other examples ? :-)
>>
>> (A-Z is not a contiguous unbroken sequence in EBCDIC.)
>
> I know. EBCDIC was despised by most back in the 80s for a reason...
> Anyway, my examples were dealing with digits, which do have the property
> of being a contiguous unbroken sequence even in EBCDIC...
>
> But in general, EBCDIC will require that people do much more coding that
> is very character set aware for some problems. Miserable in general.

There are two types of issues:
* issues due to developer not knowing EBCDIC well enough
* issues due to nature of EBCDIC

The first is a very general phenomenon.

The second cover issues like a-z and A-Z not being
consecutive.

But there are also positives.

The conversion of numbers between EBCDIC text and
zoned BCD is damn fast!

:-)

Arne

On 4/12/2023 9:33 PM, Johnny Billquist wrote:
> On 2023-04-12 16:44, Arne Vajhøj wrote:
>> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>> On 2023-04-03 14:31, bill wrote:
>>>>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>>>>> On 2023-03-29 19:51, bill wrote:
>>>>>>> Weird?  What about under Primos where chars always have the high
>>>>>>> order
>>>>>>> bit turned on?  It was called "mark memory parity" but it never
>>>>>>> made any
>>>>>>> sense to me when I had to work with it.  :-)
>>>>>>
>>>>>> I think/suspect that this goes outside the scope of C...
>>>>>
>>>>> Of course it does.  But it affects C a lot more than other languages
>>>>> if for no other reason than programming style.  How many Unix C
>>>>> programs
>>>>> have you seen where parsing is done by looking at the value of a
>>>>> letter
>>>>> as opposed to just comparing chars?  Even with Primix porting a Unix
>>>>> program to a Pr1me was a serious task and often not even possible.
>>>>
>>>> I don't understand what you mean. Are you just talking about some
>>>> people assuming you have ASCII, and looking at the decimal values,
>>>> instead of the character representation. Basically writing 65
>>>> instead of 'A'?
>>>> If so, that is certainly something I've seen in lots of languages,
>>>> and are in fact much more an issue in most other languages that I've
>>>> used, since they do not consider a thing like 'A' to be a numeric
>>>> value. C doing that really helps in this context.
>>>>
>>>> I'd say it's more common to see C code using the characters instead
>>>> of their numeric representation just because it is so easy to do in C.
>>>
>>> I believe there are basically two groups of languages:
>>>
>>> A) those where one can write both c=='A' and c==65
>>> B) those where one can write c=='A' but c==65 gives a compile error
>>> and has to be written as ord(c)==65
>>>
>>> I find it more likely that group A will use 65 than group B.
>>
>> Examples of code:
>
> [...lots of code deleted...]
>
> The problem with this is that it is very artificial, and designed to
> prove your point.

Testing if a char is in the digit range is not an artificial problem.

Yes - the example was showing my point - it would have
been pretty weird if I had produced an example that did
not show my point.

> I can just as well give a counter example.
>
> Let's say you have a character that you know is a digit, and you want to
> convert it nicely to an integer.
>
> In C, you'd do that like this:
>
>    x = c - '0';
>
> In FORTRAN, BASIC, and god knows what else, you'd see:
>
>   x = ord(c) - 48;
>
> Now, I'd say I've seen plenty more of that than your type of example.
> And I've *never* seen:
>
>   x = ord(c) - ord('0');
>
>
> And yes, of course, you can also in C do:
>
>   x = c - 48;
>
> but I'd say that is less common, and a bad programmer will always manage
> to write bad code, no matter what language. That don't mean the language
> is bad. It is just more unclear, and in C there is no performance
> reason, or anything else giving any reason why you would write 48, when
> '0' is so much clearer what the intent is. And then it also works if you
> use another character set, as long as all the digits have consecutive
> code points.

I suspect that you are correct that x = c - '0' is more common
than x = c - 48 in C and x = ord(c) - ord('0') is less common
than x = ord(c) - 48 in more type safe languages.

But the construct should be very rare overall as most languages
has easy to use and efficient builtin methods for that.

(and no it is not quite the same for checking if in digit range
as doing conversion and check for error and regex are a bit
heavy tools for the task).

Arne

On 4/16/2023 1:26 PM, Arne Vajhøj wrote:
> On 4/12/2023 9:33 PM, Johnny Billquist wrote:
>> On 2023-04-12 16:44, Arne Vajhøj wrote:
>>> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>>> On 2023-04-03 14:31, bill wrote:
>>>>>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>>>>>> On 2023-03-29 19:51, bill wrote:
>>>>>>>> Weird?  What about under Primos where chars always have the high
>>>>>>>> order
>>>>>>>> bit turned on?  It was called "mark memory parity" but it never
>>>>>>>> made any
>>>>>>>> sense to me when I had to work with it.  :-)
>>>>>>>
>>>>>>> I think/suspect that this goes outside the scope of C...
>>>>>>
>>>>>> Of course it does.  But it affects C a lot more than other languages
>>>>>> if for no other reason than programming style.  How many Unix C
>>>>>> programs
>>>>>> have you seen where parsing is done by looking at the value of a
>>>>>> letter
>>>>>> as opposed to just comparing chars?  Even with Primix porting a Unix
>>>>>> program to a Pr1me was a serious task and often not even possible.
>>>>>
>>>>> I don't understand what you mean. Are you just talking about some
>>>>> people assuming you have ASCII, and looking at the decimal values,
>>>>> instead of the character representation. Basically writing 65
>>>>> instead of 'A'?
>>>>> If so, that is certainly something I've seen in lots of languages,
>>>>> and are in fact much more an issue in most other languages that
>>>>> I've used, since they do not consider a thing like 'A' to be a
>>>>> numeric value. C doing that really helps in this context.
>>>>>
>>>>> I'd say it's more common to see C code using the characters instead
>>>>> of their numeric representation just because it is so easy to do in C.
>>>>
>>>> I believe there are basically two groups of languages:
>>>>
>>>> A) those where one can write both c=='A' and c==65
>>>> B) those where one can write c=='A' but c==65 gives a compile error
>>>> and has to be written as ord(c)==65
>>>>
>>>> I find it more likely that group A will use 65 than group B.
>>>
>>> Examples of code:
>>
>> [...lots of code deleted...]
>>
>> The problem with this is that it is very artificial, and designed to
>> prove your point.
>
> Testing if a char is in the digit range is not an artificial problem.
>
> Yes - the example was showing my point - it would have
> been pretty weird if I had produced an example that did
> not show my point.
>
>> I can just as well give a counter example.
>>
>> Let's say you have a character that you know is a digit, and you want
>> to convert it nicely to an integer.
>>
>> In C, you'd do that like this:
>>
>>     x = c - '0';
>>
>> In FORTRAN, BASIC, and god knows what else, you'd see:
>>
>>    x = ord(c) - 48;
>>
>> Now, I'd say I've seen plenty more of that than your type of example.
>> And I've *never* seen:
>>
>>    x = ord(c) - ord('0');
>>
>>
>> And yes, of course, you can also in C do:
>>
>>    x = c - 48;
>>
>> but I'd say that is less common, and a bad programmer will always
>> manage to write bad code, no matter what language. That don't mean the
>> language is bad. It is just more unclear, and in C there is no
>> performance reason, or anything else giving any reason why you would
>> write 48, when '0' is so much clearer what the intent is. And then it
>> also works if you use another character set, as long as all the digits
>> have consecutive code points.
>
> I suspect that you are correct that x = c - '0' is more common
> than x = c - 48 in C and x = ord(c) - ord('0') is less common
> than x = ord(c) - 48 in more type safe languages.
>
> But the construct should be very rare overall as most languages
> has easy to use and efficient builtin methods for that.
>
> (and no it is not quite the same for checking if in digit range
> as doing conversion and check for error and regex are a bit
> heavy tools for the task).

And the usual code example to illustrate what I am talking
about.

$ type toint.c
#include <stdio.h>
#include <string.h>

int toint(const char *s)
{ int res;
sscanf(s, "%d", &res);
return res;
}

int tointx(const char *s)
{ int res, i;
res = 0;
for(i = 0; i < strlen(s); i++)
{
res = 10 * res + (s[i] - '0');
}
return res;
}

int tointxx(const char *s)
{ int res, i;
res = 0;
for(i = 0; i < strlen(s); i++)
{
res = 10 * res + (s[i] - 48);
}
return res;
}

void test(const char *s)
{ printf("\"%s\" : %d\n", s, toint(s));
printf("\"%s\" : %d\n", s, tointx(s));
printf("\"%s\" : %d\n", s, tointxx(s));
}

int main(int argc, char *argv[])
{ test("1");
test("12");
test("123");
return 0;
} $ cc toint
$ link toint
$ run toint
"1" : 1
"1" : 1
"1" : 1
"12" : 12
"12" : 12
"12" : 12
"123" : 123
"123" : 123
"123" : 123
$ type toint.pas
program main(input,output);

type
string = varying [255] of char;

function toint(s : string) : integer;

var
res : integer;

begin
readv(s, res);
toint := res;
end;

function tointx(s : string) : integer;

var
res, i : integer;

begin
res := 0;
for i := 1 to length(s) do begin
res := 10 * res + (ord(s[i]) - ord('0'));
end;
tointx := res;
end;

function tointxx(s : string) : integer;

var
res, i : integer;

begin
res := 0;
for i := 1 to length(s) do begin
res := 10 * res + (ord(s[i]) - 48);
end;
tointxx := res;
end;

procedure test(s : string);

begin
writeln('"', s, '" : ', toint(s):1);
writeln('"', s, '" : ', tointx(s):1);
writeln('"', s, '" : ', tointxx(s):1);
end;

begin
test('1');
test('12');
test('123');
end.
$ pas toint
$ link toint
$ run toint
"1" : 1
"1" : 1
"1" : 1
"12" : 12
"12" : 12
"12" : 12
"123" : 123
"123" : 123
"123" : 123
$ type toint.for
program main
call test('1')
call test('12')
call test('123')
end
c subroutine test(s)
character*(*) s
integer*4 toint, tointx, tointxx
write(*,'(1x,a,3h : ,i3)') s, toint(s)
write(*,'(1x,a,3h : ,i3)') s, tointx(s)
write(*,'(1x,a,3h : ,i3)') s, tointxx(s)
end
c integer*4 function toint(s)
character*(*) s
integer*4 res
read(s,'(i)') res
toint = res
end
c integer*4 function tointx(s)
character*(*) s
integer*4 res, i
res = 0
do 100 i = 1, len(s)
res = 10 * res + (ichar(s(i:i)) - ichar('0'))
100 continue
tointx = res
end
c integer*4 function tointxx(s)
character*(*) s
integer*4 res, i
res = 0
do 100 i = 1, len(s)
res = 10 * res + (ichar(s(i:i)) - 48)
100 continue
tointxx = res
end
$ for toint
$ link toint
$ run toint
1 : 1
1 : 1
1 : 1
12 : 12
12 : 12
12 : 12
123 : 123
123 : 123
123 : 123
$ type toint.bas
program main

external sub test(string)

call test("1")
call test("12")
call test("123")

end program
! sub test(string s)

external integer function toint(string)
external integer function tointx(string)
external integer function tointxx(string)

On 2023-04-16 19:26, Arne Vajhøj wrote:
> On 4/12/2023 9:33 PM, Johnny Billquist wrote:
>> On 2023-04-12 16:44, Arne Vajhøj wrote:
>>> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>>> On 2023-04-03 14:31, bill wrote:
>>>>>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>>>>>> On 2023-03-29 19:51, bill wrote:
>>>>>>>> Weird?  What about under Primos where chars always have the high
>>>>>>>> order
>>>>>>>> bit turned on?  It was called "mark memory parity" but it never
>>>>>>>> made any
>>>>>>>> sense to me when I had to work with it.  :-)
>>>>>>>
>>>>>>> I think/suspect that this goes outside the scope of C...
>>>>>>
>>>>>> Of course it does.  But it affects C a lot more than other languages
>>>>>> if for no other reason than programming style.  How many Unix C
>>>>>> programs
>>>>>> have you seen where parsing is done by looking at the value of a
>>>>>> letter
>>>>>> as opposed to just comparing chars?  Even with Primix porting a Unix
>>>>>> program to a Pr1me was a serious task and often not even possible.
>>>>>
>>>>> I don't understand what you mean. Are you just talking about some
>>>>> people assuming you have ASCII, and looking at the decimal values,
>>>>> instead of the character representation. Basically writing 65
>>>>> instead of 'A'?
>>>>> If so, that is certainly something I've seen in lots of languages,
>>>>> and are in fact much more an issue in most other languages that
>>>>> I've used, since they do not consider a thing like 'A' to be a
>>>>> numeric value. C doing that really helps in this context.
>>>>>
>>>>> I'd say it's more common to see C code using the characters instead
>>>>> of their numeric representation just because it is so easy to do in C.
>>>>
>>>> I believe there are basically two groups of languages:
>>>>
>>>> A) those where one can write both c=='A' and c==65
>>>> B) those where one can write c=='A' but c==65 gives a compile error
>>>> and has to be written as ord(c)==65
>>>>
>>>> I find it more likely that group A will use 65 than group B.
>>>
>>> Examples of code:
>>
>> [...lots of code deleted...]
>>
>> The problem with this is that it is very artificial, and designed to
>> prove your point.
>
> Testing if a char is in the digit range is not an artificial problem.
>
> Yes - the example was showing my point - it would have
> been pretty weird if I had produced an example that did
> not show my point.

The problem is that it is very artificial.
First of all, I've never seen C code where people would write

if ((x < 48) || (57 < x)) { ... }

It's just plain stupid to write that if they want to check if it is a
digit. It's close to unreadable, and just makes much more sense to say
'0' and '9'.

But secondly, noone in C would/should ever even do such a stupid thing.
There are isdigit() for exactly this, and basically any other
categorization you would want to do, so even more so, the suggested bad
way of doing it in C is not something anyone would/should do.

And using a function like isdigit() is actually way better than checking
if the character is between '0' and '9', even in other languages. Since
it actually also removes the possible risks that you might have a
character set where they are not consecutive values. Your code is
already making bad assumptions, and in most languages you are actually
force to stick with those assumptions.

In C, you are not, and should actually not write this kind of code. It
is potentially bad and non-portable in all kind of weird ways.

That is why you have libraries that provide the proper evaluation of
such issues, and which makes the code safer.

So in the end, I definitely think C does this better than your other
languages selected.

(And yes, my silly example of converting a character to a binary value
also suffers from the potential bad non-portability which was pointed
out. But I was just trying to find an example where expressing integer
values as characters actually was helpful, and not bad. Probably should
try to think of other examples, if we really want to continue this...)

Johnny

On 4/20/2023 5:32 AM, Johnny Billquist wrote:
> On 2023-04-16 19:26, Arne Vajhøj wrote:
>> On 4/12/2023 9:33 PM, Johnny Billquist wrote:
>>> On 2023-04-12 16:44, Arne Vajhøj wrote:
>>>> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>>>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>>>> On 2023-04-03 14:31, bill wrote:
>>>>>>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>>>>>>> On 2023-03-29 19:51, bill wrote:
>>>>>>>>> Weird?  What about under Primos where chars always have the
>>>>>>>>> high order
>>>>>>>>> bit turned on?  It was called "mark memory parity" but it never
>>>>>>>>> made any
>>>>>>>>> sense to me when I had to work with it.  :-)
>>>>>>>>
>>>>>>>> I think/suspect that this goes outside the scope of C...
>>>>>>>
>>>>>>> Of course it does.  But it affects C a lot more than other languages
>>>>>>> if for no other reason than programming style.  How many Unix C
>>>>>>> programs
>>>>>>> have you seen where parsing is done by looking at the value of a
>>>>>>> letter
>>>>>>> as opposed to just comparing chars?  Even with Primix porting a Unix
>>>>>>> program to a Pr1me was a serious task and often not even possible.
>>>>>>
>>>>>> I don't understand what you mean. Are you just talking about some
>>>>>> people assuming you have ASCII, and looking at the decimal values,
>>>>>> instead of the character representation. Basically writing 65
>>>>>> instead of 'A'?
>>>>>> If so, that is certainly something I've seen in lots of languages,
>>>>>> and are in fact much more an issue in most other languages that
>>>>>> I've used, since they do not consider a thing like 'A' to be a
>>>>>> numeric value. C doing that really helps in this context.
>>>>>>
>>>>>> I'd say it's more common to see C code using the characters
>>>>>> instead of their numeric representation just because it is so easy
>>>>>> to do in C.
>>>>>
>>>>> I believe there are basically two groups of languages:
>>>>>
>>>>> A) those where one can write both c=='A' and c==65
>>>>> B) those where one can write c=='A' but c==65 gives a compile error
>>>>> and has to be written as ord(c)==65
>>>>>
>>>>> I find it more likely that group A will use 65 than group B.
>>>>
>>>> Examples of code:
>>>
>>> [...lots of code deleted...]
>>>
>>> The problem with this is that it is very artificial, and designed to
>>> prove your point.
>>
>> Testing if a char is in the digit range is not an artificial problem.
>>
>> Yes - the example was showing my point - it would have
>> been pretty weird if I had produced an example that did
>> not show my point.
>
> The problem is that it is very artificial.
> First of all, I've never seen C code where people would write
>
> if ((x < 48) || (57 < x)) { ... }
>
> It's just plain stupid to write that if they want to check if it is a
> digit. It's close to unreadable, and just makes much more sense to say
> '0' and '9'.
>
> But secondly, noone in C would/should ever even do such a stupid thing.
> There are isdigit() for exactly this, and basically any other
> categorization you would want to do, so even more so, the suggested bad
> way of doing it in C is not something anyone would/should do.
>
> And using a function like isdigit() is actually way better than checking
> if the character is between '0' and '9', even in other languages. Since
> it actually also removes the possible risks that you might have a
> character set where they are not consecutive values. Your code is
> already making bad assumptions, and in most languages you are actually
> force to stick with those assumptions.
>
> In C, you are not, and should actually not write this kind of code. It
> is potentially bad and non-portable in all kind of weird ways.
>
> That is why you have libraries that provide the proper evaluation of
> such issues, and which makes the code safer.
>
> So in the end, I definitely think C does this better than your other
> languages selected.

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.

Arne

On 4/22/2023 7:47 PM, Arne Vajhøj wrote:
> On 4/20/2023 5:32 AM, Johnny Billquist wrote:
>> On 2023-04-16 19:26, Arne Vajhøj wrote:
>>> On 4/12/2023 9:33 PM, Johnny Billquist wrote:
>>>> On 2023-04-12 16:44, Arne Vajhøj wrote:
>>>>> On 4/12/2023 10:41 AM, Arne Vajhøj wrote:
>>>>>> On 4/7/2023 4:58 PM, Johnny Billquist wrote:
>>>>>>> On 2023-04-03 14:31, bill wrote:
>>>>>>>> On 4/2/2023 8:50 PM, Johnny Billquist wrote:
>>>>>>>>> On 2023-03-29 19:51, bill wrote:
>>>>>>>>>> Weird?  What about under Primos where chars always have the
>>>>>>>>>> high order
>>>>>>>>>> bit turned on?  It was called "mark memory parity" but it
>>>>>>>>>> never made any
>>>>>>>>>> sense to me when I had to work with it.  :-)
>>>>>>>>>
>>>>>>>>> I think/suspect that this goes outside the scope of C...
>>>>>>>>
>>>>>>>> Of course it does.  But it affects C a lot more than other
>>>>>>>> languages
>>>>>>>> if for no other reason than programming style.  How many Unix C
>>>>>>>> programs
>>>>>>>> have you seen where parsing is done by looking at the value of a
>>>>>>>> letter
>>>>>>>> as opposed to just comparing chars?  Even with Primix porting a
>>>>>>>> Unix
>>>>>>>> program to a Pr1me was a serious task and often not even possible.
>>>>>>>
>>>>>>> I don't understand what you mean. Are you just talking about some
>>>>>>> people assuming you have ASCII, and looking at the decimal
>>>>>>> values, instead of the character representation. Basically
>>>>>>> writing 65 instead of 'A'?
>>>>>>> If so, that is certainly something I've seen in lots of
>>>>>>> languages, and are in fact much more an issue in most other
>>>>>>> languages that I've used, since they do not consider a thing like
>>>>>>> 'A' to be a numeric value. C doing that really helps in this
>>>>>>> context.
>>>>>>>
>>>>>>> I'd say it's more common to see C code using the characters
>>>>>>> instead of their numeric representation just because it is so
>>>>>>> easy to do in C.
>>>>>>
>>>>>> I believe there are basically two groups of languages:
>>>>>>
>>>>>> A) those where one can write both c=='A' and c==65
>>>>>> B) those where one can write c=='A' but c==65 gives a compile
>>>>>> error and has to be written as ord(c)==65
>>>>>>
>>>>>> I find it more likely that group A will use 65 than group B.
>>>>>
>>>>> Examples of code:
>>>>
>>>> [...lots of code deleted...]
>>>>
>>>> The problem with this is that it is very artificial, and designed to
>>>> prove your point.
>>>
>>> Testing if a char is in the digit range is not an artificial problem.
>>>
>>> Yes - the example was showing my point - it would have
>>> been pretty weird if I had produced an example that did
>>> not show my point.
>>
>> The problem is that it is very artificial.
>> First of all, I've never seen C code where people would write
>>
>> if ((x < 48) || (57 < x)) { ... }
>>
>> It's just plain stupid to write that if they want to check if it is a
>> digit. It's close to unreadable, and just makes much more sense to say
>> '0' and '9'.
>>
>> But secondly, noone in C would/should ever even do such a stupid
>> thing. There are isdigit() for exactly this, and basically any other
>> categorization you would want to do, so even more so, the suggested
>> bad way of doing it in C is not something anyone would/should do.
>>
>> And using a function like isdigit() is actually way better than
>> checking if the character is between '0' and '9', even in other
>> languages. Since it actually also removes the possible risks that you
>> might have a character set where they are not consecutive values. Your
>> code is already making bad assumptions, and in most languages you are
>> actually force to stick with those assumptions.
>>
>> In C, you are not, and should actually not write this kind of code. It
>> is potentially bad and non-portable in all kind of weird ways.
>>
>> That is why you have libraries that provide the proper evaluation of
>> such issues, and which makes the code safer.
>>
>> So in the end, I definitely think C does this better than your other
>> languages selected.
>
> 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.

Arne