Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #391822 > unrolled thread
| Started by | Alexis <flexibeast@gmail.com> |
|---|---|
| First post | 2025-04-02 16:59 +1100 |
| Last post | 2025-04-11 13:51 -0700 |
| Articles | 20 on this page of 458 — 25 participants |
Back to article view | Back to comp.lang.c
"A diagram of C23 basic types" Alexis <flexibeast@gmail.com> - 2025-04-02 16:59 +1100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-02 06:02 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 01:20 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-03 20:35 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-04 04:27 -0500
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 09:02 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 07:32 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 05:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:38 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 10:15 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 04:17 -0500
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 03:28 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 11:33 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 20:53 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 10:57 +0100
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 10:14 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 15:35 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 14:05 +0000
Re: "A diagram of C23 basic types" Thiago Adams <thiago.adams@gmail.com> - 2025-04-02 11:12 -0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:12 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 16:33 +0100
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-02 15:51 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:20 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 23:31 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 23:32 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 03:02 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:42 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 19:32 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:49 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 13:21 -0500
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 01:10 +0100
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 05:09 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-02 23:12 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 01:28 -0500
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 19:37 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 21:48 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:57 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 12:49 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:01 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-09 12:26 -0500
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 20:11 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 09:53 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:37 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:43 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-12 10:10 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-12 17:21 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-12 14:27 -0500
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-10 10:07 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 12:08 +0100
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-10 12:48 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:44 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 12:42 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 15:06 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-10 15:29 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-10 16:55 +0200
C implementation headers [was Re: "A diagram of C23 basic types"] scott@slp53.sl.home (Scott Lurndal) - 2025-04-10 15:17 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-10 13:47 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 14:56 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-12 05:42 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-12 13:46 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:14 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:01 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 02:10 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 04:08 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-02 09:34 -0800
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-02 16:15 -0800
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:42 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:59 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-14 12:44 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 16:25 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-05-06 11:26 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 06:08 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-09 20:38 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 03:05 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 21:06 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 12:39 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:36 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 14:30 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 23:32 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-04 14:07 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:55 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:55 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:43 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:45 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 09:57 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:54 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:46 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 14:14 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:42 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 13:42 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:10 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-04 14:27 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 03:01 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 21:05 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-07 17:30 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 21:49 +0200
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-08 18:40 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 04:33 +0000
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-14 17:40 +0000
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-14 17:46 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-15 09:41 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-14 13:36 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:15 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 22:33 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 15:56 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 23:41 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-14 17:57 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-14 23:25 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:11 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 10:06 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 15:56 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 17:04 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 20:53 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-17 17:56 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-19 09:46 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-19 17:15 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-19 23:15 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-21 20:34 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-21 14:28 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-22 01:07 +0300
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-22 19:30 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-05 16:40 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-22 00:28 +0300
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 22:58 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 21:02 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-16 07:42 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 00:00 -0500
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:08 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 12:29 -0500
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 18:57 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:01 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 17:10 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-16 02:11 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:00 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-14 18:46 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:14 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-15 10:19 -0400
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-15 14:28 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 12:17 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-15 16:20 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 03:03 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 22:34 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-16 22:38 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 23:10 +0000
Re: "A diagram of C23 basic types" dave_thompson_2@comcast.net - 2025-07-29 10:49 -0400
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-07-29 21:18 -0400
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-14 19:43 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 04:15 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 00:40 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-15 19:22 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 12:54 -0500
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 19:10 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 19:54 -0500
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-18 20:03 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-15 22:56 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 23:48 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-16 07:41 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-18 20:10 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-15 14:10 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-15 13:00 -0500
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-15 16:42 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-16 14:00 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 12:48 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-16 20:04 +0000
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-16 16:10 -0500
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-16 23:13 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 16:31 -0700
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-17 01:05 +0100
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-17 01:26 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 23:18 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-28 07:52 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 23:57 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-05-01 06:17 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-16 16:11 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-17 23:16 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 02:10 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-28 19:20 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 08:37 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 13:14 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-28 23:34 -0400
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 08:44 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 23:58 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-30 17:15 -0700
Re: "A diagram of C23 basic types" candycanearter07 <candycanearter07@candycanearter07.nomail.afraid> - 2025-04-29 05:10 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-29 01:24 -0400
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-29 13:02 -0500
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-29 19:25 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 19:00 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:27 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 19:02 +0100
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-07 21:12 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 19:18 +0100
Re: "A diagram of C23 basic types" G <g@nowhere.invalid> - 2025-04-07 18:41 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 22:14 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-07 23:49 +0300
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 23:18 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 22:37 -0400
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 22:46 +0100
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-07 23:57 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-07 16:01 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 11:45 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 11:37 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:25 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-18 02:39 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-18 12:49 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-19 00:16 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-07 20:29 +0100
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-07 22:30 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-07 22:26 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:29 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-08 10:54 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 14:20 +0300
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:25 -0400
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 21:29 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 13:39 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-04-08 13:00 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 16:55 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-08 19:25 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:32 -0400
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 20:53 +0300
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-08 22:30 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 09:01 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 12:23 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 10:08 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 13:32 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 11:00 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-09 13:04 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:24 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-09 12:35 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 11:02 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 14:33 +0300
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:09 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-01 00:01 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:16 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 16:56 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 18:19 +0200
Re: "A diagram of C23 basic types" Richard Harnden <richard.nospam@gmail.invalid> - 2025-04-09 18:32 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:09 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:17 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:34 -0400
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-09 09:00 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:29 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:18 +0000
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-04 02:53 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-02 17:28 +0300
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:17 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 16:59 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:26 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 16:38 +0100
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-02 15:53 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 19:29 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-02 19:26 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 18:48 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-02 17:41 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:16 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 03:27 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:23 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:48 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 21:00 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:51 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:47 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 18:54 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 12:37 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-04 03:27 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-04 03:14 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 18:51 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-02 21:06 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 05:11 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-03 09:23 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 23:19 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 05:46 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-03 22:00 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-06 19:33 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-07 04:09 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 08:12 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-07 18:31 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-07 18:55 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-07 14:19 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 09:45 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-30 17:41 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 05:59 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-05-08 13:42 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:33 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 14:35 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 10:39 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 14:14 -0400
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-09 15:29 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-30 08:37 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:23 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:04 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-02 23:24 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 10:59 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 13:49 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:40 +0200
Re: "A diagram of C23 basic types" Thiago Adams <thiago.adams@gmail.com> - 2025-04-03 11:11 -0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:49 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 16:44 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:58 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-03 23:39 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 12:52 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-07 06:46 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 15:59 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 15:26 +0000
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-03 16:52 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 13:31 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:31 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 20:51 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 12:29 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:46 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:19 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 20:54 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 16:16 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:45 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 11:41 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 11:07 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:58 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:40 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 13:39 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:10 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:12 +0200
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-04 16:11 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 12:52 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-04 04:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:34 +0200
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 14:45 +0300
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 16:03 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-02 19:23 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-02 18:04 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:49 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 15:16 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 13:22 +0000
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-02 23:43 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-03 11:03 +0200
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-04 04:50 +0200
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:38 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-04 15:14 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:26 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-02 18:02 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-03 00:35 -0400
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-03 06:21 +0000
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-03 13:53 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-02 14:12 +0000
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-02 15:16 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-02 13:09 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 08:51 +0000
Re: "A diagram of C23 basic types" Opus <ifonly@youknew.org> - 2025-04-03 15:05 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-03 13:19 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 16:27 +0300
Re: "A diagram of C23 basic types" Opus <ifonly@youknew.org> - 2025-04-03 21:13 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-06 03:31 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-03 11:15 -0700
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-03 16:01 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 09:43 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 03:25 -0700
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 10:28 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-04 03:31 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 15:46 +0200
Re: "A diagram of C23 basic types" Muttley@DastardlyHQ.org - 2025-04-04 14:02 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 17:28 +0200
Re: "A diagram of C23 basic types" Muttley@dastardlyhq.com - 2025-04-04 16:12 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-04 19:25 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-04 12:18 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-05 17:34 +0200
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-05 17:10 -0500
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-04-04 18:49 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-04 21:08 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-04 19:15 -0700
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-05 17:36 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-08 02:39 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-07 23:26 -0400
Re: "A diagram of C23 basic types" Philipp Klaus Krause <pkk@spth.de> - 2025-04-05 19:56 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 14:32 +0100
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-04-08 16:57 +0200
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 16:47 +0100
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-04-08 16:08 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 11:05 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 11:20 +0300
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 11:32 +0100
Re: "A diagram of C23 basic types" Ike Naar <ike@sdf.org> - 2025-04-09 08:53 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 14:46 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-08 23:34 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 17:33 -0700
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-08 22:47 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-08 21:36 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 23:12 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-09 10:55 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-09 13:52 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-10 11:50 +0300
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-11 12:27 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-14 01:24 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-14 12:55 +0300
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 06:56 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-06 13:25 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:37 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-05-08 15:48 +0000
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-08 16:32 +0000
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 22:53 -0700
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-05-08 14:09 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-05-08 16:52 +0200
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:49 -0700
Re: "A diagram of C23 basic types" bart <bc@freeuk.com> - 2025-04-09 11:21 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-09 15:03 -0700
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-09 21:32 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-04-08 22:58 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-08 15:36 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-03 15:02 +0300
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-03 13:06 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-27 12:05 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-04-28 16:27 +0300
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-04-29 13:38 -0500
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 15:06 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-26 09:01 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-26 13:27 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-27 00:39 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-27 02:40 +0100
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-26 19:33 -0700
Re: "A diagram of C23 basic types" BGB <cr88192@gmail.com> - 2025-06-28 14:16 -0500
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-15 19:41 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-07-16 03:55 +0100
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-20 00:16 +0000
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-07-20 07:58 +0100
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-07-20 11:28 +0200
Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-29 04:44 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-29 17:13 +0300
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-06-26 12:51 +0000
Re: "A diagram of C23 basic types" "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-26 13:23 -0700
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-26 23:58 +0000
Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-06-27 03:51 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-06-27 13:44 +0200
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 14:01 +0000
Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-06-26 15:57 +0200
Re: "A diagram of C23 basic types" Richard Heathfield <rjh@cpax.org.uk> - 2025-06-26 16:10 +0100
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-26 12:31 -0700
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-26 23:59 +0300
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-26 21:09 +0000
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-26 17:10 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-27 04:33 +0200
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-27 17:56 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 05:03 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-28 23:18 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-28 20:37 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:48 +0200
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-30 21:59 -0400
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-28 20:51 -0700
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:40 +0200
Re: "A diagram of C23 basic types" - correction Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-29 20:52 +0200
Re: "A diagram of C23 basic types" - correction "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-29 12:14 -0700
Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-06-27 14:02 +0000
Re: "A diagram of C23 basic types" Michael S <already5chosen@yahoo.com> - 2025-06-27 14:52 +0300
Re: "A diagram of C23 basic types" Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-27 20:48 +0200
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-28 23:59 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-29 09:23 -0400
Re: "A diagram of C23 basic types" Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-07-29 00:56 +0000
Re: "A diagram of C23 basic types" James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-07-29 21:13 -0400
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 09:34 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 12:48 -0700
Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-04-11 09:48 -0700
Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-11 13:51 -0700
Page 19 of 23 — ← Prev page 1 … 17 18 [19] 20 21 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-04 19:25 +0200 |
| Message-ID | <vsp4n7$3u65o$1@dont-email.me> |
| In reply to | #392003 |
On 04/04/2025 18:12, Muttley@dastardlyhq.com wrote: > On Fri, 4 Apr 2025 17:28:42 +0200 > David Brown <david.brown@hesbynett.no> gabbled: >> On 04/04/2025 16:02, Muttley@DastardlyHQ.org wrote: >>>> You are using a combined C and C++ compiler in C mode, and it compiles >>>> the C program as C. In that sense, most C++ compilers are also C >>> >>> Err yes! Thats the whole point!! >>> >> >> Then if we back up the thread to where you said C programmers could >> just use a C++ compiler to get new features, you were clearly wrong. >> Of course, we all knew you were wrong already, the only question was >> in what way you were wrong. > > You think having to add an extra cast is so onorous that it doesn't count > as C any more? Any decent C dev would add it by default. Obviously I don't > include you in that grouping. > Do you understand the concept of "example" ? Chris (not me) gave an /example/ of code that is valid C, but not valid C++. There are many other things that he could have picked - this is just a clear and simple one. And yes, I know that adding a cast here is easy. And I know that /some/ C developers do that anyway - I am one of them, partly because C++ compatibility in my C code is sometimes important for my work. (I very rarely have dynamic memory in my code in the first place.) Equally, I know that many C developers do /not/ put in such a cast, and feel that it is a bad thing to have which could hide certain potential errors from compilers or linters. Other cases of C / C++ incompatibility that would cause a lot more inconvenience would be the use of things like "new" as identifiers, type-punning unions (which are UB in C++), compound literals, designated initialisers (even with C++20 support, there are plenty of differences), etc. It is certainly the case that most normal, well-written C is mostly compatible with C++ and with the same semantics. But "most" is not sufficient if you want to compile your C code as though it were C++.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-04 12:18 -0700 |
| Message-ID | <85zfgvivkt.fsf@nosuchdomain.example.com> |
| In reply to | #391993 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> It is easy to write code that is valid C23, using a new feature copied
> from C++, but which is not valid C++ :
>
> constexpr size_t N = sizeof(int);
> int * p = malloc(N);
It's much easier than that.
int class;
Every C compiler will accept that. Every C++ compiler will reject
it. (I think the standard only requires a diagnostic, which can
be non-fatal, but I'd be surprised to see a C or C++ compiler that
generates an object file after encountering a syntax error).
Muttley seems to think that because, for example, "gcc -c foo.c"
will compile C code and "gcc -c foo.cpp" will compile C++ code,
the C and C++ compilers are the same compiler. In fact they're
distinct frontends with shared backend code, invoked differently
based on the source file suffix. (And "g++" is recommended for C++
code, but let's not get into that.)
For the same compiler to compile both C and C++, assuming you don't
unreasonably stretch the meaning of "same compiler", you'd have to
have a parser that conditionally recognizes "class" as a keyword or
as an identifier, among a huge number of other differences between
the two grammars. As far as I know, nobody does that.
You and I know he's wrong. Arguing with him is a waste of everyone's
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-05 17:34 +0200 |
| Message-ID | <vsrihl$2jlgk$1@dont-email.me> |
| In reply to | #392007 |
On 04/04/2025 21:18, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> It is easy to write code that is valid C23, using a new feature copied >> from C++, but which is not valid C++ : >> >> constexpr size_t N = sizeof(int); >> int * p = malloc(N); > > It's much easier than that. > > int class; > > Every C compiler will accept that. Every C++ compiler will reject > it. (I think the standard only requires a diagnostic, which can > be non-fatal, but I'd be surprised to see a C or C++ compiler that > generates an object file after encountering a syntax error). > > Muttley seems to think that because, for example, "gcc -c foo.c" > will compile C code and "gcc -c foo.cpp" will compile C++ code, > the C and C++ compilers are the same compiler. In fact they're > distinct frontends with shared backend code, invoked differently > based on the source file suffix. (And "g++" is recommended for C++ > code, but let's not get into that.) > > For the same compiler to compile both C and C++, assuming you don't > unreasonably stretch the meaning of "same compiler", you'd have to > have a parser that conditionally recognizes "class" as a keyword or > as an identifier, among a huge number of other differences between > the two grammars. As far as I know, nobody does that. Mr. Flibble's universal compiler? :-) > > You and I know he's wrong. Arguing with him is a waste of everyone's > time. > Yes, it seems that way. Sometimes he makes posts that are worth answering or correcting, but the threads with him inevitably go downhill.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-04-05 17:10 -0500 |
| Message-ID | <vss9r7$3bs2o$1@dont-email.me> |
| In reply to | #392031 |
On 4/5/2025 10:34 AM, David Brown wrote:
> On 04/04/2025 21:18, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> It is easy to write code that is valid C23, using a new feature copied
>>> from C++, but which is not valid C++ :
>>>
>>> constexpr size_t N = sizeof(int);
>>> int * p = malloc(N);
>>
>> It's much easier than that.
>>
>> int class;
>>
>> Every C compiler will accept that. Every C++ compiler will reject
>> it. (I think the standard only requires a diagnostic, which can
>> be non-fatal, but I'd be surprised to see a C or C++ compiler that
>> generates an object file after encountering a syntax error).
>>
>> Muttley seems to think that because, for example, "gcc -c foo.c"
>> will compile C code and "gcc -c foo.cpp" will compile C++ code,
>> the C and C++ compilers are the same compiler. In fact they're
>> distinct frontends with shared backend code, invoked differently
>> based on the source file suffix. (And "g++" is recommended for C++
>> code, but let's not get into that.)
>>
>> For the same compiler to compile both C and C++, assuming you don't
>> unreasonably stretch the meaning of "same compiler", you'd have to
>> have a parser that conditionally recognizes "class" as a keyword or
>> as an identifier, among a huge number of other differences between
>> the two grammars. As far as I know, nobody does that.
>
> Mr. Flibble's universal compiler? :-)
>
FWIW, BGBCC does actually handle multiple languages in the same parser
(*1), but it is a hand-written recursive descent parser, so I don't need
to care as much about minor syntactic differences (it can check which
language is being compiled and enable/disable features as needed).
Though, language-specific behavior is a little more tricky in the
tokenizer because this tends to be more performance-sensitive, but
luckily the languages have mostly similar tokenization rules.
*1: Namely:
C (main language used in current projects)
C89, C99 (mostly), assorted newer features.
BGBScript (not used as much now, kinda resembles ActionScript)
It is more or less in the JavaScript/ECMAScript family.
Most directly tied back to ECMAScript3 and ActionScript3.
Later JS went in different directions.
No GC, may need to "delete" stuff to not leak.
Supports automatic and zoned memory lifetimes.
Default is to use default or auto-typing, but supports static.
"var i:int;" or "var i:Integer;" or similar.
BGBScript2
Switched to a more Java-like syntax, primarily static-typed.
Also has some features in common with C#.
Retains ability to use dynamic types or similar if desired.
No GC.
Uses a mix of manually, automatic, and zoned memory management.
Java (sorta, not really used)
Mostly covers Java 1.1 syntax;
Eg: It predates the addition of generics, etc.
Lacks a garbage collector though.
Will need an Object.delete() to not leak.
Had previously wrote a JavaME style library.
C# (also sorta, also not used)
Also limited to early C# syntax (no generics/...).
Also no GC.
Nor any of the runtime library.
C++ (also sorta)
It is similar to Embedded C++, but with namespaces.
Lacks proper multiple inheritance.
Single inheritence with abstract base classes
(the abstract classes are understood as interfaces).
Mostly doesn't support templates (partly added, mostly untested).
Roughly early 90s level features.
Pretty much none of the standard library.
In the case of BS2 / Java / C# / EC++, there was enough overlap to where
most of the same mechanisms could address the languages with minor
syntactic reskinning. Most of the rest is common among C-family languages.
Going further up the ladders (for Java, C#, or C++) would be a big
uphill battle, and not really worth it.
Doesn't make as much sense to advertise support for these languages if
limited to very limited forms.
Can note that the original ancestor language (what BGBCC was before it
was a C compiler) was originally BGBScript, which, as can be noted, was
originally inspired by JavaScript, which along with XML, were hot new
things back when I was in high-school, where the origins of what became
BGBCC got started, though BGBCC proper didn't get started until I was
taking college classes. However, it didn't initially live up to my hopes
(*2), so I had partly shelved it until my current project got started
(nearly a decade ago now), where BGBCC has ended up playing a much more
prominent role.
*2: Early on, I had wanted to use it like a dynamic C compiler for
scripting inside of my 3D engine (partly inspired by Quake 3 and Doom 3;
before pivoting over to copying Minecraft). I soon realized that C
wasn't a great language for this sort of scripting, and returned at the
time mostly to using my JS based language (which had since forked off
into a separate VM), which then started pulling some features from
ActionScript.
I then later stopped working on this 3D engine, and wrote another
shorter-lived 3D engine with the purpose of it being smaller, faster,
and less complicated. For this, had created the BS2 language, but in
some ways BS2 was less good as a scripting language than its predecessor
(but, was better at things like "implementing stuff", so a lot of the
higher-level parts of the engine ended up using this; with mostly the
renderer, VFS, and VM and similar, remaining in C).
Then I switched to doing CPU ISA design and FPGA stuff.
Wrote another smaller 3rd Minecraft like engine, but mostly to try to be
lightweight enough to run on a 50 MHz CPU and under 60MB of RAM (and
using raycasts for visibility determination rather than drawing
everything within a given radius).
This one was plain C, and used a similar chunk format to the prior, just
mostly switching to a smaller region size (and switching from a
Rice-coded LZ scheme to a byte-oriented LZ).
Where:
Chunks were 16x16x16 with an index into a table of blocks.
We can assume fewer that 256 unique blocks per chunk.
Each block was 64 bits in 2nd engine, 32 bits in 3rd engine.
In storage, these are LZ compressed and stored into a "region file".
My 2nd engine used 16x16x16 chunks per region (256x256x256 cube).
Chunk LZ: AdRice+STF based.
My 3rd engine used 8x8x8 chunks per region (128x128x128 cube).
Chunk LZ: RP2 (byte based, sorta like LZ4)
Regions being theoretically in a 3D grid, but 2D in practice.
2nd engine: generated/drew meshes for every chunk in-radius.
Every in-radius chunk also was fully loaded into RAM.
3rd engine: Used raycasts, only built mesh for visible terrain.
Mostly only visible/active chunks get fully loaded.
If no mobs are there, and no raycast reaches it, it is not loaded.
Data Storage:
2nd engine: EXPAK (custom, like simplified ZIP, Deflate based).
Images: BMP, custom codecs.
Audio: WAV (modified IMA ADPCM)
3rd engine: WAD4 (like WAD2, but 32-byte names, and directories).
Images: DDS (mostly DXT1), BMP
Audio: WAV (A-Law, IMA ADPCM)
Contrast, 1st engine:
Chunks were 16x16x128, regions 32x32, mostly like older Minecraft.
Chunks were compressed with RLEW (same algo as Wolf3D and ROTT).
Data was stored in ZIP;
Textures were mostly stored in a modified T.81 JPEG
(extended with optional Alpha channel).
Animated textures used repurposed AVI (sometimes MJPG).
Audio: Also ADPCM? (I forget now.)
Memory use and performance for first engine was terrible though.
Though, can mostly note that similar tech does seem to come up between
one project and another.
Note that, technically, the C mode supports dynamic types and similar,
but with non-standard syntax, eg:
__variant obj = (__variant) { .x=3, .y=4 };
For a JavaScript style ex-nihilo object.
Though, there is an implicit downside:
Using dynamic types will come with a performance penalty, as there is
basically no way to avoid this stuff being slow (if static types are
used, it is faster).
Most scenarios where people tended to use generics, I had used dynamic
types, and my languages had not used generics.
The native class/instance objects are also by-reference by default.
In the C++ case, they are faked with automatic-scoped objects.
POD types may decay into C style structs.
Can note that the general handling of automatic scoping is effectively:
Objects are heap-allocated, and added to a linked list.
When the owner frame exists, everything in the linked-list is deleted;
Backing memory generally comes from "malloc()".
Though, in this case, the malloc implementation also supports type-tags
and zones.
Note that things like C99 VLA's sorta exist, but are kinda playing with
fire here (effectively, these are dynamic heap-allocated arrays).
So, in C syntax:
int arr[n];
Is the equivalent of (BS2 syntax):
int[] arr=new! int[n];
Technically, also "alloca()" uses the same mechanism (alloca is heap
backed). Generally also used for any large arrays or structs, mostly
because in my runtime I am using 128K as the default stack size (so, if
you try to create a local array that is 16K or more, or the frame-size
exceeds 16K, compiler gives a warning and it goes to the heap).
Usually though, 128K is sufficient for the stack (unless recursion gets
out of control or program is using lots of stack arrays).
Note that, while "malloc()" backed memory isn't the fastest possible
option, it isn't that slow either (in most cases, the allocation size is
quantized and then served from a free-list).
My general heap allocator strategy looking sorta like:
Small objects (under 1K or so):
Rounded up to a multiple of 16 bytes;
If corresponding free-list is empty, allocated using a cell-bitmap;
Medium objects (up to 128K):
Size is padded up an turned into an E5.M2 (IIRC) micro-float;
This is also used as the free-list index;
If this fails, uses a linked-list / memory-block allocator.
This part resembles a more traditional malloc().
Large objects:
Generally allocated as pages (falls back to mmap or similar).
When doing an allocator on a more modern system (with multithreading and
similar), it generally makes sense to have free-lists per-thread,
allowing allocations to be served without needing to use a
mutex/critical-section, which is mostly reserved for cases where the
free-list misses.
I generally don't do eager block coalescing, as most often, if a given
size chunk of memory is freed, it will soon be needed again. Instead, it
makes sense to delay this option until there would be a potential need
to expand the heap (then a process is used to reclaim everything from
the corresponding free-lists, coalesce free space, and if this fails to
find something, expand the heap).
Though, some care is needed with multithreading, if dealing with targets
with a weak memory model (and multiple cores). You can't just null-out
the per-thread free-lists, as the threads will not necessarily see the
changed memory (until locking/unlocking a mutex, which may involve
flushing the L1 caches). Generally, it is necessary to set a semaphore
in a way that the thread can see, where the thread can then evict its
free-lists (on the next alloc/free call). Though, the L1 flush and
similar can be skipped if everything is running on a single-core, ...
Though, my compiler mostly targets my own ISA (well, along with RISC-V
and some extended RISC-V variants), but as noted, generally assumes the
use of a weak memory model (my FPGA implementation uses a weak model).
My ISA's tend to be faster than RISC-V, but with a bunch of extensions,
RV64 can be made more competitive (the main heavyweight features being:
register-indexed load/store ops, large-immediate prefixes, and
load/store pair).
Can also note that regarding performance in RISC-V, my compiler seems to
be mostly competitive with GCC in this case (though, GCC still holds
performance advantage if both are targeting plain RV64G). Though there
is also a practical difference in this case that GCC targets ELF whereas
mine targets PE/COFF.
The attempt to add Verilog support is a little harder, as Verilog's
execution model is very different from the C family languages (it is
organized into modules and mostly driven by clock-edges and similar).
Implicitly, some aspects of Verilog have leaked over to the other
languages (things may bleed over unless there is specific reason to
exclude them from the other languages).
Though, some of the features are useful, as explicit bit-manipulation
notation is easier to optimize than shifts and masks (though, granted,
is limited to constant bit values; and, if supported, the advantages
would effectively disintegrate with non-constant values).
Also, performance is helped some here by having added some special
instructions to my ISA to help with bitfield operations (where, code
using Verilog style bit-manipulation is helped notably by things like
bitfield instructions). Though, in my case, I came up with a single
instruction that can do extract/insert and bitfield move (vs, say, ARM
having separate instructions for each scenario).
Though, one limiting factor is that currently it can only do one
bitfield move at a time (and Verilog style code will quickly saturate
things with bitfield moves).
Though, for sake of wanting to do Verilog sims on it, may require
putting effort again into getting my emulators JIT back into working
order (so it can be used as a semi-fast VM). It broke a while ago and I
didn't bother fixing it, as the interpreter was still fast enough to
keep up with real-time emulation vs a 50 MHz FPGA version on my PC.
Likely, running Verilog will still be painfully slow in any case...
I guess, at least if it isn't orders of magnitude slower than Verilator
(which, for a partial sim of the CPU core, runs between 0.1 to 0.2 MHz;
a full SoC simulation being more around 0.02 MHz), possibly good enough.
Main reason this is tempting is because the ability to debug stuff
generated by Verilator is basically non-existent (even if compiling the
generated C++ with "-g" and similar, and uses GDB, one doesn't get that
far as it had basically the original Verilog has been turned into confetti).
At least, if done well, there could be some hope in theory of being able
to source-level debug this stuff.
Where, it doesn't take much to start running into the limitations of
trying to debug stuff with "$display()" statements and similar (and
where the bug is something like "something somewhere in the CPU is
misbehaving").
One starts really wishing for the ability to set a breakpoint at a
certain instruction encoding or similar and then start stepping
line-by-line and inspecting registers like what one can do in something
like Visual studio.
Granted, this also means likely needing to implement a Visual Studio
style debugger (my existing implementation has a dump on VM exit, and at
runtime, an internal GDB style debugger triggered by special keyboard
shortcuts).
>>
>> You and I know he's wrong. Arguing with him is a waste of everyone's
>> time.
>>
>
> Yes, it seems that way. Sometimes he makes posts that are worth
> answering or correcting, but the threads with him inevitably go downhill.
>
This is the sense I am getting as well...
I can only hope I come off a little better, but I don't know sometimes.
...
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2025-04-04 18:49 +0000 |
| Message-ID | <vsp9j6$2j527$1@paganini.bofh.team> |
| In reply to | #391839 |
Muttley@dastardlyhq.org wrote:
> On Wed, 2 Apr 2025 14:12:18 -0000 (UTC)
> antispam@fricas.org (Waldek Hebisch) wibbled:
>>Muttley@dastardlyhq.org wrote:
>>> On Wed, 2 Apr 2025 10:57:29 +0100
>>> bart <bc@freeuk.com> wibbled:
>>>>On 02/04/2025 06:59, Alexis wrote:
>>>>>
>>>>> Thought people here might be interested in this image on Jens Gustedt's
>>>>> blog, which translates section 6.2.5, "Types", of the C23 standard
>>>>> into a graph of inclusions:
>>>>>
>>>>> https://gustedt.wordpress.com/2025/03/29/a-diagram-of-c23-basic-types/
>>>>>
>>>>
>>>>So much for C being a 'simple' language.
>>>
>>> C should be left alone. It does what it needs to do for a systems language.
>>> Almost no use uses it for applications any more and sophisticated processing
>>> using complex types for example are far better done in C++.
>>
>>C99 has VMT (variable modified types). Thanks to VMT and complex types
>>C99 can naturaly do numeric computing that previously was done using
>>Fortran 77. Offical C++ has no VMT. C++ mechanizms look nicer,
>
> Officially no, but I've never come across a C++ compiler that didn't support
> them given they're all C compilers too.
I myself do not use Microsoft compilers, but I was repeatedy told
that they do not support VMT.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-04 21:08 -0400 |
| Message-ID | <vspvqk$sl3u$1@dont-email.me> |
| In reply to | #391839 |
Muttley@dastardlyhq.org wrote: > On Wed, 2 Apr 2025 14:12:18 -0000 (UTC) > antispam@fricas.org (Waldek Hebisch) wibbled: ... >>C99 has VMT (variable modified types). Thanks to VMT and complex types >>C99 can naturaly do numeric computing that previously was done using >>Fortran 77. Offical C++ has no VMT. C++ mechanizms look nicer, > > Officially no, but I've never come across a C++ compiler that didn't support > them given they're all C compilers too. There exist many programs that can compile either C code and C++ code, depending either upon the extension of the file name or explicit command line options to determine which language's rules to apply. That doesn't qualify. Do you know of any compiler that accepts VMTs when compiling according to C++ rules? If so, please provide an example. It will help if the code has some features that are well-formed code in C++, but syntax errors in C, to make it clear that C++'s rules are being implemented.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-04 19:15 -0700 |
| Message-ID | <85semnica1.fsf@nosuchdomain.example.com> |
| In reply to | #392022 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> Muttley@dastardlyhq.org wrote:
>> On Wed, 2 Apr 2025 14:12:18 -0000 (UTC)
>> antispam@fricas.org (Waldek Hebisch) wibbled:
> ...
>>>C99 has VMT (variable modified types). Thanks to VMT and complex types
>>>C99 can naturaly do numeric computing that previously was done using
>>>Fortran 77. Offical C++ has no VMT. C++ mechanizms look nicer,
>>
>> Officially no, but I've never come across a C++ compiler that didn't support
>> them given they're all C compilers too.
>
> There exist many programs that can compile either C code and C++ code,
> depending either upon the extension of the file name or explicit command
> line options to determine which language's rules to apply. That doesn't
> qualify. Do you know of any compiler that accepts VMTs when compiling
> according to C++ rules? If so, please provide an example. It will help
> if the code has some features that are well-formed code in C++, but
> syntax errors in C, to make it clear that C++'s rules are being implemented.
g++ and clang++ both do so:
int main() {
class foo { };
int len = 42;
int vla[len];
}
Both warn about the variable length array when invoked with "-pedantic"
and reject it with "-pedantic-errors".
Microsoft's C and C++ compilers do not support VLAs. (Their C compiler
never supported C99, and VLAs were made optional in C11, so that's not a
coformance issue.)
--
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]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-05 17:36 +0200 |
| Message-ID | <vsrilf$2jlgk$2@dont-email.me> |
| In reply to | #392023 |
On 05/04/2025 04:15, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> Muttley@dastardlyhq.org wrote:
>>> On Wed, 2 Apr 2025 14:12:18 -0000 (UTC)
>>> antispam@fricas.org (Waldek Hebisch) wibbled:
>> ...
>>>> C99 has VMT (variable modified types). Thanks to VMT and complex types
>>>> C99 can naturaly do numeric computing that previously was done using
>>>> Fortran 77. Offical C++ has no VMT. C++ mechanizms look nicer,
>>>
>>> Officially no, but I've never come across a C++ compiler that didn't support
>>> them given they're all C compilers too.
>>
>> There exist many programs that can compile either C code and C++ code,
>> depending either upon the extension of the file name or explicit command
>> line options to determine which language's rules to apply. That doesn't
>> qualify. Do you know of any compiler that accepts VMTs when compiling
>> according to C++ rules? If so, please provide an example. It will help
>> if the code has some features that are well-formed code in C++, but
>> syntax errors in C, to make it clear that C++'s rules are being implemented.
>
> g++ and clang++ both do so:
>
> int main() {
> class foo { };
> int len = 42;
> int vla[len];
> }
>
> Both warn about the variable length array when invoked with "-pedantic"
> and reject it with "-pedantic-errors".
>
There are also things that are VLA's in C, but ordinary arrays in C++,
and acceptable in both languages :
int main() {
const int len = 42;
int arr[len];
}
> Microsoft's C and C++ compilers do not support VLAs. (Their C compiler
> never supported C99, and VLAs were made optional in C11, so that's not a
> coformance issue.)
>
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-04-08 02:39 +0000 |
| Message-ID | <vt229e$15gkb$5@dont-email.me> |
| In reply to | #392022 |
On Fri, 4 Apr 2025 21:08:36 -0400, James Kuyper wrote: > There exist many programs that can compile either C code and C++ code, > depending either upon the extension of the file name or explicit command > line options to determine which language's rules to apply. But note that the *nix tradition is for the “cc” command to invoke nothing more than a “driver” program, which processes each input file according to its extension by spawning additional processes running the actual file- specific processors. And these processors include the linker, for combining object files created by the various compilers into an actual executable (or perhaps a shared library).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-04-07 23:26 -0400 |
| Message-ID | <vt2512$16844$1@dont-email.me> |
| In reply to | #392183 |
On 4/7/25 22:39, Lawrence D'Oliveiro wrote: > On Fri, 4 Apr 2025 21:08:36 -0400, James Kuyper wrote: > >> There exist many programs that can compile either C code and C++ code, >> depending either upon the extension of the file name or explicit command >> line options to determine which language's rules to apply. > > But note that the *nix tradition is for the “cc” command to invoke nothing > more than a “driver” program, which processes each input file according to > its extension by spawning additional processes running the actual file- > specific processors. And these processors include the linker, for > combining object files created by the various compilers into an actual > executable (or perhaps a shared library). My point was that it doesn't matter if the same program can process C++ code, and also accepts VMTs when processing C code. The question was whether it accepts VMTs when processing C++ code. Whether it executes some other program to actually process the code, or does the processing itself, is irrelevant to that issue.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2025-04-05 19:56 +0200 |
| Message-ID | <vsrqsh$qhuu$2@solani.org> |
| In reply to | #391827 |
Am 02.04.25 um 11:57 schrieb bart: > * Where are the fixed-width types from stdint.h? Same as for size_t, etc: They don't exist. Those are not separate types, just typedefs to some other types. E.g. uint16_t could be typedef'ed to unsigned int.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 14:32 +0100 |
| Message-ID | <vt38i9$29prg$1@dont-email.me> |
| In reply to | #392041 |
On 05/04/2025 18:56, Philipp Klaus Krause wrote: > Am 02.04.25 um 11:57 schrieb bart: >> * Where are the fixed-width types from stdint.h? > > Same as for size_t, etc: They don't exist. Those are not separate types, > just typedefs to some other types. E.g. uint16_t could be typedef'ed to > unsigned int. > This is the point I made a few weeks back, but others insisted they were part of C: Me: >> stdint.h et al are just ungainly bolt-ons, not fully supported by the >> language. Keith Thompson: > No, they're fully supported by the language. They've been in the ISO > standard since 1999. > This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header shows 'Thu, 20 Mar 2025 12:10:22 -0700') Clearly, they're not quite as fully supported as short, int etc; they are usually just aliases. But that needn't stop them being shown on such a chart.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-04-08 16:57 +0200 |
| Message-ID | <vt3dgd$2djqe$3@dont-email.me> |
| In reply to | #392197 |
On 08/04/2025 15:32, bart wrote: > On 05/04/2025 18:56, Philipp Klaus Krause wrote: >> Am 02.04.25 um 11:57 schrieb bart: >>> * Where are the fixed-width types from stdint.h? >> >> Same as for size_t, etc: They don't exist. Those are not separate >> types, just typedefs to some other types. E.g. uint16_t could be >> typedef'ed to unsigned int. >> > > This is the point I made a few weeks back, but others insisted they were > part of C: > > > Me: > >> stdint.h et al are just ungainly bolt-ons, not fully supported by the > >> language. > > Keith Thompson: > > > No, they're fully supported by the language. They've been in the ISO > > standard since 1999. > > > > This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header shows > 'Thu, 20 Mar 2025 12:10:22 -0700') > > Clearly, they're not quite as fully supported as short, int etc; they > are usually just aliases. But that needn't stop them being shown on such > a chart. Standard aliases are part of the language standard, and therefore standard and fully supported parts of the language.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-08 16:47 +0100 |
| Message-ID | <vt3gdq$2i87c$1@dont-email.me> |
| In reply to | #392200 |
On 08/04/2025 15:57, David Brown wrote:
> On 08/04/2025 15:32, bart wrote:
>> On 05/04/2025 18:56, Philipp Klaus Krause wrote:
>>> Am 02.04.25 um 11:57 schrieb bart:
>>>> * Where are the fixed-width types from stdint.h?
>>>
>>> Same as for size_t, etc: They don't exist. Those are not separate
>>> types, just typedefs to some other types. E.g. uint16_t could be
>>> typedef'ed to unsigned int.
>>>
>>
>> This is the point I made a few weeks back, but others insisted they
>> were part of C:
>>
>>
>> Me:
>> >> stdint.h et al are just ungainly bolt-ons, not fully supported by the
>> >> language.
>>
>> Keith Thompson:
>>
>> > No, they're fully supported by the language. They've been in the ISO
>> > standard since 1999.
>> >
>>
>> This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header shows
>> 'Thu, 20 Mar 2025 12:10:22 -0700')
>>
>> Clearly, they're not quite as fully supported as short, int etc; they
>> are usually just aliases. But that needn't stop them being shown on
>> such a chart.
>
> Standard aliases are part of the language standard, and therefore
> standard and fully supported parts of the language.
>
So, should they have been on that chart?
> and fully supported parts of the language.
Differences between 'unsigned long long int' and 'uint64_t' up to C23:
uint64_t unsigned long long int
Works without header No Yes
Literal suffix No Yes (ULL etc)
Dedicated printf format No Yes (%llu)
Dedicated scanf format No Yes (whatever that might be)
sizeof() might not be 8 No Maybe
Reserved word[1] No Yes
Outside lexical scope[2] No Yes
Incompatible with
unsigned long int No Yes
[1] Maybe _t names are reserved, but this:
typedef struct {int x,y;} uint64_t;
compiles cleanly with:
gcc -std=c23 -Wall -Wextra -pedantic
This means that they could legally be used for any user-defined types.
[2] This is possible with uint64_t:
#include <stdint.h>
int main() {
typedef struct {int x,y;} uint64_t;
}
You can shadow the names from stdint.h.
So I'd dispute they are as fully supported and 'special' as built-in types.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-04-08 16:08 +0000 |
| Message-ID | <nSbJP.2222868$TBhc.1750662@fx16.iad> |
| In reply to | #392201 |
bart <bc@freeuk.com> writes:
>On 08/04/2025 15:57, David Brown wrote:
>> On 08/04/2025 15:32, bart wrote:
>
>[1] Maybe _t names are reserved, but this:
>
> typedef struct {int x,y;} uint64_t;
>
7.34.15 Integer types <stdint.h>
Typedef names beginning with int or uint and ending with _t are potentially
reserved identifiers and may be added to the types defined in the <stdint.h>
header. Macro names beginning with INT or UINT and ending with _MAX, _MIN,
_WIDTH, or _C are potentially reserved identifiers and may
be added to the macros defined in the <stdint.h> header.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2025-04-08 11:05 -0700 |
| Message-ID | <86r022cyuw.fsf@linuxsc.com> |
| In reply to | #392202 |
scott@slp53.sl.home (Scott Lurndal) writes:
> bart <bc@freeuk.com> writes:
>
>> On 08/04/2025 15:57, David Brown wrote:
>>
>>> On 08/04/2025 15:32, bart wrote:
>>
>> [1] Maybe _t names are reserved, but this:
>>
>> typedef struct {int x,y;} uint64_t;
>
> 7.34.15 Integer types <stdint.h>
>
> Typedef names beginning with int or uint and ending with _t are potentially
> reserved identifiers and may be added to the types defined in the <stdint.h>
> header. Macro names beginning with INT or UINT and ending with _MAX, _MIN,
> _WIDTH, or _C are potentially reserved identifiers and may
> be added to the macros defined in the <stdint.h> header.
It would be better if it had been explained that these statements
are not currently among the requirements given by the C standard,
but only advisories listed in the "Future Directions" section.
Names like uint64_t are not reserved, even in the not-yet-ratified
draft C standard.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-04-09 11:20 +0300 |
| Message-ID | <20250409112043.00006728@yahoo.com> |
| In reply to | #392201 |
On Tue, 8 Apr 2025 16:47:07 +0100
bart <bc@freeuk.com> wrote:
> On 08/04/2025 15:57, David Brown wrote:
> > On 08/04/2025 15:32, bart wrote:
> >> On 05/04/2025 18:56, Philipp Klaus Krause wrote:
> >>> Am 02.04.25 um 11:57 schrieb bart:
> >>>> * Where are the fixed-width types from stdint.h?
> >>>
> >>> Same as for size_t, etc: They don't exist. Those are not separate
> >>> types, just typedefs to some other types. E.g. uint16_t could be
> >>> typedef'ed to unsigned int.
> >>>
> >>
> >> This is the point I made a few weeks back, but others insisted
> >> they were part of C:
> >>
> >>
> >> Me:
> >> >> stdint.h et al are just ungainly bolt-ons, not fully supported
> >> by the >> language.
> >>
> >> Keith Thompson:
> >>
> >> > No, they're fully supported by the language. They've been in
> >> the ISO > standard since 1999.
> >> >
> >>
> >> This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header
> >> shows 'Thu, 20 Mar 2025 12:10:22 -0700')
> >>
> >> Clearly, they're not quite as fully supported as short, int etc;
> >> they are usually just aliases. But that needn't stop them being
> >> shown on such a chart.
> >
> > Standard aliases are part of the language standard, and therefore
> > standard and fully supported parts of the language.
> >
>
> So, should they have been on that chart?
>
> > and fully supported parts of the language.
>
> Differences between 'unsigned long long int' and 'uint64_t' up to C23:
>
> uint64_t unsigned long long int
>
> Works without header No Yes
>
> Literal suffix No Yes (ULL etc)
>
> Dedicated printf format No Yes (%llu)
>
> Dedicated scanf format No Yes (whatever that might be)
>
> sizeof() might not be 8 No Maybe
I don't think that 'No' above is correct.
Take, for example, ADI SHARC DSPs. Traditionally, sizeof(uint64_t) was
2.
I looked into the latest manual and see that now their compiler have
an option -char-size-8 and with this option sizeof(uint64_t)=8. But
this option is available only for those members of SHARC family that
have HW support for byte addressing. Even for those, -char-size-8 is
not a default.
>
> Reserved word[1] No Yes
>
> Outside lexical scope[2] No Yes
>
> Incompatible with
> unsigned long int No Yes
>
I don't understand why you say 'No'. AFAIK, on all existing systems
except 64-bit Unixen the answer is 'Yes'.
>
> [1] Maybe _t names are reserved, but this:
>
> typedef struct {int x,y;} uint64_t;
>
> compiles cleanly with:
>
> gcc -std=c23 -Wall -Wextra -pedantic
>
> This means that they could legally be used for any user-defined types.
>
> [2] This is possible with uint64_t:
>
> #include <stdint.h>
>
> int main() {
> typedef struct {int x,y;} uint64_t;
> }
>
> You can shadow the names from stdint.h.
>
> So I'd dispute they are as fully supported and 'special' as built-in
> types.
>
>
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-04-09 11:32 +0100 |
| Message-ID | <vt5ibt$e5qu$2@dont-email.me> |
| In reply to | #392239 |
On 09/04/2025 09:20, Michael S wrote: > On Tue, 8 Apr 2025 16:47:07 +0100 > bart <bc@freeuk.com> wrote: > >> On 08/04/2025 15:57, David Brown wrote: >>> On 08/04/2025 15:32, bart wrote: >>>> On 05/04/2025 18:56, Philipp Klaus Krause wrote: >>>>> Am 02.04.25 um 11:57 schrieb bart: >>>>>> * Where are the fixed-width types from stdint.h? >>>>> >>>>> Same as for size_t, etc: They don't exist. Those are not separate >>>>> types, just typedefs to some other types. E.g. uint16_t could be >>>>> typedef'ed to unsigned int. >>>>> >>>> >>>> This is the point I made a few weeks back, but others insisted >>>> they were part of C: >>>> >>>> >>>> Me: >>>> >> stdint.h et al are just ungainly bolt-ons, not fully supported >>>> by the >> language. >>>> >>>> Keith Thompson: >>>> >>>> > No, they're fully supported by the language. They've been in >>>> the ISO > standard since 1999. >>>> > >>>> >>>> This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header >>>> shows 'Thu, 20 Mar 2025 12:10:22 -0700') >>>> >>>> Clearly, they're not quite as fully supported as short, int etc; >>>> they are usually just aliases. But that needn't stop them being >>>> shown on such a chart. >>> >>> Standard aliases are part of the language standard, and therefore >>> standard and fully supported parts of the language. >>> >> >> So, should they have been on that chart? >> >> > and fully supported parts of the language. >> >> Differences between 'unsigned long long int' and 'uint64_t' up to C23: >> >> uint64_t unsigned long long int >> >> Works without header No Yes >> >> Literal suffix No Yes (ULL etc) >> >> Dedicated printf format No Yes (%llu) >> >> Dedicated scanf format No Yes (whatever that might be) >> >> sizeof() might not be 8 No Maybe > > I don't think that 'No' above is correct. > Take, for example, ADI SHARC DSPs. Traditionally, sizeof(uint64_t) was > 2. > I looked into the latest manual and see that now their compiler have > an option -char-size-8 and with this option sizeof(uint64_t)=8. But > this option is available only for those members of SHARC family that > have HW support for byte addressing. Even for those, -char-size-8 is > not a default. There was a stipulation for an 8-bit 'char' type, but it got lost. Maybe I deleted it and intended to have it as a note later on. But better here would be whether the width (sizeof*CHAR_BIT) could be over 64 bits. >> >> Reserved word[1] No Yes >> >> Outside lexical scope[2] No Yes >> >> Incompatible with >> unsigned long int No Yes >> > > I don't understand why you say 'No'. AFAIK, on all existing systems > except 64-bit Unixen the answer is 'Yes'. That last one was an oversight which I only spotted after posting (in Reddit you can edit your posts!). The No should be Maybe.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2025-04-09 08:53 +0000 |
| Message-ID | <slrnvvcdd6.fvh.ike@iceland.freeshell.org> |
| In reply to | #392201 |
On 2025-04-08, bart <bc@freeuk.com> wrote: > Differences between 'unsigned long long int' and 'uint64_t' up to C23: > > uint64_t unsigned long long int > > [...] > > Literal suffix No Yes (ULL etc) UINT64_C > Dedicated printf format No Yes (%llu) PRIu64
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-04-08 14:46 -0700 |
| Message-ID | <87h62ys4w5.fsf@nosuchdomain.example.com> |
| In reply to | #392197 |
bart <bc@freeuk.com> writes:
> On 05/04/2025 18:56, Philipp Klaus Krause wrote:
>> Am 02.04.25 um 11:57 schrieb bart:
>>> * Where are the fixed-width types from stdint.h?
>> Same as for size_t, etc: They don't exist. Those are not separate
>> types, just typedefs to some other types. E.g. uint16_t could be
>> typedef'ed to unsigned int.
>
> This is the point I made a few weeks back, but others insisted they
> were part of C:
Of course they're part of C. Nobody has said they aren't.
I disagree with Philipp's statement that they "don't exist", but the
rest of what he said is accurate.
Specifically, they're part of the C library, not part of the core
language. They're mentioned in section 7 of the standard, not in 6.2.5,
which describes types. They are (typically, probably always) definedd
as typedefs, aliases for other types, leading in one or more steps to the
predefined types described in 6.2.5 (or to extended integer types).
> Me:
>>> stdint.h et al are just ungainly bolt-ons, not fully supported by the
>>> language.
>
> Keith Thompson:
>
>> No, they're fully supported by the language. They've been in the ISO
>> standard since 1999.
>
> This is an exchange posted on 20-Mar-2025 at 19:10 GMT (header shows
> 'Thu, 20 Mar 2025 12:10:22 -0700')
Right. Your claim that they're "not fully supported by the language" is
wrong (unless you restrict "language" to section 6 of the standard for
some reason).
int is defined in section 6. size_t is defined in section 7. Of course
you know all this and are pretending to be troubled by it.
> Clearly, they're not quite as fully supported as short, int etc; they
> are usually just aliases. But that needn't stop them being shown on
> such a chart.
Apparently the author of the chart chose to include types that are
defined by the core language, not by the library. I think that was a
perfectly valid choice. Adding all the types specified in the library
would make the chart far too big and not much more informative.
If you don't like it, make your own chart.
--
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 19 of 23 — ← Prev page 1 … 17 18 [19] 20 21 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web