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

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

Default signedness of 'plain' char.

Started bygazelle@shell.xmission.com (Kenny McCormack)
First post2026-08-02 14:17 +0000
Last post2026-08-06 15:33 -0700
Articles 20 on this page of 133 — 18 participants

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 1 of 7  [1] 2 3 4 5 6 7  Next page →

#400708 — Default signedness of 'plain' char.

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2026-08-02 14:17 +0000
SubjectDefault signedness of 'plain' char.
Message-ID<114nji9$li5u$1@news.xmission.com>
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?

-- 
Treating the stock market indexes as general measures of the well-being of a
society is like treating your blood pressure as an indicator of health.  The
higher, the better, right?  In fact, a high stock market is good for the investor
class, but it means the rest of us are getting screwed better than ever.

[toc] | [next] | [standalone]

#400712

FromJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date2026-08-03 02:45 +0800
Message-ID<PeMbS.103022$aXr.22087@fx18.ams4>
In reply to#400708
On 02/08/2026 10:17 PM, 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.

I believe some of it is to do with compatibility.  The previous
compiler, acc defined it signed, so when the next compiler on the same
system, bcc, comes along they do it that way, even though bcc has been
unsigned on the original system it was developed on.

And why did acc define it signed in the first place?  Maybe the CPU only
had signed bytes, or they were faster than unsigned?  I wouldn't know as
this is a made up example.

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

Yes, I had that problem before.  Seems the tradition is to treat -Dfoo
as

#define foo 1

rather than just

#define foo

so you need the added = to make it empty.  It would be much better if
this was taught in elementary C courses.  But as it turns out, compiler
arcana isn't taught much at all.

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

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

#400730

Fromgazelle@shell.xmission.com (Kenny McCormack)
Date2026-08-03 01:47 +0000
Message-ID<114orut$nmkv$1@news.xmission.com>
In reply to#400712
In article <PeMbS.103022$aXr.22087@fx18.ams4>,
Johann 'Myrkraverk' Oskarsson  <johann@myrkraverk.invalid> wrote:
...
>And why did acc define it signed in the first place?  Maybe the CPU only
>had signed bytes, or they were faster than unsigned?  I wouldn't know as
>this is a made up example.

Thank you for your response.   I hope to see more responses on this thread.

But, just out of curiosity, why do you way that "this is a made up example" ?
To what are you referring and why do you think it was "made up" ?

-- 
A pervert, a racist, and a con man walk into a bar...

Bartender says, "What will you have, Donald!"

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

#400749

FromJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date2026-08-03 23:14 +0800
Message-ID<Of2cS.34633$ZjVb.9403@fx12.ams4>
In reply to#400730
On 03/08/2026 9:47 AM, Kenny McCormack wrote:
> In article <PeMbS.103022$aXr.22087@fx18.ams4>,
> Johann 'Myrkraverk' Oskarsson  <johann@myrkraverk.invalid> wrote:
> ...
>> And why did acc define it signed in the first place?  Maybe the CPU only
>> had signed bytes, or they were faster than unsigned?  I wouldn't know as
>> this is a made up example.
> 
> Thank you for your response.   I hope to see more responses on this thread.
> 
> But, just out of curiosity, why do you way that "this is a made up example" ?
> To what are you referring and why do you think it was "made up" ?
> 

Because I did not bother to dig up my RISC OS computer, and see what
that C compiler did about the signedness of chars.

It's a high chance that GCC, when ported to ARM for the first time,
was compatible with whatever C compiler the original /Acorn/ team
used, or made.

I believe I have a continuation of that C compiler on my RISC OS
machine.  So assuming it still works, I can boot it up, and check
what it does.

That said, I'm in no hurry, and I'm not sure it still works.  It's
a /Pinebook/ that boots into RISC OS 5.

Then, we should keep in mind that the /Acorn/ team was used to code
in assembly.  I believe most of RISC OS is coded in assembly, and
their original C compiler was -- and had to be -- compatible with
whatever /application binary interface/ they were used to in that
assembly code.

So, that's the reason I believe default ARM char is unsigned.  I'm
sure other regulars will be extremely happy to correct me, so let
them.  They enjoy that sport.

I'm also adding comp.sys.acorn.misc, so the regulars there have a
chance at correcting this historical tidbit.  We'll leave alt.folk-
lore.computers alone for now.

-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com

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

#400750

Frombart <bc@freeuk.com>
Date2026-08-03 17:04 +0100
Message-ID<114qe6e$1ebd0$1@dont-email.me>
In reply to#400749
On 03/08/2026 16:14, Johann 'Myrkraverk' Oskarsson wrote:
> On 03/08/2026 9:47 AM, Kenny McCormack wrote:
>> In article <PeMbS.103022$aXr.22087@fx18.ams4>,
>> Johann 'Myrkraverk' Oskarsson  <johann@myrkraverk.invalid> wrote:
>> ...
>>> And why did acc define it signed in the first place?  Maybe the CPU only
>>> had signed bytes, or they were faster than unsigned?  I wouldn't know as
>>> this is a made up example.
>>
>> Thank you for your response.   I hope to see more responses on this 
>> thread.
>>
>> But, just out of curiosity, why do you way that "this is a made up 
>> example" ?
>> To what are you referring and why do you think it was "made up" ?
>>
> 
> Because I did not bother to dig up my RISC OS computer, and see what
> that C compiler did about the signedness of chars.
> 
> It's a high chance that GCC, when ported to ARM for the first time,
> was compatible with whatever C compiler the original /Acorn/ team
> used, or made.

When I implemented C on Windows, I made 'char' unsigned (actually it was 
an alias for 'unsigned char'), as I thought a signed char was wrong.

However, I ran into problems with programs that assumed a signed char. 
So I made it an alias for 'signed char' instead.

Sometimes you just have to follow either the platform or existing 
practice, but it means crass choices like this persist.

A more interesting fact for me is that signed 'char' is incompatible 
with 'signed char', and unsigned 'char' is incompatible with 'unsigned 
char', which introduces problems of its own. (Eg. what type does 'puts' 
take if called via an FFI where the C 'char' type does not exist.)


> I believe I have a continuation of that C compiler on my RISC OS
> machine.  So assuming it still works, I can boot it up, and check
> what it does.
> 
> That said, I'm in no hurry, and I'm not sure it still works.  It's
> a /Pinebook/ that boots into RISC OS 5.

According to Godbolt, C for ARM64 uses an unsigned 'char'. I hope 
because they realised that a signed 'char' makes no sense by itself.

> So, that's the reason I believe default ARM char is unsigned.  I'm
> sure other regulars will be extremely happy to correct me, so let
> them.  They enjoy that sport.
> 
> I'm also adding comp.sys.acorn.misc,so the regulars there have a
> chance at correcting this historical tidbit.

Please don't; why are you so obsessed with cross-posting everything in 
half-a-dozen unrelated groups?

Why do you think they would be experts in the history of the C language 
or C compilers anyway? None of the threads there over the last two years 
give any evidence of that.

Also, just because some application, library, system or language happens 
to be implemented in language X, (or some computer that happens to run 
some programs written in X!) doesn't mean it it topical in a newsgroup 
devoted to that language.

Most newsgroups are pretty much dead anyway and are either wastelands or 
cesspits; I hope you're not trying to turn this into the latter.

If you want a more appreciative (and younger) audience, try Reddit.

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

#400753 — The Spanish Inquisition (was: Re: Default signedness of 'plain' char.)

FromJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date2026-08-04 00:23 +0800
SubjectThe Spanish Inquisition (was: Re: Default signedness of 'plain' char.)
Message-ID<Rf3cS.134519$9jNc.22182@fx16.ams4>
In reply to#400750
On 04/08/2026 12:04 AM, bart wrote:
> On 03/08/2026 16:14, Johann 'Myrkraverk' Oskarsson wrote:
>> On 03/08/2026 9:47 AM, Kenny McCormack wrote:
>>> In article <PeMbS.103022$aXr.22087@fx18.ams4>,
>>> Johann 'Myrkraverk' Oskarsson  <johann@myrkraverk.invalid> wrote:
>>> ...
>>>> And why did acc define it signed in the first place?  Maybe the CPU 
>>>> only
>>>> had signed bytes, or they were faster than unsigned?  I wouldn't 
>>>> know as
>>>> this is a made up example.
>>>
>>> Thank you for your response.   I hope to see more responses on this 
>>> thread.
>>>
>>> But, just out of curiosity, why do you way that "this is a made up 
>>> example" ?
>>> To what are you referring and why do you think it was "made up" ?
>>>
>>
>> Because I did not bother to dig up my RISC OS computer, and see what
>> that C compiler did about the signedness of chars.
>>
>> It's a high chance that GCC, when ported to ARM for the first time,
>> was compatible with whatever C compiler the original /Acorn/ team
>> used, or made.
> 
> When I implemented C on Windows, I made 'char' unsigned (actually it was 
> an alias for 'unsigned char'), as I thought a signed char was wrong.
> 
> However, I ran into problems with programs that assumed a signed char. 
> So I made it an alias for 'signed char' instead.
> 
> Sometimes you just have to follow either the platform or existing 
> practice, but it means crass choices like this persist.
> 
> A more interesting fact for me is that signed 'char' is incompatible 
> with 'signed char', and unsigned 'char' is incompatible with 'unsigned 
> char', which introduces problems of its own. (Eg. what type does 'puts' 
> take if called via an FFI where the C 'char' type does not exist.)
> 
> 
>> I believe I have a continuation of that C compiler on my RISC OS
>> machine.  So assuming it still works, I can boot it up, and check
>> what it does.
>>
>> That said, I'm in no hurry, and I'm not sure it still works.  It's
>> a /Pinebook/ that boots into RISC OS 5.
> 
> According to Godbolt, C for ARM64 uses an unsigned 'char'. I hope 
> because they realised that a signed 'char' makes no sense by itself.
> 
>> So, that's the reason I believe default ARM char is unsigned.  I'm
>> sure other regulars will be extremely happy to correct me, so let
>> them.  They enjoy that sport.
>>
>> I'm also adding comp.sys.acorn.misc,so the regulars there have a
>> chance at correcting this historical tidbit.
> 
> Please don't; why are you so obsessed with cross-posting everything in 
> half-a-dozen unrelated groups?
> 
> Why do you think they would be experts in the history of the C language 
> or C compilers anyway? None of the threads there over the last two years 
> give any evidence of that.

You really need to ask me that question, and remove the cross posting?
Why not ask them, like a regular human being?
> 
> Also, just because some application, library, system or language happens 
> to be implemented in language X, (or some computer that happens to run 
> some programs written in X!) doesn't mean it it topical in a newsgroup 
> devoted to that language.
> 
> Most newsgroups are pretty much dead anyway and are either wastelands or 
> cesspits; I hope you're not trying to turn this into the latter.
> 
> If you want a more appreciative (and younger) audience, try Reddit.
> 
> 

Dear bart, as you seem to be trying not to be an asshole, I'll deign to
reply and try not to be an asshole too.

I've been with the "younger" crowd, on Discord.  They're even more
problematic than comp.lang.c.  I escaped with the little hair I have
left, see picture on my BlueSky.

What you all fail no notice, is that you're all so covered with feces
and spread it around wherever you go, that you're the ones making this
last bastion of Usenet a cesspit.

Once you, Dan Cross, Keith Thompson, Scott Lurndal, and Lawrence
D'Oliveiro realize you're the ones causing the trouble, we may, just
may, have a decent conversation.

I do not conform to your "group think" about how C is supposed to work,
and that bothers all of you.  You may not realize it, and I'm stepping
into parapsychology here, but that's why you don't like me.  Once you're
willing to accept that people have different opinions, or should I say,
/belief/, about how a C compiler should behave, you'll realize you're
the ones pushing everyone else out of comp.lang.c.

Nobody likes a true believer who spreads his and her religioun all over
their social contacts.  Stop it, or face the consequences of the Spanish
Inquisition!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

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

#400754 — Re: The Spanish Inquisition

Frombart <bc@freeuk.com>
Date2026-08-03 18:03 +0100
SubjectRe: The Spanish Inquisition
Message-ID<114qhlm$1g9dt$1@dont-email.me>
In reply to#400753
On 03/08/2026 17:23, Johann 'Myrkraverk' Oskarsson wrote:
> On 04/08/2026 12:04 AM, bart wrote:

>> Why do you think they would be experts in the history of the C 
>> language or C compilers anyway? None of the threads there over the 
>> last two years give any evidence of that.
> 
> You really need to ask me that question, and remove the cross posting?
> Why not ask them, like a regular human being?

I'm asking you because you're the one constantly adding new groups. 
You've admitted you like doing it to annoy people.

So /you're/ being the asshole.



>> Also, just because some application, library, system or language 
>> happens to be implemented in language X, (or some computer that 
>> happens to run some programs written in X!) doesn't mean it it topical 
>> in a newsgroup devoted to that language.
>>
>> Most newsgroups are pretty much dead anyway and are either wastelands 
>> or cesspits; I hope you're not trying to turn this into the latter.
>>
>> If you want a more appreciative (and younger) audience, try Reddit.
>>
>>
> 
> Dear bart, as you seem to be trying not to be an asshole, I'll deign to
> reply and try not to be an asshole too.
> 
> I've been with the "younger" crowd, on Discord.  They're even more
> problematic than comp.lang.c.  I escaped with the little hair I have
> left, see picture on my BlueSky.
> 
> What you all fail no notice, is that you're all so covered with feces
> and spread it around wherever you go, that you're the ones making this
> last bastion of Usenet a cesspit.
> 
> Once you, Dan Cross, Keith Thompson, Scott Lurndal, and Lawrence
> D'Oliveiro realize you're the ones causing the trouble, we may, just
> may, have a decent conversation.

That's going to be unlikely with you, sorry.

(Also, /I'm/ the one who has long been considered the upstart here by 
asking too many questions and going against the grain.

However, I've usually respected topicality.)

> Nobody likes a true believer who spreads his and her religioun all over
> their social contacts.  Stop it, or face the consequences of the Spanish
> Inquisition!

So what religion are you spreading? Does it have anything to do with 
.... C? I don't mean you've used a program written in a language 
compiled with a program that might have been written in C.

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

#400755 — Re: The Spanish Inquisition

FromJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date2026-08-04 01:26 +0800
SubjectRe: The Spanish Inquisition
Message-ID<qb4cS.41495$yRb.11190@fx13.ams4>
In reply to#400754
On 04/08/2026 1:03 AM, bart wrote:
> On 03/08/2026 17:23, Johann 'Myrkraverk' Oskarsson wrote:
>> On 04/08/2026 12:04 AM, bart wrote:
> 
>>> Why do you think they would be experts in the history of the C 
>>> language or C compilers anyway? None of the threads there over the 
>>> last two years give any evidence of that.
>>
>> You really need to ask me that question, and remove the cross posting?
>> Why not ask them, like a regular human being?
> 
> I'm asking you because you're the one constantly adding new groups. 
> You've admitted you like doing it to annoy people.
> 
> So /you're/ being the asshole.
> 

Disrespect breeds disrespect.  That you fail to understand this tells
me you're a psychopath, or an LLM.

> 
> 
>>> Also, just because some application, library, system or language 
>>> happens to be implemented in language X, (or some computer that 
>>> happens to run some programs written in X!) doesn't mean it it 
>>> topical in a newsgroup devoted to that language.
>>>
>>> Most newsgroups are pretty much dead anyway and are either wastelands 
>>> or cesspits; I hope you're not trying to turn this into the latter.
>>>
>>> If you want a more appreciative (and younger) audience, try Reddit.
>>>
>>>
>>
>> Dear bart, as you seem to be trying not to be an asshole, I'll deign to
>> reply and try not to be an asshole too.
>>
>> I've been with the "younger" crowd, on Discord.  They're even more
>> problematic than comp.lang.c.  I escaped with the little hair I have
>> left, see picture on my BlueSky.
>>
>> What you all fail no notice, is that you're all so covered with feces
>> and spread it around wherever you go, that you're the ones making this
>> last bastion of Usenet a cesspit.
>>
>> Once you, Dan Cross, Keith Thompson, Scott Lurndal, and Lawrence
>> D'Oliveiro realize you're the ones causing the trouble, we may, just
>> may, have a decent conversation.
> 
> That's going to be unlikely with you, sorry.

Don't lie.  You're not sorry at all.  And also, since you failed to
notice it, all of you are behaving like psychopaths.  I don't respect
psychopaths.

> 
> (Also, /I'm/ the one who has long been considered the upstart here by 
> asking too many questions and going against the grain.
> 
> However, I've usually respected topicality.)

No, you don't.

> 
>> Nobody likes a true believer who spreads his and her religioun all over
>> their social contacts.  Stop it, or face the consequences of the Spanish
>> Inquisition!
> 
> So what religion are you spreading? Does it have anything to do 
> with .... C? I don't mean you've used a program written in a language 
> compiled with a program that might have been written in C.

I'm pointing out that you, the "regulars" in comp.lang.c are spreading
your religion.  That you fail no notice tells me that you don't consider
yourself a /believer/.  Hence, there's no point in talking to you.

Just talk to the hand.
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

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

#400815

FromTheo <theom+news@chiark.greenend.org.uk>
Date2026-08-04 13:13 +0100
Message-ID<ghc*yxhNA@news.chiark.greenend.org.uk>
In reply to#400749
In comp.sys.acorn.misc Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> wrote:
> On 03/08/2026 9:47 AM, Kenny McCormack wrote:
> > In article <PeMbS.103022$aXr.22087@fx18.ams4>,
> > Johann 'Myrkraverk' Oskarsson  <johann@myrkraverk.invalid> wrote:
> > ...
> >> And why did acc define it signed in the first place?  Maybe the CPU only
> >> had signed bytes, or they were faster than unsigned?  I wouldn't know as
> >> this is a made up example.
> > 
> > Thank you for your response.   I hope to see more responses on this thread.
> > 
> > But, just out of curiosity, why do you way that "this is a made up example" ?
> > To what are you referring and why do you think it was "made up" ?
> > 
> 
> Because I did not bother to dig up my RISC OS computer, and see what
> that C compiler did about the signedness of chars.
> 
> It's a high chance that GCC, when ported to ARM for the first time,
> was compatible with whatever C compiler the original /Acorn/ team
> used, or made.
> 
> I believe I have a continuation of that C compiler on my RISC OS
> machine.  So assuming it still works, I can boot it up, and check
> what it does.

I don't have Norcroft C handy to check, but I expect chars are also
unsigned.

I wasn't there at the time, but I can make an informed guess as to why.  I
think it was Steve Furber who famously said that Acorn gave them two unique
things when designing the original ARM1: no people and no money.  That meant
that everything had to be incredibly simple, because they didn't have
transistors for anything else.

That's why the 32 bit ISA has the instruction:
LDR  Rd,[Ra, #n]
for a 32 bit load, and
LDRB Rd,[Ra, #n]
for an 8 bit load.

Internally, the 8 bit load is just a 4-to-1 mux x 8 bits of the 32 bit
version.  There was no sign extension logic on that datapath (would have
cost transistors and reduced clock speed), so the read value has zeros in
the upper 24 bits.

Also, in that vein, you can easily merge four 8 bit values in registers into a
32-bit word:
ORR Rd,Rs0,Rs1,LSL#8
ORR Rd, Rd,Rs2,LSL#16
ORR Rd, Rd,Rs3,LSL#24

which sign extension would mess up (you'd have to mask off the sign bits
first).

With that, it's natural for chars to be unsigned.  It enables a lot of the
bit- and byte-twiddling that the A32 instruction set is good at.

> Then, we should keep in mind that the /Acorn/ team was used to code
> in assembly.  I believe most of RISC OS is coded in assembly, and
> their original C compiler was -- and had to be -- compatible with
> whatever /application binary interface/ they were used to in that
> assembly code.

Assembly was popular because A32 assembly is nice to write.  Acorn had C and
Modula2 compilers from early on (~1985-6), but as an outside developer they
cost a couple of hundred pounds (in 1980s money) while an assembler was
included in BBC BASIC V in ROM.  So there was a natural bias towards
assembly and BASIC (which works much like raw assembly; no linker)
programming for non-professional developers.  In BBC BASIC bytes are
unsigned.

The OS interfaces (SWIs, like Unix syscalls but much broader and extensible)
were defined for assembly-first, with shims for calling from C (primarily to
force register allocation to match what the SWI wanted; SWIs typically use 8
registers for arguments while C only uses 4 plus the stack).  This interface
doesn't document explicit types as everything is just a 32 bit word
(although they can be retrofitted, eg via OSLib) but in practice most values
are either 32 bit signed/unsigned or 8 bit unsigned (eg in structs).

At the time Acorn had two assemblers: AAsm, which only generated standalone
assembly output, and ObjAsm which played nicely with the C Linker.  So there
was indeed a whole other world which was assembly-only and didn't need to
worry about C.  When you were using C, object files were in the Acorn Object
Format (AOF) and used the Arm Procedure Calling Standard (APCS-R for RISC
OS with 26-bit PC; APCS-A was an earlier version for Arthur).

Nick Burrett did most of the early porting work on GCC for RISC OS circa
1991; since the whole Acorn world was using AOF and APCS-R, in order to be
cross-compatible with libraries that was what GCC had to generate.  When
upstream GCC moved on to ELF, for a long time we had to maintain AOF output
to keep compatibility (RISC OS GCC 3.4.6 [I think] is the last AOF
version; GCC 4 uses ELF).

> So, that's the reason I believe default ARM char is unsigned.  I'm
> sure other regulars will be extremely happy to correct me, so let
> them.  They enjoy that sport.

So TL;DR, as I see it:

- the architecture made its 8 bit datatype zero-extended because it
was the cheapest thing to do in silicon
- assembly programmers used unsigned 8-bit datatypes because that's what the
architecture made easy and cheap, but also because it was the most natural
- BBC BASIC on the 6502 had unsigned bytes and those carried over to ARM BBC
BASIC
- Acorn C followed their lead
- GCC naturally had to follow what Acorn C did
- in all cases it was the best fit for the architecture anyway

Theo

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

#400849

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-08-05 07:30 +0000
Message-ID<114uoq1$2p426$4@dont-email.me>
In reply to#400815
On 04 Aug 2026 13:13:22 +0100 (BST), Theo wrote:

> Also, in that vein, you can easily merge four 8 bit values in
> registers into a 32-bit word:
>
> ORR Rd,Rs0,Rs1,LSL#8
> ORR Rd, Rd,Rs2,LSL#16
> ORR Rd, Rd,Rs3,LSL#24
>
> which sign extension would mess up (you'd have to mask off the sign
> bits first).

That’s what happens in general: any kind of bit-twiddling is usually
much easier with unsigned rather than signed integer types (of
whatever size).

I once had to do some inter-process communication between a client’s
online shop system and the payment processor. The code library they
provided was written in Java, so I wrote a wrapper app around that to
communicate with the main shop system (which I had written in C++).

(Seasoned Java programmers can probably already guess where this story
is going ...)

About once a week or so, a payment would fail to go through. Took me
quite a few examinations of debug messages before I realized that,
because Java only has signed integers and no unsigned, I was sometimes
computing a length field incorrectly due to sign extension.

Put in the necessary masking calls, and all was hunky-dory after that.

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

#400853

FromJohann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid>
Date2026-08-05 18:18 +0800
Message-ID<Z5EcS.2$k1Ya.1@fx12.ams4>
In reply to#400849
On 05/08/2026 3:30 PM, Lawrence D’Oliveiro wrote:
> On 04 Aug 2026 13:13:22 +0100 (BST), Theo wrote:
> 
>> Also, in that vein, you can easily merge four 8 bit values in
>> registers into a 32-bit word:
>>
>> ORR Rd,Rs0,Rs1,LSL#8
>> ORR Rd, Rd,Rs2,LSL#16
>> ORR Rd, Rd,Rs3,LSL#24
>>
>> which sign extension would mess up (you'd have to mask off the sign
>> bits first).
> 
> That’s what happens in general: any kind of bit-twiddling is usually
> much easier with unsigned rather than signed integer types (of
> whatever size).
> 
> I once had to do some inter-process communication between a client’s
> online shop system and the payment processor. The code library they
> provided was written in Java, so I wrote a wrapper app around that to
> communicate with the main shop system (which I had written in C++).
> 
> (Seasoned Java programmers can probably already guess where this story
> is going ...)
> 
> About once a week or so, a payment would fail to go through. Took me
> quite a few examinations of debug messages before I realized that,
> because Java only has signed integers and no unsigned, I was sometimes
> computing a length field incorrectly due to sign extension.


Now, that's only because of your own inexperience at the time.  I have
also dealt with, and I mentioned this briefly in another post, payment
processing in C.  This was to bridge the hardware terminal with the POS
software.

I used the decNumber library for the financial transaction calculations.

I don't begrudge people's inexperience, but why do you make it sound
like you were using integers for the payment field?  Did you not learn
during your first semester of Java, that it's much, much better to use
BigDecimal,

   https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html

for the financial transactions?

Adding comp.lang.java in case someone there wants to chime in.

> 
> Put in the necessary masking calls, and all was hunky-dory after that.

That's good.  I hope this payment processing system is still up and
running.


Have a nice payment processing day!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social

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

#400864

Frombart <bc@freeuk.com>
Date2026-08-05 17:20 +0100
Message-ID<114vnsf$34jbe$1@dont-email.me>
In reply to#400853
On 05/08/2026 11:18, Johann 'Myrkraverk' Oskarsson wrote:
> On 05/08/2026 3:30 PM, Lawrence D’Oliveiro wrote:
>> On 04 Aug 2026 13:13:22 +0100 (BST), Theo wrote:
>>
>>> Also, in that vein, you can easily merge four 8 bit values in
>>> registers into a 32-bit word:
>>>
>>> ORR Rd,Rs0,Rs1,LSL#8
>>> ORR Rd, Rd,Rs2,LSL#16
>>> ORR Rd, Rd,Rs3,LSL#24
>>>
>>> which sign extension would mess up (you'd have to mask off the sign
>>> bits first).
>>
>> That’s what happens in general: any kind of bit-twiddling is usually
>> much easier with unsigned rather than signed integer types (of
>> whatever size).
>>
>> I once had to do some inter-process communication between a client’s
>> online shop system and the payment processor. The code library they
>> provided was written in Java, so I wrote a wrapper app around that to
>> communicate with the main shop system (which I had written in C++).
>>
>> (Seasoned Java programmers can probably already guess where this story
>> is going ...)
>>
>> About once a week or so, a payment would fail to go through. Took me
>> quite a few examinations of debug messages before I realized that,
>> because Java only has signed integers and no unsigned, I was sometimes
>> computing a length field incorrectly due to sign extension.
> 
> 
> Now, that's only because of your own inexperience at the time.  I have
> also dealt with, and I mentioned this briefly in another post, payment
> processing in C.  This was to bridge the hardware terminal with the POS
> software.
> 
> I used the decNumber library for the financial transaction calculations.
> 
> I don't begrudge people's inexperience, but why do you make it sound
> like you were using integers for the payment field?  Did you not learn
> during your first semester of Java, that it's much, much better to use
> BigDecimal,
> 
>    https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html
> 
> for the financial transactions?
> 
> Adding comp.lang.java in case someone there wants to chime in.

What not just add in all 100,000 newsgroups? In case anyone in those 
wants to comment on any of the myriad random topics and ideas you seem 
compelled to hit on every day?

It's getting exhausting.

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

#400878

FromLawrence D’Oliveiro <ldo@nz.invalid>
Date2026-08-05 21:57 +0000
Message-ID<1150bl3$3blde$6@dont-email.me>
In reply to#400864
On Wed, 5 Aug 2026 17:20:33 +0100, bart wrote:

> On 05/08/2026 11:18, Johann 'Myrkraverk' Oskarsson wrote:
>>
>> On 05/08/2026 3:30 PM, Lawrence D’Oliveiro wrote:
>>>
>>> ... I was sometimes computing a length field incorrectly due to
>>> sign extension.
>>
>> ... why do you make it sound like you were using integers for the
>> payment field?
>
> What not just add in all 100,000 newsgroups? In case anyone in those
> wants to comment on any of the myriad random topics and ideas you
> seem compelled to hit on every day?

Also, somebody didn’t quite read what I wrote before commenting ...

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

#400880

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2026-08-05 15:29 -0700
Message-ID<1150dfs$3bm07$1@kst.eternal-september.org>
In reply to#400864
bart <bc@freeuk.com> writes:
[...]
> What not just add in all 100,000 newsgroups? In case anyone in those
> wants to comment on any of the myriad random topics and ideas you seem
> compelled to hit on every day?
>
> It's getting exhausting.

The solution is left as an exercise for your killfile.

Johann 'Myrkraverk' Oskarsson is just the latest in a long line
of tiresome trolls who think everyone else here is Doing It Wrong
and their own posts are more important than anyone else's, whether
they're about C or not.  He will not respond to reasonable requests
(I tried for a while).  Eventually he'll get tired and comp.lang.c
will move on without him.  Meanwhile, in my humble opinion, it's
not worth replying to him.

(I see that this same user posted a few times in 2019, and did not
seem to be a troll at the time.)

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

#400733

FromDavid Brown <david.brown@hesbynett.no>
Date2026-08-03 09:56 +0200
Message-ID<114phk1$14lmv$1@dont-email.me>
In reply to#400708
On 02/08/2026 16:17, 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.
> 

I agree it is an interesting question, but I don't think I have heard 
anything much other than "for compatibility reasons".

I expect that from the earliest pre-standardisation days, some compilers 
treated "char" as signed and some as unsigned.  So the standards 
solution was to let programmers be specified when they need to be (thus 
"signed char" and "unsigned char"), and let compiler writers keep "char" 
as they had done from before.

Since characters at that time were pretty much only 7-bit, it did not 
really matter what signedness was used for character data.  Perhaps the 
choice made a difference for implementation efficiency when extending to 
"int", or for comparisons.  (I have worked with a processor - albeit a 
small microcontroller, rather than a typical target for C compilers - 
which could only do unsigned relational comparisons.  "x < y" for signed 
types was therefore extra work, and "char" is naturally "unsigned char" 
on such targets.)

Of course, in your own programming, if signedness matters then you 
should give it explicitly (or use more appropriate <stdint.h> types if 
you are handling small numbers rather than characters).  That won't 
affect assumptions other people might have made in their code which can 
cause trouble for re-use.  (gcc has "-fsigned-char" and 
"-funsigned-char" that can be of help when dealing with code that 
assumes a certain signedness of char.)

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

gcc has the same "-D" option, but you'd need two commands to build and 
run the program.

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

"-DU" gives the effect of "#define U 1".  The most common use of 
command-line defines is with conditional compilation, so that you could 
have :

#if U
...
#endif

Personally, I prefer to use "#ifdef U" or "#if defined(U)" constructs 
for such tests, and have my compiler complain about attempts to use 
undefined macros in any other way - that reduces the risk of undetected 
mistakes from typos in code using macros.

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

#400763

FromBGB <cr88192@gmail.com>
Date2026-08-03 13:56 -0500
Message-ID<114qogm$1ihsc$1@dont-email.me>
In reply to#400733
On 8/3/2026 2:56 AM, David Brown wrote:
> On 02/08/2026 16:17, 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.
>>
> 
> I agree it is an interesting question, but I don't think I have heard 
> anything much other than "for compatibility reasons".
> 
> I expect that from the earliest pre-standardisation days, some compilers 
> treated "char" as signed and some as unsigned.  So the standards 
> solution was to let programmers be specified when they need to be (thus 
> "signed char" and "unsigned char"), and let compiler writers keep "char" 
> as they had done from before.
> 
> Since characters at that time were pretty much only 7-bit, it did not 
> really matter what signedness was used for character data.  Perhaps the 
> choice made a difference for implementation efficiency when extending to 
> "int", or for comparisons.  (I have worked with a processor - albeit a 
> small microcontroller, rather than a typical target for C compilers - 
> which could only do unsigned relational comparisons.  "x < y" for signed 
> types was therefore extra work, and "char" is naturally "unsigned char" 
> on such targets.)
> 
> Of course, in your own programming, if signedness matters then you 
> should give it explicitly (or use more appropriate <stdint.h> types if 
> you are handling small numbers rather than characters).  That won't 
> affect assumptions other people might have made in their code which can 
> cause trouble for re-use.  (gcc has "-fsigned-char" and "-funsigned- 
> char" that can be of help when dealing with code that assumes a certain 
> signedness of char.)
> 

In my case, I went with signed for my targets, as that is what most code 
expects.

Had noted when porting code to ARM based targets that this is a frequent 
pain point, as there is a lot of code around that tends to assume that 
plain char is signed. Not usually a hard fix, but an annoying one.


I remembered also once (long ago) that I tried implementing a (now 
misplaced) version of BGBCC that tried to target ARM (mostly 
ARM11/Thumb2 at the time), but performance was so dismal that I just 
stuck with GCC and (occasionally) transpiling stuff to C and feeding it 
through GCC (still gave faster results).

Though, was generating some pretty awful code; and the ARM11 chips 
didn't exactly hide the poor performance of inefficient code (and the 
ISA wasn't super friendly in some ways; but I made the possibly mistaken 
idea to target Thumb2 as the primary codegen strategy).


>> 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.
> 
> gcc has the same "-D" option, but you'd need two commands to build and 
> run the program.
> 
>>
>> 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?
>>
> 
> "-DU" gives the effect of "#define U 1".  The most common use of 
> command-line defines is with conditional compilation, so that you could 
> have :
> 
> #if U
> ...
> #endif
> 
> Personally, I prefer to use "#ifdef U" or "#if defined(U)" constructs 
> for such tests, and have my compiler complain about attempts to use 
> undefined macros in any other way - that reduces the risk of undetected 
> mistakes from typos in code using macros.
> 
> 
> 
>

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

#400743

Fromantispam@fricas.org (Waldek Hebisch)
Date2026-08-03 13:48 +0000
Message-ID<114q689$33oi$1@paganini.bofh.team>
In reply to#400708
Kenny McCormack <gazelle@shell.xmission.com> 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.

On original ARM one byte read was zero-extending.  Sign extention
needs 2 extra instructions.  So, the question is: do you want
1 instruction for reading characters or 3 instructions?  If you
choose 1 instruction you have choosen unsigned char.

-- 
                              Waldek Hebisch

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

#400745

Fromcross@spitfire.i.gajendra.net (Dan Cross)
Date2026-08-03 14:47 +0000
Message-ID<114q9lr$llq$1@reader1.panix.com>
In reply to#400708
In article <114nji9$li5u$1@news.xmission.com>,
Kenny McCormack <gazelle@shell.xmission.com> 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.

The original ANSI C rationale touches on this; to quote two
excerpts:

From section 1.1, when discussing "Keep the spirit of C", they
mention, "Make it fast, even if it is not guaranteed to be
portable" and about this, say the following:

|The last proverb needs a little explanation. The potential for
|efficient code generation is one of the most important strengths
|of C. To help ensure that no code explosion occurs for what
|appears to be a very simple operation, many operations are
|defined to be _how the target machine’s hardware does it_ rather
|than by a general abstract rule. An example of this willingness
|to live with _what the machine does_ can be seen in the rules
|that govern the widening of `char` objects for use in
|expressions: whether the values of `char` objects widen to
|signed or unsigned quantities typically depends on which byte
|operation is more efficient on the target machine.

That is, whether `char` is treated as signed or unsigned depends
on the target.  The precedent for this seems to be taken from
history; later on, in the section on "Types" they write:

|Three types of char are specified: signed, plain, and unsigned.
|A plain char may be represented as either signed or unsigned,
|depending upon the implementation, as in prior practice.

So the motivation for chosing one way or the other seems to be,
"do what's fast" and the behavior originated in pre-standards C
compilers.

K&R1 chalks it up to machine differences, and says the following
when discussion type conversions:

|There is one subtle point about the conversion of characters to
|integers. The language does not specify whether variables of
|type `char` are signed or unsigned quantities. When a `char` is
|converted to an `int`, can it ever produce a _negative_
|integer? Unfortunately, this varies from machine to machine,
|reflecting differences in architecture. On some machines
|(PDP-ll, for instance), a `char` whose leftmost bit is 1 will
i|be converted to a negative integer ("sign extension"). On
|others, a `char` is promoted to an `int` by adding zeros at the
|left end, and thus is always positive.
|
|The definition of C guarantees that any character in the
|machine's standard character set will never be negative, so
|these characters may be used freely in expressions as positive
|quantities. But arbitrary bit patterns stored in to character
|variables may appear be negative on some machines, yet positive
|on others.
|
|The most common occurrence of this situation is when the value
|-1 is used for EOF. Consider the code
|
|   char c;
|
|   c = getchar();
|   if (c == EOF)
|       ...
|
|On a machine which does not do sign extension, `c` is always
|positive because it is a `char`, yet EOF is negative. As a
|result, the test always fails. To avoid this, we have been
|careful to use `int` instead of `char` for any variable which
|holds a value returned by `getchar`.

So the original motivation is differences between architectures
with respect to sign extension when converting a char-sized
quantity to something larger.

	- Dan C.

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

#400746

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-08-03 14:47 +0000
Message-ID<114q9lp$1b9f1$1@dont-email.me>
In reply to#400708
On Sun, 02 Aug 2026 14:17:45 +0000, 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 the effects of the integer promotion rules on a system with an 8-bit
execution characterset (CHAR_BIT == 8) that has significant characters in the
0x80 through 0xff range[1], and how it affects the return results of functions
like getchar(), getc(), and fgetc().

A <<char>> is defined by the standard as being "large enough to store any
member of the basic execution character set", and, when storing such an
element "its value is guaranteed to be positive."

So, with our hypothetical execution characterset (above), the compiler would
have to consider <<char>> as unsigned. If it did not, then the getchar(),
getc(), and fgetc() functions would return negative values for some characters,
conflicting with the definition of EOF given in the standard.

But, we rarely find our hypothetical execution characterset "out in the wild",
so compilers (knowing the target execution characterset) often target <<char>>
as a signed value. 



[snip]


[1] Not as hypothetical as you might think; Some of the earliest C compilers
(and current compilers as well) targetted the IBM EBCDIC systems, where much
of the basic execution characterset resides between 0x80 and 0xff, with the
numeric characters residing between 0xf0 and 0xf9. A signed <<char>> would
not work here.

-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

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

#400748

FromLew Pitcher <lew.pitcher@digitalfreehold.ca>
Date2026-08-03 15:04 +0000
Message-ID<114qam6$1b9f1$2@dont-email.me>
In reply to#400746
On Mon, 03 Aug 2026 14:47:21 +0000, Lew Pitcher wrote:

> On Sun, 02 Aug 2026 14:17:45 +0000, 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 the effects of the integer promotion rules on a system with an 8-bit
> execution characterset (CHAR_BIT == 8) that has significant characters in the
> 0x80 through 0xff range[1], and how it affects the return results of functions
> like getchar(), getc(), and fgetc().
[snip]
> [1] Not as hypothetical as you might think; Some of the earliest C compilers
> (and current compilers as well) targetted the IBM EBCDIC systems, where much
> of the basic execution characterset resides between 0x80 and 0xff, with the
> numeric characters residing between 0xf0 and 0xf9. A signed <<char>> would
> not work here.

For what it's worth, this was also the reason (prior to Unicode) that C
did not specify that alphabetic characters would have a contiguous sequence
in the execution characterset. In EBCDIC, the alphabetics group a-i, j-r, s-z
and A-I, J-R, S-Z, with various other characters (both assigned and unassigned)
between the groupings.


-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

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

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

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

csiph-web