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?

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;

int c = a+b; //is it 400?

int d = a*b; //what with that?

wtorek, 15 sierpnia 2023 o 15:59:15 UTC+2 fir napisał(a):
> 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;
>
> int c = a+b; //is it 400?
>
> int d = a*b; //what with that?

i would also like probably to insight the thesis that programming language like c should be donte maybe thsi way that maybe thsi kind of expresions should work like int and char woudl be of class "dontcare" i mean possibly giving proper results for a=b=-20, and a=b=200; (and maybe even a=b=-200) but i dont 'inspected' it all

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.

>
> int d = a*b; //what with that?

Can be 40000, 3136, -25536, what is your point?

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

points may be many but im close to think that such "expresiion" shouldgenerally 'carry'
a real value this way if

int a = -200, b=-200;
int c = a*b ; c should be 40000 and so on

i think possibly classes like signed unsigned maybe should be more use for storage arrays not much in normal calculations

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.
> > >
> > > 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..
>
It may cause signed integer overflow on 8 bit or 16 bit embedded system
and that is undefined behavior unless something defines it for said system.

>
> points may be many but im close to think that such "expresiion" shouldgenerally 'carry'
> a real value this way if
>
> int a = -200, b=-200;
> int c = a*b ; c should be 40000 and so on
>
> i think possibly classes like signed unsigned maybe should be more use for storage arrays not much in normal calculations

How so? If on 8 bit microcontroller int has 16 bits of storage with value
range -32768 to 32767 then there are no way how it can be 40000.
It is simply impossible for c to have that value.

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

>>
> It may cause signed integer overflow on 8 bit or 16 bit embedded system
> and that is undefined behavior unless something defines it for said system.
>
>>
>> points may be many but im close to think that such "expresiion" shouldgenerally 'carry'
>> a real value this way if
>>
>> int a = -200, b=-200;
>> int c = a*b ; c should be 40000 and so on
>>
>> i think possibly classes like signed unsigned maybe should be more use for storage arrays not much in normal calculations
>
> How so? If on 8 bit microcontroller int has 16 bits of storage with value
> range -32768 to 32767 then there are no way how it can be 40000.
> It is simply impossible for c to have that value.

On Wednesday, 16 August 2023 at 07:53:32 UTC+1, David Brown wrote:
> 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.
>
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.

On 16/08/2023 09:02, Malcolm McLean wrote:
> On Wednesday, 16 August 2023 at 07:53:32 UTC+1, David Brown wrote:
>> 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.
>>
> 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.

Conversion from plain char to unsigned char will always be safe and
well-defined, regardless of the signedness of plain char. And it is
always safe to access plain char data through an unsigned char pointer.
Given that string literals are treated as char array (unless you have an
encoding prefix for wide characters of some kind), using plain char
seems entirely reasonable. But "const char *" would be vastly better.

(The conversion from unsigned char to plain char is implementation
dependent, but I know of no platforms where it will not work in the
simple and obvious way.)

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.

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.

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.

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

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

strchr("0123456789", ch);

to convert from character to digit. But people like efficiency.

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)

Unixware 2.01:

#define isascii(c) (!((c) & ~0177))
#define toascii(c) ((c) & 0177)

#if defined(_XOPEN_SOURCE) || (__STDC__ == 0 \
&& !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE))
#define _toupper(c) ((__ctype + 258)[c])
#define _tolower(c) ((__ctype + 258)[c])

>

ś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

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

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

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. The C standards require the macros to return the argument
unchanged except when the character can be made upper-case or
lower-case. Maybe these macros were from pre-C90 C, but they are pretty
useless as they stand. (C99 says they are functions, not macros, but
maybe that too has changed. The functions take an "int" argument, so
there is no attempt at arithmetic on (promoted) chars.)

>
> Unixware 2.01:
>
> #define isascii(c) (!((c) & ~0177))
> #define toascii(c) ((c) & 0177)
>
> #if defined(_XOPEN_SOURCE) || (__STDC__ == 0 \
> && !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE))
> #define _toupper(c) ((__ctype + 258)[c])
> #define _tolower(c) ((__ctype + 258)[c])
>
>>

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.

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.

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

ś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

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.

> The C standards require the macros to return the argument

The above header file predated the standard by a number of years.

ś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