środa, 16 sierpnia 2023 o 21:52:53 UTC+2 fir napisał(a):
> środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
> > środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
> > >
> > > if ((ch >= '0') && (ch <= '9)) {
> > > return ch - '0';
> > > }
> > there is a question if not write this
> >
> > if(ch>='0' & ch<='9') return ch - '0';
> >
> > i mean use & instead of &&, this && is kinda nonsense (skipping parenthesis i assume work coz im not sure, but better to assume and debug imo)
> i checked if this work and seem to be ok
>
> char c ='3'; if(c>='0'&c<='9') printf("%d",c-'0');
>
> btw the more long i c then i tend to write with syntax that can
> be considered tricks (like long vertical lines, short syntax..but imo its right
> way becouse what may be considered little trouble for nob it is none
> if youre just familiar
>
> painfull are though the c flops not alowing use some shortcuts where there is
> nothing thatdisallows them on semantic level (mainly like instantiating
> variables inside some contructs etc)
>
> conclusions
>
> THOSE WHO MANAGE EXTENSIONS TO C SHOULD ALLOW THAT,
> I MEAN ALLOW THAT SYNTAX EXTENSIONS
>
> really, it would not break c and would be much pleasant

btw speaking of ifs some observation on switch case unconsequence
(ratcher unpleasant)

case resembles if except you write case(2) instead of if(c==2),
i mean switch(c) case(1) case(2) default; is proper syntax for it
yhis what is right now is bad

ommiting those parenthesis is bad also no need to enclosing {}
on all construct

switch(p)
case(1) a(); case(2) b();
just like if, the additional statemnts

case(1) a(); c(); case(2) b();
like c(); here should be either just executed as free (not part of case(1)
or disallowed

in the way it is roght now its syntax incoherence imo (as case is close to of and no need to break this syntax imo)

btw the holes in if-else also should be either executed or disallowed

if(a==2) foo(); bar(); else zoo();

Bart <bc@freeuk.com> writes:
[...]
> Unfortunately, in C, string literals have type char*, and char*
> strings are encountered everywhere, where they can store ASCII,
> extended ASCII of various kinds, or UTF8.

No, string literals are of type char[N], where N is the length of the
literal plus 1.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

On 16/08/2023 21:26, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
> [...]
>> Unfortunately, in C, string literals have type char*, and char*
>> strings are encountered everywhere, where they can store ASCII,
>> extended ASCII of various kinds, or UTF8.
>
> No, string literals are of type char[N], where N is the length of the
> literal plus 1.
>

Which is usually converted to type char*?

But this makes little difference to my point: you can't really get away
from C's plain 'char' type if dealing with text and strings.

David Brown <david.brown@hesbynett.no> writes:

> On 16/08/2023 16:35, Malcolm McLean wrote:
>> On Wednesday, 16 August 2023 at 14:31:51 UTC+1, David Brown wrote:

>>> I think it is entirely appropriate to use "char" for characters (and
>>> const char* for immutable strings). But I don't think it is appropriate
>>> for any kind of arithmetic.
>>>
>> Theoretically an atoi() should be implemeted with
>
> I'm not sure "should be" is the phrase you are looking for here!
>
>> strchr("0123456789", ch);

That's a rather oblique hint. You can't use strchr unless you record
the pointer to the digit string:

const char *digits = "0123456789";

now, when ch is a digit, strchr(digits, ch) - digits gives ch's value as
a digit. But since this only works for valid digits, we probably want
something more like

const char *digits = "0123456789", *found = strchr(digits, ch);
return found ? found - digits : -1;

>> to convert from character to digit. But people like efficiency.
>
> It would still not be arithmetic on chars.

That's Malcolm's point. He's countering your "no arithmetic on chars"
by saying we'd be forced to use something like a search and people like
efficiency.

But then atoi is a library function and I am sure you did not intend you
prohibition to extend to the internals of an implementation.

Anyway, as you go on to say...

> But you /could/ have code such as :
>
> if ((ch >= '0') && (ch <= '9)) {
> return ch - '0';
> }
>
> That would be arithmetic on chars. Well, obviously the actual arithmetic
> is on chars promoted to int (or unsigned int, if plain char is unsigned at
> the same size as int) - but you know what I mean.
>
> The C standard requires a character set in which '0' to '9' are
> consecutive, so that kind of code will be fully defined.

.... this one is fine. In fact, I would not go so far as to say "on
arithmetic on chars" because of thins like this.

--
Ben.

fir <profesor.fir@gmail.com> writes:

> środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
>> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
>> >
>> > if ((ch >= '0') && (ch <= '9)) {
>> > return ch - '0';
>> > }
>> there is a question if not write this
>>
>> if(ch>='0' & ch<='9') return ch - '0';
>>
>> i mean use & instead of &&, this && is kinda nonsense (skipping
>> parenthesis i assume work coz im not sure, but better to assume and
>> debug imo)
>
> the decision not to use && for bitwiseand and || for bitwise was
> clearly idiotic and the question is who did it? ...normal and as & and
> normal or as | is quite standable

Clearly you don't know why this decision was made, yet you are sure it
was idiotic! That's not a good look.

You can find out the whole story with a bit of searching on the web
(keywords: Dennis Ritchie C history Bell Labs).

--
Ben.

środa, 16 sierpnia 2023 o 23:01:32 UTC+2 Ben Bacarisse napisał(a):
> fir <profes...@gmail.com> writes:
>
> > środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
> >> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
> >> >
> >> > if ((ch >= '0') && (ch <= '9)) {
> >> > return ch - '0';
> >> > }
> >> there is a question if not write this
> >>
> >> if(ch>='0' & ch<='9') return ch - '0';
> >>
> >> i mean use & instead of &&, this && is kinda nonsense (skipping
> >> parenthesis i assume work coz im not sure, but better to assume and
> >> debug imo)
> >
> > the decision not to use && for bitwiseand and || for bitwise was
> > clearly idiotic and the question is who did it? ...normal and as & and
> > normal or as | is quite standable
> Clearly you don't know why this decision was made, yet you are sure it
> was idiotic! That's not a good look.
>

i see the bad (idiotic) results - so the decisions leading to them are idiotoc..
im not so bad in logic here

> You can find out the whole story with a bit of searching on the web
> (keywords: Dennis Ritchie C history Bell Labs).
>

środa, 16 sierpnia 2023 o 23:01:32 UTC+2 Ben Bacarisse napisał(a):
> fir <profes...@gmail.com> writes:
>
> > środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
> >> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
> >> >
> >> > if ((ch >= '0') && (ch <= '9)) {
> >> > return ch - '0';
> >> > }
> >> there is a question if not write this
> >>
> >> if(ch>='0' & ch<='9') return ch - '0';
> >>
> >> i mean use & instead of &&, this && is kinda nonsense (skipping
> >> parenthesis i assume work coz im not sure, but better to assume and
> >> debug imo)
> >
> > the decision not to use && for bitwiseand and || for bitwise was
> > clearly idiotic and the question is who did it? ...normal and as & and
> > normal or as | is quite standable
> Clearly you don't know why this decision was made, yet you are sure it
> was idiotic! That's not a good look.
>
> You can find out the whole story with a bit of searching on the web
> (keywords: Dennis Ritchie C history Bell Labs).
>
yyou may quote what was that as im not in mood to search long text ..overally people posting reference to long text assuming somebody has so much time to search this behave not much wise imo

środa, 16 sierpnia 2023 o 23:09:34 UTC+2 fir napisał(a):
> środa, 16 sierpnia 2023 o 23:01:32 UTC+2 Ben Bacarisse napisał(a):
> > fir <profes...@gmail.com> writes:
> >
> > > środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
> > >> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
> > >> >
> > >> > if ((ch >= '0') && (ch <= '9)) {
> > >> > return ch - '0';
> > >> > }
> > >> there is a question if not write this
> > >>
> > >> if(ch>='0' & ch<='9') return ch - '0';
> > >>
> > >> i mean use & instead of &&, this && is kinda nonsense (skipping
> > >> parenthesis i assume work coz im not sure, but better to assume and
> > >> debug imo)
> > >
> > > the decision not to use && for bitwiseand and || for bitwise was
> > > clearly idiotic and the question is who did it? ...normal and as & and
> > > normal or as | is quite standable
> > Clearly you don't know why this decision was made, yet you are sure it
> > was idiotic! That's not a good look.
> >
> i see the bad (idiotic) results - so the decisions leading to them are idiotoc..
> im not so bad in logic here
> > You can find out the whole story with a bit of searching on the web
> > (keywords: Dennis Ritchie C history Bell Labs).
> >

c has some idiotic decisions, but noticing which one are idiotic is not so easy

idiotic is for example decision that local variables in if block or for block are
local to that block, its verry annoying and thsi is idiotic... those blocks in
many cases are not separate blocks when you need to destroy variables but just logical branches .. and the need to declare variables before that vlock is opposite to sugar

David Brown <david.brown@hesbynett.no> writes:

> On 16/08/2023 09:02, Malcolm McLean wrote:
>> On Wednesday, 16 August 2023 at 07:53:32 UTC+1, David Brown wrote:

>>> It is, of course, a terrible idea to do any kind of arithmetic or hold
>>> numbers in plain char - use them for 7-bit ASCII characters only.
>>>
>> I pass about UTF-8 as char *s in Baby X. But of course it is
>> converted to unsigned char for the actual UTF-8 manipulations.

I think too much is often made of this. What is it that you are worried
about? A lot of UTF-8 fiddling is masking values that will have been
promoted to int. The masking can be more portable than the conversion.

> Conversion from plain char to unsigned char will always be safe and
> well-defined, regardless of the signedness of plain char.

It's not UB in the dreaded C sense, but it's not defined in a way that
will help you for UTF-8. Let's say you want to see if *cp (a plain
pointer to signed char) points to a UTF-8 continuation character. I'd
write

(*cp & 0xC0) == 0x80

and the value of six bits represented is *cp & 0x3F, i.e. 2.

Will this fail because char is signed? No. Will it fail if char is
signed and the implementation uses sign-and-magnitude? I don't think so
because UTF-8 mandates the bit pattern not the value. (If anyone has
ever seen UTF-8 on a non-two's complement machine with signed char, do
let me know!)

> And it is always
> safe to access plain char data through an unsigned char pointer.

But what happens if I convert to unsigned char:

const unsigned char *ucp = cp;

Now what is *cp & 0x3F on a sign-and-magnitude machine? It's 62 not 2.

Admittedly, anything but two's complement is now relegated to C's
history even if the machines still exist, so may we should not care
anymore.

--
Ben.

Bart <bc@freeuk.com> writes:
> On 16/08/2023 21:26, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> Unfortunately, in C, string literals have type char*, and char*
>>> strings are encountered everywhere, where they can store ASCII,
>>> extended ASCII of various kinds, or UTF8.
>> No, string literals are of type char[N], where N is the length of the
>> literal plus 1.
>
> Which is usually converted to type char*?

Yes, usually, but by no means always.

> But this makes little difference to my point: you can't really get
> away from C's plain 'char' type if dealing with text and strings.

Agreed.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

fir <profesor.fir@gmail.com> writes:

> środa, 16 sierpnia 2023 o 23:01:32 UTC+2 Ben Bacarisse napisał(a):
>> fir <profes...@gmail.com> writes:
>>
>> > środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
>> >> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
>> >> >
>> >> > if ((ch >= '0') && (ch <= '9)) {
>> >> > return ch - '0';
>> >> > }
>> >> there is a question if not write this
>> >>
>> >> if(ch>='0' & ch<='9') return ch - '0';
>> >>
>> >> i mean use & instead of &&, this && is kinda nonsense (skipping
>> >> parenthesis i assume work coz im not sure, but better to assume and
>> >> debug imo)
>> >
>> > the decision not to use && for bitwiseand and || for bitwise was
>> > clearly idiotic and the question is who did it? ...normal and as & and
>> > normal or as | is quite standable
>> Clearly you don't know why this decision was made, yet you are sure it
>> was idiotic! That's not a good look.
>>
>> You can find out the whole story with a bit of searching on the web
>> (keywords: Dennis Ritchie C history Bell Labs).
>>
> yyou may quote what was that as im not in mood to search long text
> ..overally people posting reference to long text assuming somebody has
> so much time to search this behave not much wise imo

But I should take the time to explain the reasons to you? You don't
want to read up on why C's design is not "idiotic", and I don't want to
try to explain it to you.

--
Ben.

czwartek, 17 sierpnia 2023 o 01:52:15 UTC+2 Ben Bacarisse napisał(a):
> fir <profes...@gmail.com> writes:
>
> > środa, 16 sierpnia 2023 o 23:01:32 UTC+2 Ben Bacarisse napisał(a):
> >> fir <profes...@gmail.com> writes:
> >>
> >> > środa, 16 sierpnia 2023 o 19:30:28 UTC+2 fir napisał(a):
> >> >> środa, 16 sierpnia 2023 o 19:21:28 UTC+2 David Brown napisał(a):
> >> >> >
> >> >> > if ((ch >= '0') && (ch <= '9)) {
> >> >> > return ch - '0';
> >> >> > }
> >> >> there is a question if not write this
> >> >>
> >> >> if(ch>='0' & ch<='9') return ch - '0';
> >> >>
> >> >> i mean use & instead of &&, this && is kinda nonsense (skipping
> >> >> parenthesis i assume work coz im not sure, but better to assume and
> >> >> debug imo)
> >> >
> >> > the decision not to use && for bitwiseand and || for bitwise was
> >> > clearly idiotic and the question is who did it? ...normal and as & and
> >> > normal or as | is quite standable
> >> Clearly you don't know why this decision was made, yet you are sure it
> >> was idiotic! That's not a good look.
> >>
> >> You can find out the whole story with a bit of searching on the web
> >> (keywords: Dennis Ritchie C history Bell Labs).
> >>
> > yyou may quote what was that as im not in mood to search long text
> > ..overally people posting reference to long text assuming somebody has
> > so much time to search this behave not much wise imo
> But I should take the time to explain the reasons to you? You don't
> want to read up on why C's design is not "idiotic", and I don't want to
> try to explain it to you.
>
so why you talk on it? are you an idiot?

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 16/08/2023 09:02, Malcolm McLean wrote:
>>
>>> On Wednesday, 16 August 2023 at 07:53:32 UTC+1, David Brown wrote:
>>>
>>>> It is, of course, a terrible idea to do any kind of arithmetic or
>>>> hold numbers in plain char - use them for 7-bit ASCII characters
>>>> only.
>>>
>>> I pass about UTF-8 as char *s in Baby X. But of course it is
>>> converted to unsigned char for the actual UTF-8 manipulations.
>
> I think too much is often made of this. What is it that you are
> worried about? A lot of UTF-8 fiddling is masking values that will
> have been promoted to int. The masking can be more portable than
> the conversion.

I'm not sure the question is so clear cut. First the pointer
conversion (from char * to unsigned char *) is absolutely
guaranteed to work, and accesses through the unsigned char * are
guaranteed to work. The only question is what bits do you get.
Of course if the implementation is two's complement then it
doesn't matter. But if it isn't, where did the bits come from?
That matters because values that go through <stdio.h> functions
may have been converted to -- or re-interpreted as, it isn't
clear which -- unsigned char. If a file is being read that was
produced under a different implementation, reading the bytes as
char's rather than unsigned char's could result in incorrect
values. Or, unfortunately, vice versa.

Speaking for myself normally I would prefer to do UTF8-style
processing through unsigned char pointers. My reasoning is it's
easier to think about and (probably) more likely to work in the
unusual cases. Also, now that I think of it, safer, because
unsigned char cannot have trap representations. Also if there is
some sort of encoding problem I have more confidence in solving
the problem working directly on unsigned char values than in
reasoning through what will happen when working with the signed
values. Conversely if I were reading code that was doing UTF8
processing and using plain char, I think I would need to work
harder to understand how it works. So FWIW there is a personal
view.

David Brown <david.brown@hesbynett.no> writes:
> On 16/08/2023 14:31, Bart wrote:
>> On 16/08/2023 07:53, David Brown wrote:
>>> Just to be clear about this in case anyone wonders why you wrote
>>> that - plain "char" can be signed or unsigned, depending on the
>>> platform. Older platforms (including x86) tend to have plain char
>>> as signed, while more modern ABIs are usually unsigned.
>>>
>>> It is, of course, a terrible idea to do any kind of arithmetic or
>>> hold numbers in plain char - use them for 7-bit ASCII characters
>>> only.  For anything with numbers, use "signed char", "unsigned
>>> char", or (better, IMHO) appropriate <stdint.h> types when you need
>>> a small integer type.
>>
>> Unfortunately, in C, string literals have type char*, and char*
>> strings are encountered everywhere, where they can store ASCII,
>> extended ASCII of various kinds, or UTF8.
>>
>> But you frequently need to manipulate individual character codes.
>
> It's quite rare to have to manipulate characters individually, other
> than perhaps comparing them to character constants. Certainly general
> arithmetic is very rare on characters, with the exception of something
> like UTF8 code point extraction. Do you have examples where people
> might reasonably want to perform arithmetic on plain char, that you
> think occur frequently?
>
> I think it is entirely appropriate to use "char" for characters (and
> const char* for immutable strings). But I don't think it is
> appropriate for any kind of arithmetic.

How would you hash a string (for example for insertion in a hash table)
without arithmetic?

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On Thu, 17 Aug 2023 10:44:29 +0300
Phil Carmody <pc+usenet@asdf.org> wrote:
> David Brown <david.brown@hesbynett.no> writes:
> > It's quite rare to have to manipulate characters individually, other
> > than perhaps comparing them to character constants. Certainly general
> > arithmetic is very rare on characters, with the exception of something
> > like UTF8 code point extraction. Do you have examples where people
> > might reasonably want to perform arithmetic on plain char, that you
> > think occur frequently?
> >
> > I think it is entirely appropriate to use "char" for characters (and
> > const char* for immutable strings). But I don't think it is
> > appropriate for any kind of arithmetic.
>
> How would you hash a string (for example for insertion in a hash table)
> without arithmetic?

You would cast each element of the string to an unsigned integer type
which won't get promoted to a signed type ; so unsigned int at least.
And then you would feed your hash function the unsigned integers. How
wide these would need to be depends on how many bits the hash values
are supposed to have.

On Thu, 17 Aug 2023 08:17:52 -0000 (UTC)
Spiros Bousbouras <spibou@gmail.com> wrote:
> On Thu, 17 Aug 2023 10:44:29 +0300
> Phil Carmody <pc+usenet@asdf.org> wrote:
> > David Brown <david.brown@hesbynett.no> writes:
> > > It's quite rare to have to manipulate characters individually, other
> > > than perhaps comparing them to character constants. Certainly general
> > > arithmetic is very rare on characters, with the exception of something
> > > like UTF8 code point extraction. Do you have examples where people
> > > might reasonably want to perform arithmetic on plain char, that you
> > > think occur frequently?
> > >
> > > I think it is entirely appropriate to use "char" for characters (and
> > > const char* for immutable strings). But I don't think it is
> > > appropriate for any kind of arithmetic.
> >
> > How would you hash a string (for example for insertion in a hash table)
> > without arithmetic?
>
> You would cast each element of the string to an unsigned integer type
> which won't get promoted to a signed type ; so unsigned int at least.
> And then you would feed your hash function the unsigned integers. How
> wide these would need to be depends on how many bits the hash values
> are supposed to have.

Come to think of it , it has been discussed several times on this group
whether wraparound arithmetic is ever useful. It is useful for hashing and
also for pseudorandom number generators. But for such applications , using
non negative integers is probably preferable.

--
vlaho.ninja/prog

Spiros Bousbouras <spibou@gmail.com> writes:
> On Thu, 17 Aug 2023 08:17:52 -0000 (UTC)
> Spiros Bousbouras <spibou@gmail.com> wrote:
>> On Thu, 17 Aug 2023 10:44:29 +0300
>> Phil Carmody <pc+usenet@asdf.org> wrote:
>> > David Brown <david.brown@hesbynett.no> writes:
>> > > It's quite rare to have to manipulate characters individually, other
>> > > than perhaps comparing them to character constants. Certainly general
>> > > arithmetic is very rare on characters, with the exception of something
>> > > like UTF8 code point extraction. Do you have examples where people
>> > > might reasonably want to perform arithmetic on plain char, that you
>> > > think occur frequently?
>> > >
>> > > I think it is entirely appropriate to use "char" for characters (and
>> > > const char* for immutable strings). But I don't think it is
>> > > appropriate for any kind of arithmetic.
>> >
>> > How would you hash a string (for example for insertion in a hash table)
>> > without arithmetic?
>>
>> You would cast each element of the string to an unsigned integer type
>> which won't get promoted to a signed type ; so unsigned int at least.
>> And then you would feed your hash function the unsigned integers. How
>> wide these would need to be depends on how many bits the hash values
>> are supposed to have.
>
> Come to think of it , it has been discussed several times on this group
> whether wraparound arithmetic is ever useful. It is useful for hashing and
> also for pseudorandom number generators. But for such applications , using
> non negative integers is probably preferable.

Yup, I agree. My example was not a particularly good one at all. Alas,
I think that the pedantic nature of there being up-conversions to int
before the operations are performed, even if the result desired is
another char is confusing matters. I'd say that there are two entirely
supportable answers to the question "is this arithmetic on chars?":
char a=get_a(), b=get_b();
char c=a+b;
For the initial question to even make sense, you need to be prepared to
ignore the pedantic definition of the operation - as it demands that the
answer is "yes".

Phil
--
We are no longer hunters and nomads. No longer awed and frightened, as we have
gained some understanding of the world in which we live. As such, we can cast
aside childish remnants from the dawn of our civilization.
-- NotSanguine on SoylentNews, after Eugen Weber in /The Western Tradition/

On 16/08/2023 19:50, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 16/08/2023 16:43, Scott Lurndal wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 16/08/2023 16:05, Scott Lurndal wrote:
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>> On 16/08/2023 14:31, Bart wrote:
>>>>>>> On 16/08/2023 07:53, David Brown wrote:
>>>>>>>
>>>>>>>> Just to be clear about this in case anyone wonders why you wrote that
>>>>>>>> - plain "char" can be signed or unsigned, depending on the platform.
>>>>>>>> Older platforms (including x86) tend to have plain char as signed,
>>>>>>>> while more modern ABIs are usually unsigned.
>>>>>>>>
>>>>>>>> It is, of course, a terrible idea to do any kind of arithmetic or hold
>>>>>>>> numbers in plain char - use them for 7-bit ASCII characters only.  For
>>>>>>>> anything with numbers, use "signed char", "unsigned char", or (better,
>>>>>>>> IMHO) appropriate <stdint.h> types when you need a small integer type.
>>>>>>>
>>>>>>> Unfortunately, in C, string literals have type char*, and char* strings
>>>>>>> are encountered everywhere, where they can store ASCII, extended ASCII
>>>>>>> of various kinds, or UTF8.
>>>>>>>
>>>>>>> But you frequently need to manipulate individual character codes.
>>>>>>
>>>>>> It's quite rare to have to manipulate characters individually, other
>>>>>> than perhaps comparing them to character constants. Certainly general
>>>>>> arithmetic is very rare on characters, with the exception of something
>>>>>> like UTF8 code point extraction.
>>>>>
>>>>> toupper() and tolower() were often implemented using arithmetic
>>>>> on characters in the C locale, but the point stands.
>>>>>
>>>>
>>>> Surely that would be logical instructions (x &= ~0x20, or x |= 0x20)
>>>> rather than arithmetic instructions? But I wouldn't do logical
>>>> operations on plain char either! (The C library implementation can, of
>>>> course, do whatever it likes.)
>>>
>>> Unix v7:
>>> #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]&(_N|_X))
>>> #define isspace(c) ((_ctype_+1)[c]&_S)
>>> #define ispunct(c) ((_ctype_+1)[c]&_P)
>>> #define isalnum(c) ((_ctype_+1)[c]&(_U|_L|_N))
>>> #define isprint(c) ((_ctype_+1)[c]&(_P|_U|_L|_N))
>>> #define iscntrl(c) ((_ctype_+1)[c]&_C)
>>> #define isascii(c) ((unsigned)(c)<=0177)
>>> #define toupper(c) ((c)-'a'+'A')
>>> #define tolower(c) ((c)-'A'+'a')
>>> #define toascii(c) ((c)&0177)
>>>
>>
>> Those "toupper" and "tolower" macros are going to give the wrong result
>> for any argument that is not a lower case or upper case (respectively)
>> ASCII letter.
>
> Which in 1979 when Unix V7 in the wild is why isalpha was used to qualify toupper/lower.

That would not suffice - you'd need isupper() or islower() :

#define useful_tolower(c) isupper((c)) ? tolower((c)) : (c)
#define useful_toupper(c) islower((c)) ? toupper((c)) : (c)

>
>> The C standards require the macros to return the argument
>
> The above header file predated the standard by a number of years.
>

Fair enough. Some things have got better over time!

On 16/08/2023 19:25, Bart wrote:
> On 16/08/2023 14:31, David Brown wrote:
>> On 16/08/2023 14:31, Bart wrote:
>>> On 16/08/2023 07:53, David Brown wrote:
>>>
>>>> Just to be clear about this in case anyone wonders why you wrote
>>>> that - plain "char" can be signed or unsigned, depending on the
>>>> platform. Older platforms (including x86) tend to have plain char as
>>>> signed, while more modern ABIs are usually unsigned.
>>>>
>>>> It is, of course, a terrible idea to do any kind of arithmetic or
>>>> hold numbers in plain char - use them for 7-bit ASCII characters
>>>> only.  For anything with numbers, use "signed char", "unsigned
>>>> char", or (better, IMHO) appropriate <stdint.h> types when you need
>>>> a small integer type.
>>>
>>> Unfortunately, in C, string literals have type char*, and char*
>>> strings are encountered everywhere, where they can store ASCII,
>>> extended ASCII of various kinds, or UTF8.
>>>
>>> But you frequently need to manipulate individual character codes.
>>
>> It's quite rare to have to manipulate characters individually, other
>> than perhaps comparing them to character constants.  Certainly general
>> arithmetic is very rare on characters, with the exception of something
>> like UTF8 code point extraction.  Do you have examples where people
>> might reasonably want to perform arithmetic on plain char, that you
>> think occur frequently?
>
> It's just something that will come up:
>
> * Relative compares such as:  c >= 'A'

Agreed (as I mentioned).

>
> * Getting the next character in the alphabet: c + 1 (eg. rot13)

Is that common? I agree it can be found in code, but how frequent is it?

>
> * Turning characters into a number: (c-'0')*10 + (d-'0')

Yes, subtracting or adding '0' is a clear use-case that turns up quite
often.

>
> * Using character codes to index into an array: ++counts[c]

That is a fair point, since "counts[c]" means "*(counts + c)". I'd be
extremely careful of doing this, however, precisely because on some
systems, plain char is signed. It's easy to accidentally try to access
negative indexes. (Of course you have to be careful with any array
access to make sure your indexes are in range.)

>
> * Decoding/encoding of different kinds
>
> * Calculating a hash value from a sequence of characters
>
> Etc.
>
> You can just decree that can you can't do anything with a char values
> except compare two characters for equality.
>

I did not decree anything of the sort. I simply said I don't think
arithmetic on plain char (rather than signed or unsigned char) is very
common, and I don't think it is a good idea. (And I also said
comparisons to character literals are common - I did not restrict that
to equality comparisons, because relative comparisons are common.)

You've given a few more cases when it arithmetic on plain chars might
turn up, so maybe it is more common than I first thought. I still think
it is rarely a good idea, but that's just a matter of opinion.

(As noted before - the chars are of course promoted to int, or
hypothetically unsigned int, before the actual arithmetic is performed.)

On 17/08/2023 10:51, Spiros Bousbouras wrote:
> On Thu, 17 Aug 2023 08:17:52 -0000 (UTC)
> Spiros Bousbouras <spibou@gmail.com> wrote:
>> On Thu, 17 Aug 2023 10:44:29 +0300
>> Phil Carmody <pc+usenet@asdf.org> wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> It's quite rare to have to manipulate characters individually, other
>>>> than perhaps comparing them to character constants. Certainly general
>>>> arithmetic is very rare on characters, with the exception of something
>>>> like UTF8 code point extraction. Do you have examples where people
>>>> might reasonably want to perform arithmetic on plain char, that you
>>>> think occur frequently?
>>>>
>>>> I think it is entirely appropriate to use "char" for characters (and
>>>> const char* for immutable strings). But I don't think it is
>>>> appropriate for any kind of arithmetic.
>>>
>>> How would you hash a string (for example for insertion in a hash table)
>>> without arithmetic?
>>
>> You would cast each element of the string to an unsigned integer type
>> which won't get promoted to a signed type ; so unsigned int at least.
>> And then you would feed your hash function the unsigned integers. How
>> wide these would need to be depends on how many bits the hash values
>> are supposed to have.

Or you would use unsigned char - viewing the string as a block of
memory. (The unsigned char would then be promoted or converted - I
would convert it to an unsigned int type.)

>
> Come to think of it , it has been discussed several times on this group
> whether wraparound arithmetic is ever useful. It is useful for hashing and
> also for pseudorandom number generators. But for such applications , using
> non negative integers is probably preferable.
>

Agreed.