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

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

Default signedness of 'plain' char.

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

Contents

  Default signedness of 'plain' char. gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-02 14:17 +0000
    Re: Default signedness of 'plain' char. Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 02:45 +0800
      Re: Default signedness of 'plain' char. gazelle@shell.xmission.com (Kenny McCormack) - 2026-08-03 01:47 +0000
        Re: Default signedness of 'plain' char. Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 23:14 +0800
          Re: Default signedness of 'plain' char. bart <bc@freeuk.com> - 2026-08-03 17:04 +0100
            The Spanish Inquisition (was: Re: Default signedness of 'plain' char.) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-04 00:23 +0800
              Re: The Spanish Inquisition bart <bc@freeuk.com> - 2026-08-03 18:03 +0100
                Re: The Spanish Inquisition Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-04 01:26 +0800
          Re: Default signedness of 'plain' char. Theo <theom+news@chiark.greenend.org.uk> - 2026-08-04 13:13 +0100
            Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 07:30 +0000
              Re: Default signedness of 'plain' char. Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 18:18 +0800
                Re: Default signedness of 'plain' char. bart <bc@freeuk.com> - 2026-08-05 17:20 +0100
                  Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 21:57 +0000
                  Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-05 15:29 -0700
    Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-03 09:56 +0200
      Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-03 13:56 -0500
    Re: Default signedness of 'plain' char. antispam@fricas.org (Waldek Hebisch) - 2026-08-03 13:48 +0000
    Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-03 14:47 +0000
    Re: Default signedness of 'plain' char. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-08-03 14:47 +0000
      Re: Default signedness of 'plain' char. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-08-03 15:04 +0000
        Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 16:58 -0700
          Re: Default signedness of 'plain' char. Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2026-08-04 15:10 +0000
            Re: Default signedness of 'plain' char. scott@slp53.sl.home (Scott Lurndal) - 2026-08-04 15:50 +0000
            Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 03:00 +0000
            Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-05 09:01 +0200
        Re: Default signedness of 'plain' char. antispam@fricas.org (Waldek Hebisch) - 2026-08-04 18:10 +0000
          Compilers targetting the C64 (was: Re: Default signedness of 'plain' char.) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:17 +0800
          Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-04 16:25 -0500
          Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 02:57 +0000
            Re: Default signedness of 'plain' char. Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-05 00:19 -0500
              Re: Default signedness of 'plain' char. Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 18:57 +0800
              Re: Default signedness of 'plain' char. scott@slp53.sl.home (Scott Lurndal) - 2026-08-05 14:33 +0000
              Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-05 22:38 +0000
          Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-04 21:36 -0700
            Re: Default signedness of 'plain' char. antispam@fricas.org (Waldek Hebisch) - 2026-08-06 00:21 +0000
    Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:20 -0700
      Re: Default signedness of 'plain' char. bart <bc@freeuk.com> - 2026-08-03 22:06 +0100
        Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 14:25 -0700
          Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-03 18:38 -0500
            Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:34 -0700
              Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-05 04:40 -0500
            Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 07:22 +0000
              Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-05 04:02 -0500
                Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-05 12:35 +0200
                Re: Default signedness of 'plain' char. Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 18:49 +0800
                  Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-05 12:39 -0700
                    Dear Chris (was: Re: Default signedness of 'plain' char.) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-06 20:15 +0800
                      Re: Dear Chris bart <bc@freeuk.com> - 2026-08-06 15:05 +0100
                        Re: Dear Chris Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-06 23:16 +0800
                        Re: Dear Chris David Brown <david.brown@hesbynett.no> - 2026-08-06 20:10 +0200
                Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 21:54 +0000
                  Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-06 04:49 -0500
                    Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-07 00:10 +0000
                      Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-07 09:56 +0200
              Re: Default signedness of 'plain' char. James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-05 13:33 -0400
                Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 21:50 +0000
                  Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-06 10:34 +0200
                    Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-09 15:19 -0500
                      Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-09 20:33 +0000
                        Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-09 18:04 -0700
                          Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-10 02:45 +0000
                            Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-10 02:24 -0700
                      Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-09 18:03 -0700
                        Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-10 08:58 +0200
                          Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-10 15:17 -0500
                            Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-10 15:19 -0700
                              Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-10 17:31 -0500
                                Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-10 23:48 +0000
                                Re: Default signedness of 'plain' char. James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-10 20:03 -0400
                                  Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-10 20:44 -0500
                                    Re: Default signedness of 'plain' char. James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-11 11:17 -0400
                                      Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-11 14:54 -0500
                                        Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 03:36 +0000
                                          Re: Quaternions (was Re: Default signedness of 'plain' char.) BGB <cr88192@gmail.com> - 2026-08-12 01:24 -0500
                                            Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 07:47 +0000
                                              Re: Quaternions (was Re: Default signedness of 'plain' char.) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:52 -0700
                                                Re: Quaternions (was Re: Default signedness of 'plain' char.) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:56 -0700
                                                Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 02:16 +0000
                                                  Re: Quaternions (was Re: Default signedness of 'plain' char.) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 21:04 -0700
                                                Re: Quaternions (was Re: Default signedness of 'plain' char.) BGB <cr88192@gmail.com> - 2026-08-12 23:07 -0500
                                                  Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 05:00 +0000
                                                    Re: Quaternions (was Re: Default signedness of 'plain' char.) BGB <cr88192@gmail.com> - 2026-08-13 04:37 -0500
                                                      Re: Quaternions (was Re: Default signedness of 'plain' char.) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 14:36 -0700
                                                        Re: Quaternions (was Re: Default signedness of 'plain' char.) BGB <cr88192@gmail.com> - 2026-08-13 23:07 -0500
                                                      Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 23:44 +0000
                                                        Re: Quaternions (was Re: Default signedness of 'plain' char.) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 18:50 -0700
                                                          Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 02:41 +0000
                                                            Re: Quaternions (was Re: Default signedness of 'plain' char.) BGB <cr88192@gmail.com> - 2026-08-13 23:47 -0500
                                                              Re: Quaternions (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 04:59 +0000
                                      Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-11 13:47 -0700
                                        Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-13 23:50 -0500
                                          Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 05:59 +0000
                                            Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-14 03:16 -0500
                                              Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 08:32 +0000
                                            Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:36 -0700
                                              Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-15 03:16 +0000
                                                Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 22:38 -0700
                                                  Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-16 00:08 +0000
                                          Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:17 -0700
                                  Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-11 13:46 +0000
                                    Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-11 13:49 -0700
                                Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-11 08:58 +0200
                                  Re: Default signedness of 'plain' char. BGB <cr88192@gmail.com> - 2026-08-11 04:03 -0500
                            Re: Default signedness of 'plain' char. steve g <Sgonedes1977@gmail.com> - 2026-08-10 20:29 -0400
                            Re: Vectors! Quaternions! (was Re: Default signedness of 'plain' char.) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-11 03:58 +0000
                            Re: Default signedness of 'plain' char. David Brown <david.brown@hesbynett.no> - 2026-08-11 09:06 +0200
                      Re: Default signedness of 'plain' char. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-10 21:15 -0700
                        Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-11 04:52 +0000
                          Re: Default signedness of 'plain' char. Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-11 06:45 -0700
                            Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-11 14:01 -0700
              Re: Default signedness of 'plain' char. "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-05 12:36 -0700
      Re: Default signedness of 'plain' char. Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-05 07:18 +0000
    Re: Default signedness of 'plain' char. Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-05 18:30 -0500
      Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-05 16:41 -0700
        Re: Default signedness of 'plain' char. bart <bc@freeuk.com> - 2026-08-06 01:24 +0100
          Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-05 17:46 -0700
          Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-06 22:59 +0000
            Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-06 19:54 -0700
              Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-07 11:02 +0000
                Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-07 10:35 -0700
                  Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-07 18:32 +0000
                    Re: Default signedness of 'plain' char. Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-07 20:55 +0200
                Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-07 20:51 +0200
                  Re: Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-07 13:03 -0700
                    Re: Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-07 13:32 -0700
                    Re: Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-07 21:44 +0000
                    Re: Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-07 23:47 +0200
                      Re: Use of isascii() back in early days (was Re: Default signedness of 'plain' char.) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-07 15:26 -0700
        Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-06 22:57 +0000
          Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-06 18:23 -0700
            Re: Default signedness of 'plain' char. cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-07 11:47 +0000
      Re: Default signedness of 'plain' char. scott@slp53.sl.home (Scott Lurndal) - 2026-08-06 14:40 +0000
        Re: Default signedness of 'plain' char. Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-06 15:33 -0700

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

#401027

On 8/11/2026 6:46 AM, Dan Cross wrote:
> In article <115dot7$3ihmr$1@dont-email.me>,
> James Kuyper  <jameskuyper@alumni.caltech.edu> wrote:
>> On 2026-08-10 18:31, BGB wrote:
>> ...> Snipped section included my epic fail at trying to use traditional
>> style
>>> mathematical notation in a Usenet post...
>>>
>>> It was bugging me, by implying the conjugate was a scalar, where no, the
>>> conjugate is not a scalar...
>>
>> I'm not sure what you're saying. As far as C is concerned.
> 
> Was it not clear to you that he was referring to the definition
> of a complex conjugate, in the mathematical sense?
> 
> The conjugate of a complex number is also a complex number, and
> it is common in elementary mathematics to regard such numbers as
> a vector (specifically a pair) consisting of a real component,
> and an imaginary component.  Some other fields think of complex
> numbers as scalars, but I would expect the person you replied to
> to think of a complex number z=a+bi as an ordered pair, <a,b>,
> where a,b are real numbers and where "a" is the value of the
> real component, and "b" is the (real) factor of the imaginary
> component.  The complex conjugate of z is then z*=a-bi=<a,-b>,
> is also a vector.

simply negate the imaginary part for the conjugate.


> 
> This is totally independent of how C defines things; because C
> defines its complex type as a "scalar type" does not mean that
> in the mathematical sense, complex numbers cannot be thought of
> as vectors.  Besides, math was here first.
> 
>> complex types
>> are floating types (6.2.5p15), and therefore arithmetic types
>> (6.2.5p23), and therefore scalar types (6.2.5p26) Therefore, a function
>> that returns the conjugate of its argument would return a scalar type.
> 
> This is exactly the danger of an overly pedantic reading: it
> leads to attempts to apply one's knowledge of some domain
> (such as C) to things outside that domain (such as mathematics).
> Being overly rigid in one's thinking and interpretations is not
> a sign of expertise, but rather, of the inability to abstract
> appropriately.
> 
> 	- Dan C.
> 

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

#400965

On 11/08/2026 00:31, BGB wrote:
> On 8/10/2026 5:19 PM, Keith Thompson wrote:
>> BGB <cr88192@gmail.com> writes:

>> C++ complex numbers are implemented as a library class with
>> overloaded operators.
>>
> 
> Though the drawback here is that then it leaves more heavy lifting for 
> the compiler if you want them to also be fast(ish).
> 

The compiler has to do the job of generating the code no matter what.  A 
library class in C++ for complex numbers is not going to be 
significantly more demanding for the compiler than a struct of two 
doubles in C.

Standard C++ libraries can also use compiler-specific features or 
builtins.  While you can write your own C++ complex class based around a 
struct of two doubles, a C++ library targeting a specific compiler could 
happily just be a wrapper of a "_Complex double" if the compiler 
supported it as an extension.  So a well-written C++ standard library 
complex type can be just as efficient as having the feature part of the 
language, while also being able to work even if the compiler does not 
have such extensions.

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

#400969

On 8/11/2026 1:58 AM, David Brown wrote:
> On 11/08/2026 00:31, BGB wrote:
>> On 8/10/2026 5:19 PM, Keith Thompson wrote:
>>> BGB <cr88192@gmail.com> writes:
> 
>>> C++ complex numbers are implemented as a library class with
>>> overloaded operators.
>>>
>>
>> Though the drawback here is that then it leaves more heavy lifting for 
>> the compiler if you want them to also be fast(ish).
>>
> 
> The compiler has to do the job of generating the code no matter what.  A 
> library class in C++ for complex numbers is not going to be 
> significantly more demanding for the compiler than a struct of two 
> doubles in C.
> 

A struct with two doubles is also a problem...

Ideally, you want it as a built-in type, this way the compiler can have 
special logic paths for it; and to create a good place to plug in the 
SIMD instructions and SIMD related register allocation handling and similar.

Can't really easily do this with structs and functions as this would 
also require a significant amount of heavy-lifting on the compiler's part.

Similar reasons to why one generally needs to use things like SIMD types 
or SIMD intrinsics to really get a strong benefit from SIMD instructions 
(well, and then the hassle of all this stuff being poorly standardized; 
depending mostly on the combination of compiler and platform).


Like, auto-vectorization exists, and often sorta works, but the 
situation is often far from ideal.


> Standard C++ libraries can also use compiler-specific features or 
> builtins.  While you can write your own C++ complex class based around a 
> struct of two doubles, a C++ library targeting a specific compiler could 
> happily just be a wrapper of a "_Complex double" if the compiler 
> supported it as an extension.  So a well-written C++ standard library 
> complex type can be just as efficient as having the feature part of the 
> language, while also being able to work even if the compiler does not 
> have such extensions.
> 

Hmm...
   struct dcomplex {
     __mm128 v;
   };
   dcomplex operator+(dcomplex a, dcomplex b)
   {
     dcomplex c;
     c.v=_mm_add_pd(a.v, b.v);
     return c;
   }
   ...
Then hope the compiler doesn't add too much overhead from all this.


In my compiler, I went a little higher level:
   "_Complex float" "_Complex double"  //native 2-element SIMD types;
   __vec2f, __vec3f, __vec4f
   __vec2d, __vec3d, __vec4d
   __vec2h, __vec3h, __vec4h,  __vec2sf, __vec3sf, __vec4sf
   __quath/__quatsf, __quatf, __quatd

No built-in matrix types or similar at present though (unlike GLSL).


All of these exist as built-in native types.
Note that it is possible to pull elements out of them, or sub-vectors, 
etc. But, it is not possible to assign elements.

   f=v.x;  //yep, fine
   v1=v0.xy; //also fine

   v.x=f;  //illegal


Does mean there are a fair number of built-in types though.
   Much of the type-handling in BGBCC is via predicates.

So:
TypeCategoryP(type)
//does type belong in a given category

TypeSmallSometypeP(type)
//is type along a path that promotes to Sometype

...

There are a few paths that can turn into a big N*M mess though, like the 
CONV handling in the backend. This needs to deal with every possible 
type that may be cast into whatever other type for which is is possible 
to cast them.

Well, and a subset of types that are "compatible" as-in, type conversion 
doesn't require any actual conversion and it if viable mostly to simply 
re-label the value from one type to the other. This would be types that 
are semantically unique but have the same in-register format.


The later is partly how a lot of the __m64 and __m128 casting works, as 
these types are "compatible" with a lot of types that wouldn't otherwise 
be compatible, so they can allow a multi-step cast to effectively 
relabel a working variable reference from one type to another (and thus 
essentially perform a raw bit copy when the value is used).

Though, this can create a headache on an ISA like RV64G:
   double f;
   int e;
   e=(((long long)((__m64)f))>>52)&2047;
While it looks innocent enough, can result in an awkward situation where 
an F register shows up as an input to an integer instruction (X 
registers only on RV64G), where the ISA has separate X and F registers. 
This sort of situation ended up needing to be awkwardly hacked around 
for RV64G.

This could be dealt with by making __m64 and similar less universally 
compatible of RV64G, but this would also result in an increase of no-op 
register moves (and diminish the relative benefit of __m64).


Can note that a lot of compilers seem to have a smaller number of 
built-in types though...

As is, I am sitting at around 100 built-in types.

A lot are due to combinations of features:
   Various type sizes;
   Combination of vector lengths and base types;
   ...

...

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

#400958

BGB <cr88192@gmail.com> writes:


[...]
 
> Generally agree...
>
> Usual reason to add features to the language proper is when they are either:
> Highly used, so it is about programmer convenience;
> Can be made a lot more computationally efficient by having them in-language
> rather than as a library feature (most SIMD/vector stuff fits here).


I am an goofy wanna be economist...

The reason to add "new features" is for marketing.

The purpose of standardization is to diversify the market.

It is like a light bulb. If the new LEDs did not fit into the "standard"
light socket you may need to rebuild your house for better lighting.
This will surely not succeed in the market place.

How do I know LEDs are better than the tungsten? It is because people
like them better. Think about those T4 lamps - not seeing them around so
much anymore.

I am sorry to you C people; if C was a failure would they have created
C++ ? No! People like C, they know C; c++ just allows programmers to
write their software in a more marketable way (this is not an offensive statement).

I do not mean any offense to C programmers. I love the language; if C
did not work why are people not using D?

Have fun

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

#400960 — Re: Vectors! Quaternions! (was Re: Default signedness of 'plain' char.)

On Mon, 10 Aug 2026 15:17:45 -0500, BGB wrote:

> Also interesting in a way that other people think quaternions can be
> useful, as (in general) they seem to be rather rarely used (and
> rarely known to most people).

Fun fact: quaternions came before vector algebra, and led to the
development of the latter. But not before a bunch of mathematicians
fought a rear-guard action to keep the “vector” and “scalar” parts of
a quaternion together, while the vector folks found that it made a lot
of things easier if you separated them.

If you’re interested, the “Kathy Loves Physics & History” channel
recounts the story at <https://www.youtube.com/watch?v=M12CJIuX8D4>.

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

#400966

On 10/08/2026 22:17, BGB wrote:
> 
> 
> Also interesting in a way that other people think quaternions can be 
> useful, as (in general) they seem to be rather rarely used (and rarely 
> known to most people).
> 
The major use of quaternions is for 3-D graphics, and 3-D navigation 
(whether it is real navigation, control of robot arms, or something like 
a computer game).  Angles and rotations can often be easier to handle 
using quaternions than Euler angles as they can keep equations neater, 
make frame changes simpler, and avoid issues of poor resolution (or 
gimble lock) at certain angles.

They are also popular with people doing relativity calculations, quantum 
mechanics, and other physics work.

But you are of course correct that they are not as well-known as complex 
numbers.

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

#400962

On 08/09/2026 01:19 PM, BGB wrote:
> On 8/6/2026 3:34 AM, David Brown wrote:
>> On 05/08/2026 23:50, Lawrence D’Oliveiro wrote:
>>> On Wed, 5 Aug 2026 13:33:44 -0400, James Kuyper wrote:
>>>
>>>> On 2026-08-05 03:22, Lawrence D’Oliveiro wrote:
>>>>>
>>>>> On Mon, 3 Aug 2026 18:38:03 -0500, BGB wrote:
>>>>>
>>>>>> ... (though last I checked, MSVC still doesn't fully support C99;
>>>>>> eg, still no VLAs or _Complex).
>>>>>
>>>>> If a language implementation still doesn’t fully cope with a
>>>>> version of the language spec that is from over a quarter century
>>>>> ago and about two subsequent revisions out of date, I would say
>>>>> that describes a product that is on “life support” ...
>>>>
>>>> "cope" is fairly vague. VLAs and complex math are both optional in
>>>> the current version of C, so lack of support for those features is
>>>> no barrier to being a fully conforming implementation.
>>>
>>> Technically, you might be correct.
>>>
>>> But when your competition is GCC, then letting yourself look bad means
>>> you’re not even trying any more.
>>
>> I don't think MS sees gcc as a competitor in this sense.  I suspect
>> that there are few programmers who want to use MSVC for C programming
>> but choose gcc on Windows because of its support for _Complex or VLAs.
>>
>> I also think there are not many C programmers who use _Complex types -
>> they are simply not useful in most coding.  And programmers who do
>> need complex numbers may well be choosing other languages anyway.  (Of
>> course "not many C programmers" does not mean /no/ C programmers,)
>>
>
> Yeah, complex is rarely all that useful.
>
>
> If I were to rank these sorts of edge-case features from most to least
> from useful based on personal use (in BGBCC's dialect):
>    __int128       //actually pretty useful sometimes
>    SIMD vectors;  //useful, but horribly non-standardized
>    "short float"  //Binary16
>    "long double"  //Binary128
>    quaternions    //Typically 4x Binary32 (*1)
>    lambdas
>    VLAs
>    _Complex
>    __variant      //dynamic types
>
>
> *1: Though for storage savings, 4x Binary16 or 4x FP8(A) can make sense.
>    In the most common use-case, rotations, Binary16 is sufficient.
>    FP8A (modified A-Law) is a good storage option.
>      While, strictly speaking, less accurate than 4 linear bytes;
>      They become more accurate than bytes following renormalization (*2).
>
> *2: As any one component becomes larger, the other components become
> smaller, and the inaccuracy from the larger component(s) is compensated
> for by the smaller components, resulting in a higher average accuracy.
> While bytes (mapped from -1.0 to +1.0) are initially more accurate,
> their accuracy does not benefit from normalization, so using bytes
> effectively causes a more significant jitter of the position on the 4D
> unit sphere.
>
> Where, normalization here is defined as, say:
>    q1 = q / sqrt(q.x*q.x + q.y*q.y + q.z*q.z + q.w*q.w);
> Because apparently some people define it differently.
>
>
> In contrast, Complex is relatively little used in my use-cases.
> Most signal processing tasks I do are real-valued;
> Not really doing anything like Mandelbrot fractals or working with
> Riemann surfaces or similar;
> Nor doing any quantum mechanics calculations or similar;
> ...
>
>
> At which point, practical use-cases for plain Complex kinda fall off.
>
> Even if, yes, a quaternion is more complex than a normal complex, but
> they have a "killer app" of sorts in that they are useful for storing
> the rotations of things.
>
> Nevermind the that effectively every possible 3D rotation is effectively
> represented twice and you need to rotation 720 degrees to get back to
> the original orientation. Sometimes this does result in weird quirks
> that need to be accounted for when interpolating rotations (such as
> detecting when points are near opposite sides of the unit sphere and
> then mirroring them to be closer together).
>
> Well, decided to leave out a big detour about rotations in free-space
> and "intermediate axis theorem" and similar. Not really relevant here.
> But, yeah, they still end up as one of the better options despite the
> 720 degree quirk.
>
>
> Does either really need a C type?
> It is convenient, but debatable.
>
>
> Both would still be lower on the list than other 2 and 4 element vector
> types (and having a nice way to deal with rotations also only makes
> sense if one has a nice way to represent the thing being rotated).
>
> Though, could in theory store all the spatial coordinates in quaternions
> as well, but this goes against convention.
>
> Like, say, to rotate a 3D vector one could be like:
>    point2 = (rot * point1) / rot;
>
> Where note that P*Q is not necessarily equal to Q*P, and both
> multiplying and dividing by a rotation need not result in identity
> (well, except with 1+0i+0j+0k or similar...).
>
>
> For normal 3D vectors, A*B is defined as a per-element multiply, but
> this is not true of quaternions.
>
> Well, or people can find other uses by them, and they also contain
> complex numbers as a subset, ...
>
> ...
>
>
> Lambdas:
>    Uses a C++ style syntax:
>      [capture] (args)->type { body }
>    Representation:
>      Function pointer of the corresponding type signature;
>      Typically points to RWX memory;
>      Has different rules based on capture type.
>        [&] ...  //implicit by-reference, local lifetime only
>        [=] ...  //implicit by-value, unbounded lifetime
>        []  ...  //no capture, unbounded lifetime
>      Can also list captures individually if desired.
>
> Rarely used...
>    Note that non-careful use of [=] lambdas can result in a memory leak;
>    [&] lambdas don't leak as they are auto-destroyed;
>    [] lambdas don't leak, as nothing is created to be leaked.
>
> Can note that (from a compiler POV) lambdas are a pain to deal with, as
> the compiler effectively needs to fold them into their own function
> bodies with an implicit context structure for the captures.
>
> This context structure is usually preceded with a stub:
> Loads itself into a register;
> Branches to the actual lambda function's entry point.
>
> Typically needs special RWX memory, which is not used for general heap
> or stack memory as it provides a safety risk (RWX memory for heap or
> stack leaves an attack surface for shell-code injection).
>
>
>> VLAs are also not very common in C programming, and what is found is
>> often arrays that are technically VLAs, but in practice are sizes that
>> are known at compile time - the size is given by a variable (that is,
>> or could be, declared "const") that is fixed.  In C++, such "const"
>> variables can be used as the size of an array - these are normal
>> arrays in C++, but technically VLAs in C.  MSVC users can get that by
>> compiling their C code as C++, which is something I have seen MSVC
>> users do without realising it.
>>
>> It would be best, of course, if MS simply added these C99 features to
>> their C compiler.  I do not think it is beyond their technical
>> abilities or that it would be a huge effort.  (It doesn't need to be
>> particularly efficient.)
>>
>
> The main argument against the traditional notion of VLAs is that it
> implies variable-sized stack-frames, but there are other options:
>    Offer a small brk-like or hunk-like mechanism;
>      If space remains, and the alloc is under the size limit, use this;
>    Fall back heap allocations with an implicit chain-freeing mechanism.
>
> So, say, for the brk-like mechanism:
>    A modest, likely fixed-size region exists per-thread;
>    Keep track of its position when used in a frame;
>    Returning from a frame will restore its prior position;
>    Enforces a size limit for allocs.
>      Point is mostly to make small VLAs fast;
>      Defeated if it all gets used up by a big VLA.
>
> For the heap-based mechanism:
>    Keep a linked list of allocs;
>    Existing a frame also frees any allocs in this list;
>    Implicitly can also cover automatic objects and lambdas.
>
> In this strategy, each stack frame can remain fixed size.
>
>
>> Making VLAs and _Complex optional in C11 was, I think, a mistake.  It
>> is fair enough to make /new/ features optional in a new standard - and
>> then perhaps make them required features in later standards if they
>> are popular enough.  I don't know if MS was instrumental in changing
>> VLAs and _Complex to optional features in C11, but it certainly gives
>> that impression.
>>
>
> I think they were in this case.
> Or, at least, MS's refusal to implement them probably didn't exactly
> help matters...
>
> IMO, unlike VLAs, there is no particularly strong technical reason for
> not implementing _Complex though (they don't really require any
> infrastructure that the compiler wouldn't have likely already needed for
> other reasons).
>
> ...
>
>

Thanks for writing.

The "matroids" are a sort of higher-order matrix, and have some
geometric character, then "generalized matrix products" and the
corresponding "generalized matrix inverses", as well don't simply
fit in the usual account of square or rectangular matrices and
the like, while yet that products of tuple and scalars and vectors
sort of make them.

A new term I hadn't heard before a few weeks ago was "mechanical
sympathy", the idea of designing algorithm that it reflects the
model of computation and operation, then there's an idea of
alike what's "mathematical sympathy", about what objects have
what forms that mathematics reduces them. Here there's been
being considered the "Stall-less/Branch-less/Call-less" approaches,
or branch-less I suppose it's usually called, not that branches
per se are bad yet that mis-predicted or un-predictable branches
or bad, and most all interesting algorithms have un-predictable
branches.

Then about the mention of SIMD, here the idea is that at least
with regards to various vector extensions on the processor,
they can be considered as 128-bit vectors, 16-deep, about
designing the algorithm in these blocks, then for example
that SSE 4.2 has one block, Arm NEON has two blocks,
AVX2 has two blocks, AVX512 has eight blocks, SVE has more
blocks, in terms of a limited common subset of algorithms
that work on the layout in terms of arithmetic & logic & comparison
that when implemented in terms of these blocks within basically
the virtually-addressed register file of banks of blocks,
is about a programming model for SIMD that makes for byte-wise
operations about serial algorithms, then also besides for
usual sorts of flow-machines that make systolic Stall-less,
Branch-less, Call-less code that doesn't stall or evict or
exit the pipeline, in uniform sizes and with uniform operations
across all usual modern commodity instruction sets.
Surfacing that to the higher-level language then though
is contrived, yet, it's just the block as a value type
and then a limited common subset of operations on them,
then as with regards to being agnostic endianness and so on.

This posts is prompted from reading about "Default signedness
of 'plain' char", which is signed, though there are compiler
options either way, and that usually the first thing in
dealing with "unsigned char" is to get something equivalent
to "uint8_t", that I was tapping at some Unicode code and
those are unsigned for arithmetic yet the SIMD CMP or compare
instructions only work on signed bytes across the vector,
with regards to adding 0x80 to translate the unsigned to
signed so the relation and equivalence relation about
l.t. and g.t. hold when the unit only does signed comparisons,
and without needing to unpack the vector, courtesy 2's complement.


About variants and so on or union types, and various accounts
for example of just boxing those in structs for example to
make them 512-bits like cache-lines or 16-bytes like 128-bit
vector words, or for example 4096 bytes a usual page size,
or about the 8192 bytes and jumbo packets, it seems to be
making for "types" and storage-class and so on, and the
conventions of values, which most people avoid with pointers.


The variable-length array is a bit contrived, it's either on
the stack or on the heap or in the image, it's in static
initialization and seems to reflect the "happy or fatal"
sort of outlook, or for "carp, croak, and die", vis-a-vis,
"silent exit" with regards to signals and so on and other
things I don't much think about yet are sensible for processes
if not so much libraries.


So, "matroids" and "generalized matrix products" and
"generalized matrix inverse" are their own kinds of
things, while of course floating-point arithmetic
is what it is.

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

#400963

On Mon, 10 Aug 2026 21:15:40 -0700, Ross Finlayson wrote:

> The "matroids" are a sort of higher-order matrix, and have some
> geometric character, then "generalized matrix products" and the
> corresponding "generalized matrix inverses", as well don't simply
> fit in the usual account of square or rectangular matrices and the
> like, while yet that products of tuple and scalars and vectors sort
> of make them.

Tensors?

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

#400979

On 08/10/2026 09:52 PM, Lawrence D’Oliveiro wrote:
> On Mon, 10 Aug 2026 21:15:40 -0700, Ross Finlayson wrote:
>
>> The "matroids" are a sort of higher-order matrix, and have some
>> geometric character, then "generalized matrix products" and the
>> corresponding "generalized matrix inverses", as well don't simply
>> fit in the usual account of square or rectangular matrices and the
>> like, while yet that products of tuple and scalars and vectors sort
>> of make them.
>
> Tensors?
>

The "tensors is as tensors does", about tensorial products and
that the point of tensors is that they mean tensorial products,
usually in a setting of vectorial products, it's a bit different
than "it is what it is", the interleaved "logical" and "physical"
layers, and "it is what it does", the logical layer or abstraction,
then that tensors has that engineers have tensors which are often
framed as systems of linear invariants, and physicists have tensors
which are often framed as systems of linear invariants, then that
vector spaces are often usual to everyone, yet some people just call
their systems of "vectors" their "tensors", that matroids and tensors
are alike in that sense, yet that matroids have a sort of "universal
matroid" or "uniform matroid", while tensors are often described as
systems and conventions abotu vector or linear invariants, when though
that's as they fulfill "what it does", maintaining systemic invariants,
that for example the linear has partials or the non-linear and the
vectorial has, for example, "gimbal lock", or singularities, which is an
example of something that the quaternion avoids, then that
"tensors" are usually described as both the system and the elements,
ignoring the difference, to keep things tight the tensors.

So, "tensor" used in the field like "we have a tensor machine"
usually enough is gussied-up "we have a system of linear invariants
according to a vector model", since "tensor" is a bit wider itself.

It is what it does, ....

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

#401028

On 8/11/2026 6:45 AM, Ross Finlayson wrote:
[...]
> So, "tensor" used in the field like "we have a tensor machine"
> usually enough is gussied-up "we have a system of linear invariants
> according to a vector model", since "tensor" is a bit wider itself.
> 
> It is what it does, ....

I tend to like n-ary vectors in an n-ary vector field. Fwiw, here is an 
example animation I made, along with the MIDI music:

https://youtu.be/HwIkk9zENcg

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

#400868

On 8/5/2026 12:22 AM, Lawrence D’Oliveiro wrote:
> On Mon, 3 Aug 2026 18:38:03 -0500, BGB wrote:
> 
>> ... (though last I checked, MSVC still doesn't fully support C99;
>> eg, still no VLAs or _Complex).
> 
> If a language implementation still doesn’t fully cope with a version
> of the language spec that is from over a quarter century ago and about
> two subsequent revisions out of date, I would say that describes a
> product that is on “life support” ...

MSVC is pretty good with modern C++. MSVC 6 had pretty damn good support 
for C, but teribble support for C++, iirc they licensed the dinkumware 
crap stl and shit like that. However, it seems they push C++ now and 
treat C as as a second class citizen, so to speak. Not sure if they 
support membars and atomics in C yet. I only use it for C++ nowdays.

Iirc, a compiler that tried to adopt C11 is Pelles. Even then I found 
some issues. Fwiw, when you get some free time, read all of:

https://forum.pellesc.de/index.php?topic=7167.msg27217#msg27217

https://forum.pellesc.de/index.php?topic=7311.msg27764#msg27764

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

#400847

On Mon, 3 Aug 2026 13:20:07 -0700, Chris M. Thomasson wrote:

> fwiw, I personally prefer unsigned char for all of my raw buffers
> and such, but that's just me.

On the original PDP-11 (where the bulk of early Unix and C development
happened), the “move byte from memory to register” instruction would
sign-extend the byte into the 16-bit register.

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

#400882

On 8/2/2026 9:17 AM, Kenny McCormack wrote:
> First off, I know the "standards" answer is "Either is correct; you have no
> right to complain about anything", but I am not interested in the
> "standards" answer.  If this is all you can do, then just click Next and go
> on.
> 
> I'm interested in the "why" of why implementations might prefer one or the
> other.
> 
> Consider:
> 
> /* macro 'U' must be defined on the cmd line */
> #include <stdio.h>
> 
> int main(void)
> {
>      U char c = 255;
> 
>      printf("Result of 'c > 0': %d\n",c > 0);
> }
> 
> And the following command lines:
> 
> $ tcc -DU= -run CheckSignedChar.c
> $ tcc -DU=signed -run CheckSignedChar.c
> $ tcc -DU=unsigned -run CheckSignedChar.c
> 
> On 32 bit RpiOS, the default is unsigned, but on x64 Ubuntu, the default is
> signed.  I'm interested in what sorts of factors drive the decision-making.
> 
> Note, BTW, that I first noticed this in a project using gcc, but it is
> easier to test using tcc, as above.
> 
> Also, total aside, I'm surprised that one needs to do -DU= instead of just
> -DU.  I thought -DU would define it as an empty string, but that generates
> a compile error.  You need -DU=.  Why?

So, you have to check every compiler and every compiler version to see 
what the signedness of char is.  That is not good in these days of UTF-8.

Lynn

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

#400883

Lynn McGuire <lynnmcguire5@gmail.com> writes:
[...]
> So, you have to check every compiler and every compiler version to see
> what the signedness of char is.  That is not good in these days of
> UTF-8.

Not really.  You can usually write code that doesn't care whether
plain char is signed or unsigned.  And if it matters, you can check
whether CHAR_MIN==0.

This evolved from systems like the PDP-11 where character values
ranged from 0 to 127, so the signedness of plain char didn't
matter much.

It's annoying that, in many implementations, UTF-8 strings can
contain elements with negative values (negative character values
rarely make sense), but in practice it doesn't cause many problems.

IMHO it would be cleaner to require plain char to be unsigned,
but I don't see that happening.

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

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

#400885

On 06/08/2026 00:41, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
> [...]
>> So, you have to check every compiler and every compiler version to see
>> what the signedness of char is.  That is not good in these days of
>> UTF-8.
> 
> Not really.  You can usually write code that doesn't care whether
> plain char is signed or unsigned.  And if it matters, you can check
> whether CHAR_MIN==0.

It causes a problem here when char is signed:

   int counts[256];

   void scanstr(char* s) {
       while (*s) ++counts[*s++];
   }

   int main(void) {
       scanstr("abcdef €");
   }

Changing the type to 'unsigned char*', or uint_8, would result in warnings.

> IMHO it would be cleaner to require plain char to be unsigned,
> but I don't see that happening.

Some existing programs will make assumptions about it.

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

#400886

bart <bc@freeuk.com> writes:
> On 06/08/2026 00:41, Keith Thompson wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> [...]
>>> So, you have to check every compiler and every compiler version to see
>>> what the signedness of char is.  That is not good in these days of
>>> UTF-8.
>>
>> Not really.  You can usually write code that doesn't care whether
>> plain char is signed or unsigned.  And if it matters, you can check
>> whether CHAR_MIN==0.
>
> It causes a problem here when char is signed:
>
>   int counts[256];
>
>   void scanstr(char* s) {
>       while (*s) ++counts[*s++];
>   }
>
>   int main(void) {
>       scanstr("abcdef €");
>   }
>
> Changing the type to 'unsigned char*', or uint_8, would result in warnings.

Yes, I did say "usually".

Rather than changing the type, I'd cast the value of *s++ to
unsigned char.  (I'd also use UCHAR_MAX+1 rather than 256, more
for clarity than for portability.)

(Ideally, you could also use u8"abcdef €" rather than "abcdef €",
but strangely enough the type of u8"..." string literals changed
between C17 and C23.  UTF-8 string literals were introduced in C99.
From C99 to C17, the array elements have type char.  In C23, they
have type char8_t, which is the same as unsigned char; char8_t
didn't exist in C17 and earlier.)

>> IMHO it would be cleaner to require plain char to be unsigned,
>> but I don't see that happening.
>
> Some existing programs will make assumptions about it.

Which is why I don't see it happening.  There's too much existing code
that makes the non-portable assumption that plain char is signed.

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

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

#400902

In article <1150k8j$3ebfi$1@dont-email.me>, bart  <bc@freeuk.com> wrote:
>On 06/08/2026 00:41, Keith Thompson wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> [...]
>>> So, you have to check every compiler and every compiler version to see
>>> what the signedness of char is.  That is not good in these days of
>>> UTF-8.
>> 
>> Not really.  You can usually write code that doesn't care whether
>> plain char is signed or unsigned.  And if it matters, you can check
>> whether CHAR_MIN==0.
>
>It causes a problem here when char is signed:
>
>   int counts[256];
>
>   void scanstr(char* s) {
>       while (*s) ++counts[*s++];
>   }
>
>   int main(void) {
>       scanstr("abcdef €");
>   }
>
>Changing the type to 'unsigned char*', or uint_8, would result in warnings.

Cast the value when using as the index:

	while (*s) ++counts[(unsignd char)*s++];

Note that this is already required for the `is*` functions
defined in `ctype.h` (except, IIRC, `isascii`).

>> IMHO it would be cleaner to require plain char to be unsigned,
>> but I don't see that happening.
>
>Some existing programs will make assumptions about it.

*Many.

	- Dan C.

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

#400908

cross@spitfire.i.gajendra.net (Dan Cross) writes:
[...]
> Cast the value when using as the index:
>
> 	while (*s) ++counts[(unsignd char)*s++];
>
> Note that this is already required for the `is*` functions
> defined in `ctype.h` (except, IIRC, `isascii`).

isascii() is not defined by ISO C, or even by POSIX.  isblank() is
another common extension.  For implementations that support them,
I don't think they're handled differently from the other is*()
functions.  Most implementations handle values from SCHAR_MIN to
UCHAR_MAX without error, but the behavior is undefined for any
value other than EOF outside the range 0..UCHAR_MAX.

[...]

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

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

#400912

In article <1153hcv$ba35$1@kst.eternal-september.org>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>[...]
>> Cast the value when using as the index:
>>
>> 	while (*s) ++counts[(unsignd char)*s++];
>>
>> Note that this is already required for the `is*` functions
>> defined in `ctype.h` (except, IIRC, `isascii`).
>
>isascii() is not defined by ISO C, or even by POSIX.

Ah, right you are.  `isascii` was marked obsolescent in POSIX
Issue 7 (2018) and removed in Issue 8 (2024); it never made it
into standardized C, and was dropped during the initial work
leading up to ANSI C (the C89 rationale discusses it), though it
remains broadly implemented, presumably for compatibility with
older code.

>isblank() is
>another common extension.  For implementations that support them,
>I don't think they're handled differently from the other is*()
>functions.  Most implementations handle values from SCHAR_MIN to
>UCHAR_MAX without error, but the behavior is undefined for any
>value other than EOF outside the range 0..UCHAR_MAX.

Before removal from POSIX, `isascii` was specified as defined
for all integer values.
https://pubs.opengroup.org/onlinepubs/9699919799/functions/isascii.html

I imagine that `isblank` would be implemented similarly to the
others, however.

	- Dan C.

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

#400918

cross@spitfire.i.gajendra.net (Dan Cross) writes:
> In article <1153hcv$ba35$1@kst.eternal-september.org>,
> Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>>cross@spitfire.i.gajendra.net (Dan Cross) writes:
>>[...]
>>> Cast the value when using as the index:
>>>
>>> 	while (*s) ++counts[(unsignd char)*s++];
>>>
>>> Note that this is already required for the `is*` functions
>>> defined in `ctype.h` (except, IIRC, `isascii`).
>>
>>isascii() is not defined by ISO C, or even by POSIX.
>
> Ah, right you are.  `isascii` was marked obsolescent in POSIX
> Issue 7 (2018) and removed in Issue 8 (2024); it never made it
> into standardized C, and was dropped during the initial work
> leading up to ANSI C (the C89 rationale discusses it), though it
> remains broadly implemented, presumably for compatibility with
> older code.
>
>>isblank() is
>>another common extension.  For implementations that support them,
>>I don't think they're handled differently from the other is*()
>>functions.  Most implementations handle values from SCHAR_MIN to
>>UCHAR_MAX without error, but the behavior is undefined for any
>>value other than EOF outside the range 0..UCHAR_MAX.
>
> Before removal from POSIX, `isascii` was specified as defined
> for all integer values.
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/isascii.html
>
> I imagine that `isblank` would be implemented similarly to the
> others, however.

Interesting.  The 2018 POSIX specification says that "The isascii()
function is defined on all integer values.", but for isblank() and
isdigit() it says "The c argument is an int, the value of which the
application shall ensure is a character representable as an unsigned
char or equal to the value of the macro EOF. If the argument has any
other value, the behavior is undefined.".  (I presume the same applies
to the other ISO-C-defined functions, but I haven't checked them all.)

isascii() is (was?) a special case, probably because it's easier to
implement without using a lookup table.  In glibc:

#define __isascii(c)    (((c) & ~0x7f) == 0)

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

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

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7  Next page →

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

csiph-web