Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #172278 > unrolled thread

signed/unsigned - what will fail

Back to article view | Back to comp.lang.c

Contents

  signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-15 06:50 -0700
    Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-15 06:59 -0700
      Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-15 07:03 -0700
      Re: signed/unsigned - what will fail Öö Tiib <ootiib@hot.ee> - 2023-08-15 07:44 -0700
        Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-15 08:01 -0700
          Re: signed/unsigned - what will fail Öö Tiib <ootiib@hot.ee> - 2023-08-15 09:48 -0700
            Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 08:53 +0200
              Re: signed/unsigned - what will fail Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 00:02 -0700
                Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 13:05 +0200
                  Re: signed/unsigned - what will fail Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 22:40 +0100
                    Re: signed/unsigned - what will fail Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-08-16 20:12 -0700
              Re: signed/unsigned - what will fail Bart <bc@freeuk.com> - 2023-08-16 13:31 +0100
                Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 15:31 +0200
                  Re: signed/unsigned - what will fail scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 14:05 +0000
                    Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 16:20 +0200
                      Re: signed/unsigned - what will fail scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 14:43 +0000
                        Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 19:16 +0200
                          Re: signed/unsigned - what will fail scott@slp53.sl.home (Scott Lurndal) - 2023-08-16 17:50 +0000
                            Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-17 16:05 +0200
                  Re: signed/unsigned - what will fail Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-08-16 07:35 -0700
                    Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-16 19:21 +0200
                      Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 10:30 -0700
                        Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 10:33 -0700
                          Re: signed/unsigned - what will fail Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 22:01 +0100
                            Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 14:09 -0700
                              Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 14:29 -0700
                            Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 14:14 -0700
                              Re: signed/unsigned - what will fail Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-17 00:52 +0100
                                Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 17:07 -0700
                        Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 12:52 -0700
                          Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 13:13 -0700
                      Re: signed/unsigned - what will fail Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-08-16 21:52 +0100
                  Re: signed/unsigned - what will fail Bart <bc@freeuk.com> - 2023-08-16 18:25 +0100
                    Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-17 16:15 +0200
                  Re: signed/unsigned - what will fail Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 10:44 +0300
                    Re: signed/unsigned - what will fail Spiros Bousbouras <spibou@gmail.com> - 2023-08-17 08:17 +0000
                      Re: signed/unsigned - what will fail Spiros Bousbouras <spibou@gmail.com> - 2023-08-17 08:51 +0000
                        Re: signed/unsigned - what will fail Phil Carmody <pc+usenet@asdf.org> - 2023-08-17 15:11 +0300
                        Re: signed/unsigned - what will fail David Brown <david.brown@hesbynett.no> - 2023-08-17 21:20 +0200
                Re: signed/unsigned - what will fail Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 13:26 -0700
                  Re: signed/unsigned - what will fail Bart <bc@freeuk.com> - 2023-08-16 21:51 +0100
                    Re: signed/unsigned - what will fail Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-08-16 15:35 -0700
              Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 08:14 -0700
                Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 08:34 -0700
                  Re: signed/unsigned - what will fail fir <profesor.fir@gmail.com> - 2023-08-16 08:48 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#172393

On 16/08/2023 16:35, Malcolm McLean wrote:
> On Wednesday, 16 August 2023 at 14:31:51 UTC+1, 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?
>>
>> 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);
> 
> to convert from character to digit. But people like efficiency.
> 

It would still not be arithmetic on chars.

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.

[toc] | [prev] | [next] | [standalone]

#172395

ś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)

[toc] | [prev] | [next] | [standalone]

#172396

ś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

[toc] | [prev] | [next] | [standalone]

#172412

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.

[toc] | [prev] | [next] | [standalone]

#172413

ś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). 
> 

[toc] | [prev] | [next] | [standalone]

#172416

ś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

[toc] | [prev] | [next] | [standalone]

#172414

ś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

[toc] | [prev] | [next] | [standalone]

#172424

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.

[toc] | [prev] | [next] | [standalone]

#172426

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?

[toc] | [prev] | [next] | [standalone]

#172404

ś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

[toc] | [prev] | [next] | [standalone]

#172406

ś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();

[toc] | [prev] | [next] | [standalone]

#172411

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.

[toc] | [prev] | [next] | [standalone]

#172394

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'

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

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

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

* 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.

[toc] | [prev] | [next] | [standalone]

#172458

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.)

[toc] | [prev] | [next] | [standalone]

#172435

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/

[toc] | [prev] | [next] | [standalone]

#172436

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.

[toc] | [prev] | [next] | [standalone]

#172437

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

[toc] | [prev] | [next] | [standalone]

#172450

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/

[toc] | [prev] | [next] | [standalone]

#172474

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.

[toc] | [prev] | [next] | [standalone]

#172407

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 */

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web