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

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

signed/unsigned - what will fail

Started byfir <profesor.fir@gmail.com>
First post2023-08-15 06:50 -0700
Last post2023-08-16 08:48 -0700
Articles 5 on this page of 45 — 11 participants

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 3 of 3 — ← Prev page 1 2 [3]

#172410

FromBart <bc@freeuk.com>
Date2023-08-16 21:51 +0100
Message-ID<ubjcsv$3efav$1@dont-email.me>
In reply to#172407
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.

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

#172420

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2023-08-16 15:35 -0700
Message-ID<87y1iak44d.fsf@nosuchdomain.example.com>
In reply to#172410
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 */

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

#172382

Fromfir <profesor.fir@gmail.com>
Date2023-08-16 08:14 -0700
Message-ID<88a6f46b-d2aa-49ff-a60f-36448e126af3n@googlegroups.com>
In reply to#172352
środa, 16 sierpnia 2023 o 08:53:32 UTC+2 David Brown napisał(a):
> On 15/08/2023 18:48, Öö Tiib wrote: 
> > On Tuesday, 15 August 2023 at 18:01:23 UTC+3, fir wrote: 
> >> wtorek, 15 sierpnia 2023 o 16:45:07 UTC+2 Öö Tiib napisał(a): 
> >>> On Tuesday, 15 August 2023 at 16:59:15 UTC+3, fir wrote: 
> >>>> wtorek, 15 sierpnia 2023 o 15:51:07 UTC+2 fir napisał(a): 
> >>>>> im not sure if im a fan of division signed/unsigned 
> >>>>> (for example maybe there are cases where you dont care 
> >>>>> and in such case treat given int as both signed and unsigned 
> >>>>> (as it kinda is) 
> >>>>> 
> >>>>> im not stating hovever to define 3 tates signed, unsigned, and 
> >>>>> dontcare or just remove signed unsigned or what else - becouse i dont 
> >>>>> know, i dont understand it enough well 
> >>>>> 
> >>>>> but asume i use dont care (and always write just "int"): 
> >>>>> what will exactly fail? 
> >>>> im not sure but probably could assume that additions and subtractions are safe, 
> >>>> but im not sure: 
> >>>> 
> >>>> seay 
> >>>> 
> >>>> char a = 200, b= 200; 
> >>>> 
> >>> You contradict your "and always write just "int"" I see clearly char there. 
> >>> 
> >>> Do you turn off warnings on your compilers? With gcc you get most likely 
> >>> something like: "warning: overflow in conversion from 'int' to 'char' changes 
> >>> value from '200' to '-56' [-Woverflow]" 
> >>>> int c = a+b; //is it 400? 
> >>> Can be, but it is more likely -112.
> 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. 
> 
> So after "char a = 200;", the value in "a" depends on the target's ABI. 
> (Enabling warnings on the compiler is always a good idea!)
> >>>> 
> >>>> int d = a*b; //what with that? 
> >>> Can be 40000, 3136, -25536, what is your point? 
> >> 
> >> it cant be 2 or 3 at once it is one of it..
> If plain char is signed on the target, then "d" will always be 3136. 
> 
> If plain char is unsigned and int is bigger than 16 bit (generally 32 
> bit) on the target, then "d" will always be 40000. 
> 
> If plain char is unsigned and int is 16-bit, then there is an arithmetic 
> overflow in the signed int multiplication - that's undefined behaviour, 
> and there's no limit to what can go wrong, including the compiler 
> generating code that treats the result as 2 or 3 of these values. 
> Often, it will appear to be -25536 - but that is not guaranteed or 
> reliable in any way (without specific compiler flags or documentation). 
> 
> (I know you, Öö, know this - but fir may be less sure.)


i told some tiem ago i learned c totally in 2014 or something (talking abut statement c is said by someone to be simple) - as to this signed unsigned piece of mess i dont know this...
though i got some idea - it seem to me that general arithmetoc should be done nearly always on signed - as unsigned types may be said are not to be to do arithmetic maybe, they are for logical/bytelike types for more bit operations

thsi maybe signed/unsigned is kinda misleading suggesting both are something liek arithmetic types with two wariants, where arithmetic is int

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

#172385

Fromfir <profesor.fir@gmail.com>
Date2023-08-16 08:34 -0700
Message-ID<1b45016f-bb5b-430e-a5d9-47f1b61fe5ecn@googlegroups.com>
In reply to#172382
środa, 16 sierpnia 2023 o 17:14:44 UTC+2 fir napisał(a):
> środa, 16 sierpnia 2023 o 08:53:32 UTC+2 David Brown napisał(a): 
> > On 15/08/2023 18:48, Öö Tiib wrote: 
> > > On Tuesday, 15 August 2023 at 18:01:23 UTC+3, fir wrote: 
> > >> wtorek, 15 sierpnia 2023 o 16:45:07 UTC+2 Öö Tiib napisał(a): 
> > >>> On Tuesday, 15 August 2023 at 16:59:15 UTC+3, fir wrote: 
> > >>>> wtorek, 15 sierpnia 2023 o 15:51:07 UTC+2 fir napisał(a): 
> > >>>>> im not sure if im a fan of division signed/unsigned 
> > >>>>> (for example maybe there are cases where you dont care 
> > >>>>> and in such case treat given int as both signed and unsigned 
> > >>>>> (as it kinda is) 
> > >>>>> 
> > >>>>> im not stating hovever to define 3 tates signed, unsigned, and 
> > >>>>> dontcare or just remove signed unsigned or what else - becouse i dont 
> > >>>>> know, i dont understand it enough well 
> > >>>>> 
> > >>>>> but asume i use dont care (and always write just "int"): 
> > >>>>> what will exactly fail? 
> > >>>> im not sure but probably could assume that additions and subtractions are safe, 
> > >>>> but im not sure: 
> > >>>> 
> > >>>> seay 
> > >>>> 
> > >>>> char a = 200, b= 200; 
> > >>>> 
> > >>> You contradict your "and always write just "int"" I see clearly char there. 
> > >>> 
> > >>> Do you turn off warnings on your compilers? With gcc you get most likely 
> > >>> something like: "warning: overflow in conversion from 'int' to 'char' changes 
> > >>> value from '200' to '-56' [-Woverflow]" 
> > >>>> int c = a+b; //is it 400? 
> > >>> Can be, but it is more likely -112. 
> > 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. 
> > 
> > So after "char a = 200;", the value in "a" depends on the target's ABI. 
> > (Enabling warnings on the compiler is always a good idea!) 
> > >>>> 
> > >>>> int d = a*b; //what with that? 
> > >>> Can be 40000, 3136, -25536, what is your point? 
> > >> 
> > >> it cant be 2 or 3 at once it is one of it.. 
> > If plain char is signed on the target, then "d" will always be 3136. 
> > 
> > If plain char is unsigned and int is bigger than 16 bit (generally 32 
> > bit) on the target, then "d" will always be 40000. 
> > 
> > If plain char is unsigned and int is 16-bit, then there is an arithmetic 
> > overflow in the signed int multiplication - that's undefined behaviour, 
> > and there's no limit to what can go wrong, including the compiler 
> > generating code that treats the result as 2 or 3 of these values. 
> > Often, it will appear to be -25536 - but that is not guaranteed or 
> > reliable in any way (without specific compiler flags or documentation). 
> > 
> > (I know you, Öö, know this - but fir may be less sure.)
> i told some tiem ago i learned c totally in 2014 or something (talking abut statement c is said by someone to be simple) - as to this signed unsigned piece of mess i dont know this... 
> though i got some idea - it seem to me that general arithmetoc should be done nearly always on signed - as unsigned types may be said are not to be to do arithmetic maybe, they are for logical/bytelike types for more bit operations 
> 
> thsi maybe signed/unsigned is kinda misleading suggesting both are something liek arithmetic types with two wariants, where arithmetic is int

other part of thought is in fact people can say when saying say char as
a thing that is not "signed char" and "unsigned char" or "negative unsigned char" (with values -1 to -256 ? or 0 to -255?) but some abstract union of this

and the question is if use this abstract union is not wisest

becouse when someone says write char a =200 (when char on given platform is signed) and char b =200 then the question is if 
int c = a*b; shouldnt be in fact 40000

should it or should not?

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

#172386

Fromfir <profesor.fir@gmail.com>
Date2023-08-16 08:48 -0700
Message-ID<7f816bce-d897-453a-bc5e-820b2e5bf8e4n@googlegroups.com>
In reply to#172385
środa, 16 sierpnia 2023 o 17:35:09 UTC+2 fir napisał(a):
> środa, 16 sierpnia 2023 o 17:14:44 UTC+2 fir napisał(a): 
> > środa, 16 sierpnia 2023 o 08:53:32 UTC+2 David Brown napisał(a): 
> > > On 15/08/2023 18:48, Öö Tiib wrote: 
> > > > On Tuesday, 15 August 2023 at 18:01:23 UTC+3, fir wrote: 
> > > >> wtorek, 15 sierpnia 2023 o 16:45:07 UTC+2 Öö Tiib napisał(a): 
> > > >>> On Tuesday, 15 August 2023 at 16:59:15 UTC+3, fir wrote: 
> > > >>>> wtorek, 15 sierpnia 2023 o 15:51:07 UTC+2 fir napisał(a): 
> > > >>>>> im not sure if im a fan of division signed/unsigned 
> > > >>>>> (for example maybe there are cases where you dont care 
> > > >>>>> and in such case treat given int as both signed and unsigned 
> > > >>>>> (as it kinda is) 
> > > >>>>> 
> > > >>>>> im not stating hovever to define 3 tates signed, unsigned, and 
> > > >>>>> dontcare or just remove signed unsigned or what else - becouse i dont 
> > > >>>>> know, i dont understand it enough well 
> > > >>>>> 
> > > >>>>> but asume i use dont care (and always write just "int"): 
> > > >>>>> what will exactly fail? 
> > > >>>> im not sure but probably could assume that additions and subtractions are safe, 
> > > >>>> but im not sure: 
> > > >>>> 
> > > >>>> seay 
> > > >>>> 
> > > >>>> char a = 200, b= 200; 
> > > >>>> 
> > > >>> You contradict your "and always write just "int"" I see clearly char there. 
> > > >>> 
> > > >>> Do you turn off warnings on your compilers? With gcc you get most likely 
> > > >>> something like: "warning: overflow in conversion from 'int' to 'char' changes 
> > > >>> value from '200' to '-56' [-Woverflow]" 
> > > >>>> int c = a+b; //is it 400? 
> > > >>> Can be, but it is more likely -112. 
> > > 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. 
> > > 
> > > So after "char a = 200;", the value in "a" depends on the target's ABI. 
> > > (Enabling warnings on the compiler is always a good idea!) 
> > > >>>> 
> > > >>>> int d = a*b; //what with that? 
> > > >>> Can be 40000, 3136, -25536, what is your point? 
> > > >> 
> > > >> it cant be 2 or 3 at once it is one of it.. 
> > > If plain char is signed on the target, then "d" will always be 3136. 
> > > 
> > > If plain char is unsigned and int is bigger than 16 bit (generally 32 
> > > bit) on the target, then "d" will always be 40000. 
> > > 
> > > If plain char is unsigned and int is 16-bit, then there is an arithmetic 
> > > overflow in the signed int multiplication - that's undefined behaviour, 
> > > and there's no limit to what can go wrong, including the compiler 
> > > generating code that treats the result as 2 or 3 of these values. 
> > > Often, it will appear to be -25536 - but that is not guaranteed or 
> > > reliable in any way (without specific compiler flags or documentation). 
> > > 
> > > (I know you, Öö, know this - but fir may be less sure.) 
> > i told some tiem ago i learned c totally in 2014 or something (talking abut statement c is said by someone to be simple) - as to this signed unsigned piece of mess i dont know this... 
> > though i got some idea - it seem to me that general arithmetoc should be done nearly always on signed - as unsigned types may be said are not to be to do arithmetic maybe, they are for logical/bytelike types for more bit operations 
> > 
> > thsi maybe signed/unsigned is kinda misleading suggesting both are something liek arithmetic types with two wariants, where arithmetic is int
> other part of thought is in fact people can say when saying say char as 
> a thing that is not "signed char" and "unsigned char" or "negative unsigned char" (with values -1 to -256 ? or 0 to -255?) but some abstract union of this 
> 
> and the question is if use this abstract union is not wisest 
> 
> becouse when someone says write char a =200 (when char on given platform is signed) and char b =200 then the question is if 
> int c = a*b; shouldnt be in fact 40000 
> 
> should it or should not?

i mean then char is "signed char a =200;" and b is signed char b = 200
then the result should be probably -56*-56 but if a is "char a =200"
maybe the char shouldnt be either  signed nor unsigned but 'abstract' and the result should be 40000 (maybe, i dont saying definitely)

[toc] | [prev] | [standalone]

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

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

csiph-web