Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #392905 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2025-04-26 13:47 +0200 |
| Last post | 2025-05-09 14:13 +0000 |
| Articles | 20 on this page of 165 — 19 participants |
Back to article view | Back to comp.lang.c
Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-26 13:47 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-26 15:00 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-04-26 14:34 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-27 01:12 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-27 14:11 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-27 20:32 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-27 21:55 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 02:53 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? vallor <vallor@cultnix.org> - 2025-04-28 01:21 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 06:28 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? vallor <vallor@cultnix.org> - 2025-04-28 04:55 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 09:27 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-28 09:42 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 09:44 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-28 10:08 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 11:10 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 14:21 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 18:54 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 16:59 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 20:36 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Richard Harnden <richard.nospam@gmail.invalid> - 2025-04-28 19:47 +0100
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 23:26 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Richard Heathfield <rjh@cpax.org.uk> - 2025-04-29 00:24 +0100
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 07:36 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Richard Heathfield <rjh@cpax.org.uk> - 2025-04-29 07:25 +0100
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-06 16:35 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 05:08 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-07 14:58 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-05-07 20:24 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 22:30 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-08 13:13 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-08 15:17 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 14:13 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-08 18:50 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 17:19 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-09 11:45 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-09 02:26 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-09 12:50 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-15 07:33 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-15 12:29 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-09 02:24 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 13:26 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-05-07 23:03 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-08 12:52 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-08 01:08 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-08 01:07 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-08 01:57 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-09 02:22 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-09 00:28 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-09 11:59 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-05-09 14:09 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-09 19:52 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-09 13:31 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-09 12:20 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-09 14:38 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-14 07:07 +0000
Locales [was: Re: Rationale for aligning data on even bytes in a Unix shell file?] Alexis <flexibeast@gmail.com> - 2025-04-29 20:50 +1000
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-29 10:36 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Richard Heathfield <rjh@cpax.org.uk> - 2025-04-29 12:23 +0100
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 00:28 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 07:35 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 12:57 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-04 21:47 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-04-29 11:29 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-04-28 20:50 -0400
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-28 20:05 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-28 18:29 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 20:38 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 01:13 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-29 10:58 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-29 10:17 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-29 15:06 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 07:54 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-28 09:31 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 11:39 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 11:45 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 14:24 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 18:56 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 17:03 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-04-28 20:36 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 17:59 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-28 18:28 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-04-28 22:29 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-28 20:12 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:26 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 09:47 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-04-29 11:17 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 01:53 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-30 11:40 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-30 13:41 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-01 00:15 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-04-30 23:49 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-02 10:25 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Michael S <already5chosen@yahoo.com> - 2025-04-28 22:23 +0300
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-29 07:40 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 01:54 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-30 07:17 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-30 09:45 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-30 09:06 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-30 11:52 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-30 12:21 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-30 12:38 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-30 12:37 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-04-30 12:25 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-30 12:46 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-30 12:38 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 23:56 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? vallor <vallor@cultnix.org> - 2025-05-01 00:57 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? David Brown <david.brown@hesbynett.no> - 2025-05-01 11:13 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-06 13:01 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-07 01:19 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-06 21:47 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-05-07 13:45 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 13:26 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 13:49 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-05-07 18:57 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? BGB <cr88192@gmail.com> - 2025-05-07 22:21 -0500
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-02 09:52 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-30 12:15 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 07:58 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 20:39 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:23 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-28 11:01 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 13:30 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 13:31 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 14:30 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 18:56 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-28 17:05 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 20:40 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:28 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 09:41 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 01:52 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-28 12:01 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:28 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-29 09:51 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 02:39 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 07:37 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:25 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 09:40 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Muttley@DastardlyHQ.org - 2025-04-29 10:12 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 14:24 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-30 07:12 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-01 05:51 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-01 12:20 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-29 12:59 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? vallor <vallor@cultnix.org> - 2025-04-28 09:04 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-28 09:29 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-27 21:40 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 02:55 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-04-27 22:53 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? gazelle@shell.xmission.com (Kenny McCormack) - 2025-04-27 23:45 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 02:55 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-28 01:22 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 06:28 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-28 04:47 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-28 09:28 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 02:37 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 07:40 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-29 07:30 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Bonita Montero <Bonita.Montero@gmail.com> - 2025-04-29 09:42 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Kaz Kylheku <643-408-1753@kylheku.com> - 2025-04-26 23:35 +0000
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-04-27 02:51 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-08 19:56 -0700
Re: Rationale for aligning data on even bytes in a Unix shell file? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-09 12:11 +0200
Re: Rationale for aligning data on even bytes in a Unix shell file? scott@slp53.sl.home (Scott Lurndal) - 2025-05-09 14:13 +0000
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2025-04-28 19:47 +0100 |
| Message-ID | <vuoig5$3ub4j$1@dont-email.me> |
| In reply to | #392996 |
On 28/04/2025 19:36, Bonita Montero wrote: > Am 28.04.2025 um 18:59 schrieb Scott Lurndal: > >> Not really. UTF-8 is UTF-8, regardless of the locale. > > But UTF-8 isn't the standard locale for Unix filesystems > except with macOS. > UTF-8 isn't a locale - it's an encoding.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-04-28 23:26 +0200 |
| Message-ID | <vuorpf$6tnn$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393000 |
Am 28.04.2025 um 20:47 schrieb Richard Harnden: > On 28/04/2025 19:36, Bonita Montero wrote: >> Am 28.04.2025 um 18:59 schrieb Scott Lurndal: >> >>> Not really. UTF-8 is UTF-8, regardless of the locale. >> >> But UTF-8 isn't the standard locale for Unix filesystems >> except with macOS. >> > > UTF-8 isn't a locale - it's an encoding. Idiot. Type "locale" in the shell and thenn return.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-04-29 00:24 +0100 |
| Message-ID | <vup2nt$bi1k$2@dont-email.me> |
| In reply to | #393005 |
On 28/04/2025 22:26, Bonita Montero wrote: > Am 28.04.2025 um 20:47 schrieb Richard Harnden: >> On 28/04/2025 19:36, Bonita Montero wrote: >>> Am 28.04.2025 um 18:59 schrieb Scott Lurndal: >>> >>>> Not really. UTF-8 is UTF-8, regardless of the locale. >>> >>> But UTF-8 isn't the standard locale for Unix filesystems >>> except with macOS. >>> >> >> UTF-8 isn't a locale - it's an encoding. > > Idiot. > Type "locale" in the shell and thenn return. As David knows and you apparently don't, UTF-8 is an encoding, not a locale. If you must call people idiots, it's probably wisest to make sure first that you're on solid ground. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-04-29 07:36 +0200 |
| Message-ID | <vupofl$13pg2$2@raubtier-asyl.eternal-september.org> |
| In reply to | #393007 |
Am 29.04.2025 um 01:24 schrieb Richard Heathfield: > On 28/04/2025 22:26, Bonita Montero wrote: >> Am 28.04.2025 um 20:47 schrieb Richard Harnden: >>> On 28/04/2025 19:36, Bonita Montero wrote: >>>> Am 28.04.2025 um 18:59 schrieb Scott Lurndal: >>>> >>>>> Not really. UTF-8 is UTF-8, regardless of the locale. >>>> >>>> But UTF-8 isn't the standard locale for Unix filesystems >>>> except with macOS. >>>> >>> >>> UTF-8 isn't a locale - it's an encoding. >> >> Idiot. >> Type "locale" in the shell and thenn return. > > As David knows and you apparently don't, UTF-8 is an encoding, not a > locale. > > If you must call people idiots, it's probably wisest to make sure first > that you're on solid ground. UTF-8 has a locale, the chars between 128 and 255 have the locale Latin 1.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2025-04-29 07:25 +0100 |
| Message-ID | <vuprce$15sqo$2@dont-email.me> |
| In reply to | #393018 |
On 29/04/2025 06:36, Bonita Montero wrote: > Am 29.04.2025 um 01:24 schrieb Richard Heathfield: >> On 28/04/2025 22:26, Bonita Montero wrote: >>> Am 28.04.2025 um 20:47 schrieb Richard Harnden: >>>> On 28/04/2025 19:36, Bonita Montero wrote: >>>>> Am 28.04.2025 um 18:59 schrieb Scott Lurndal: >>>>> >>>>>> Not really. UTF-8 is UTF-8, regardless of the locale. >>>>> >>>>> But UTF-8 isn't the standard locale for Unix filesystems >>>>> except with macOS. >>>>> >>>> >>>> UTF-8 isn't a locale - it's an encoding. >>> >>> Idiot. >>> Type "locale" in the shell and thenn return. >> >> As David knows and you apparently don't, UTF-8 is an encoding, >> not a locale. >> >> If you must call people idiots, it's probably wisest to make >> sure first that you're on solid ground. > > UTF-8 has a locale, the chars between 128 and 255 have the locale > Latin 1. A dog has a tail, but that doesn't mean a tail is a dog. Whatever UTF-8 may or may not have, it's an encoding, not a locale. David is right, and you are mistaken. If you must call people idiots, it's probably wisest to make sure first that you're on solid ground. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-05-06 16:35 +0200 |
| Message-ID | <vvd6n5$353gs$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393021 |
Am 29.04.2025 um 08:25 schrieb Richard Heathfield: > A dog has a tail, but that doesn't mean a tail is a dog. Whatever UTF-8 > may or may not have, it's an encoding, not a locale. As no one considers UTF-8 for anything different than encoding Unicode-characters you can say that UTF-8 is encodes a charset.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-07 05:08 -0500 |
| Message-ID | <vvfbnj$ulpc$1@dont-email.me> |
| In reply to | #393209 |
On 5/6/2025 9:35 AM, Bonita Montero wrote:
> Am 29.04.2025 um 08:25 schrieb Richard Heathfield:
>
>> A dog has a tail, but that doesn't mean a tail is a dog. Whatever
>> UTF-8 may or may not have, it's an encoding, not a locale.
>
> As no one considers UTF-8 for anything different than encoding
> Unicode-characters you can say that UTF-8 is encodes a charset.
...
FWIW, UTF-8:
0xxxxxxx //U+0000..U+007F
110xxxxx 10xxxxxx //U+0080..U+07FF
1110xxxx 10xxxxxx 10xxxxxx //U+0800..U+FFFF
And, going further:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx //U+010000..U+10FFFF
Technically it is possible to go larger still, but conventionally
Unicode stops after U+10FFFF.
If you know one side is UTF-8 and the other is UTF-16, then conversion
does not need to know or care which locale is in effect.
UTF-8 should not be confused with 8859-1 or CP1252.
8859-1: Directly maps bytes to 0000..00FF
80..9F being a block of pretty much never-used control characters.
CP1252: Same as 8859-1, but remaps 80..9F to other characters.
There is a variant of UTF-8 known as M-UTF-8, where:
Anything outside 0000..FFFF is first encoded as in UTF-16 and then
encoded as UTF-8 (as opposed to using UTF-8 to directly express values
outside of the "Basic Multilingual Plane");
Some special values, like U+0000 (NUL) are encoded as 2 bytes (C0 80),
allowing NUL to be expressed within a string.
As can be noted with UTF-8, when reading a character as bytes:
00..7F: ASCII
C0..DF (80..BF follows): 0000..07FF
E0..EF (two 80..BF bytes follow): 0000..FFFF
If a pattern is detected which breaks these patterns, we can infer that
it is not UTF-8 (and, random CP1252 text is statistically unlikely to
also be valid as per UTF-8 encoding rules).
As for locales and filesystems:
Ideally, the filesystem proper should not need to know nor care.
UI may care, but UI is its own things.
As for case (in)sensitivity:
Ideally, filesystems should be case sensitive by default;
If someone wants case insensitivity, this can be better handled at the
application or file-browser level.
Admittedly, in my project, I had taken the non-standard option of
treating FAT32/VFAT as case sensitive (though, it will disallow creating
a file if after case normalization, the file already exists but differs
solely in case).
So, say, the OS will not treat "Makefile" and "makefile" as the same
file in FAT, rather if one exists, the other may not be created.
Though, if someone really must make something case-insensitive, a case
could be made for only supporting it for maybe Latin, Greek, and
Cyrillic. Ideally, this would be better handled in a file-browser or
similar, and not in the VFS or FS driver itself.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-05-07 14:58 +0200 |
| Message-ID | <vvflec$11b72$1@dont-email.me> |
| In reply to | #393225 |
On 07.05.2025 12:08, BGB wrote: > [...] > > Though, if someone really must make something case-insensitive, a case > could be made for only supporting it for maybe Latin, Greek, and > Cyrillic. I don't understand what you want to say here; it just sounds strange to me. - Mind to elaborate? > Ideally, this would be better handled in a file-browser or > similar, and not in the VFS or FS driver itself. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-05-07 20:24 +0300 |
| Message-ID | <20250507202430.00005bb9@yahoo.com> |
| In reply to | #393227 |
On Wed, 7 May 2025 14:58:50 +0200 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 07.05.2025 12:08, BGB wrote: > > [...] > > > > Though, if someone really must make something case-insensitive, a > > case could be made for only supporting it for maybe Latin, Greek, > > and Cyrillic. > > I don't understand what you want to say here; it just sounds strange > to me. - Mind to elaborate? > Latin, Greek and Cyrillic are three Bicameral scripts that - have long history - widely used today - have simple mostly unambiguous relationships between upper and lower cases. AFAIK, the only other script that shares all of these properties is Armenian. I would think that BGB just forgot about it and that he would agree that Armenian belong with other three. Support for case-insensitivity for the rest of bicameral scripts in the Unicode would be harder either because of immaturity of some of scripts or because nobody uses them any longer so it would be hard to find the authority in case of confusion. > > Ideally, this would be better handled in a file-browser or > > similar, and not in the VFS or FS driver itself. > > Janis >
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-07 22:30 -0500 |
| Message-ID | <vvh8qg$1ha26$2@dont-email.me> |
| In reply to | #393231 |
On 5/7/2025 12:24 PM, Michael S wrote: > On Wed, 7 May 2025 14:58:50 +0200 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> On 07.05.2025 12:08, BGB wrote: >>> [...] >>> >>> Though, if someone really must make something case-insensitive, a >>> case could be made for only supporting it for maybe Latin, Greek, >>> and Cyrillic. >> >> I don't understand what you want to say here; it just sounds strange >> to me. - Mind to elaborate? >> > > Latin, Greek and Cyrillic are three Bicameral scripts that > - have long history > - widely used today > - have simple mostly unambiguous relationships between upper and lower > cases. > AFAIK, the only other script that shares all of these properties is > Armenian. I would think that BGB just forgot about it and that he > would agree that Armenian belong with other three. > Errm, I was mostly unaware of Armenian... But, yeah, seems it might lump in. Well, except on the "widely used" front... Used primarily in two major dialects of Armenian, where the total number of speakers of the language isn't all that large. I will not claim any sort of expertise on Unicode or all that it contains. But, at least for the "easy" scripts, it mostly makes sense. Though, even for the Latin alphabet, once one goes much outside of ASCII and Latin-1, it gets messy. > Support for case-insensitivity for the rest of bicameral scripts in > the Unicode would be harder either because of immaturity of some of > scripts or because nobody uses them any longer so it would be hard to > find the authority in case of confusion. > And the rules start turning into a mess that it doesn't really seem worth bothering with. >>> Ideally, this would be better handled in a file-browser or >>> similar, and not in the VFS or FS driver itself. >> >> Janis >> >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-05-08 13:13 +0200 |
| Message-ID | <vvi3k6$1o09d$1@dont-email.me> |
| In reply to | #393242 |
On 08.05.2025 05:30, BGB wrote:
> [...]
>
> Though, even for the Latin alphabet, once one goes much outside of ASCII
> and Latin-1, it gets messy.
I noticed that in several places you were referring to Latin-1. Since
decades that has been replaced by the Latin-9 (ISO 8859-15) character
set[*] for practical reasons ('€' sign, for example).
Why is your focus still on the old Latin-1 (ISO 8859-1) character set?
Janis, just curious
[*] Unless Unicode and its encodings are used.
> [...]
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-08 15:17 -0500 |
| Message-ID | <vvj3qe$246ff$1@dont-email.me> |
| In reply to | #393246 |
On 5/8/2025 6:13 AM, Janis Papanagnou wrote:
> On 08.05.2025 05:30, BGB wrote:
>> [...]
>>
>> Though, even for the Latin alphabet, once one goes much outside of ASCII
>> and Latin-1, it gets messy.
>
> I noticed that in several places you were referring to Latin-1. Since
> decades that has been replaced by the Latin-9 (ISO 8859-15) character
> set[*] for practical reasons ('€' sign, for example).
>
> Why is your focus still on the old Latin-1 (ISO 8859-1) character set?
>
> Janis, just curious
>
> [*] Unless Unicode and its encodings are used.
>
U+00A0..U+00FF are designated as Latin-1 in Unicode.
There are further Latin blocks in Unicode, but the characters are more
haphazard, so any rules defined are more likely to operate one character
at a time rather than moving whole blocks of characters (as in ASCII and
the Latin-1 range).
CP-1252, is the dominant remaining ASCII character set in use, is based
on Latin-1, with a few characters from Latin-15 shoved into the places
where control codes previously went.
Say, euro mark (U+20AC) located at 80, Y with diaeresis (U+0178) located
at 9F, ...
Apparently, in some online stats, only 0.02% of webpages use 8859-15 (vs
1.1% for 8859-1).
In my project, as noted, the Unicode mapping was tweaked in that
0080..009F are understood as the 1252 mappings, effectively leaving the
C1 control codes as N/E, but the C1 control codes are pretty much unused
in practice.
And, of the C0 control codes, only a subset of them can be considered
"actually" used:
\0, \a, \b, \t, \r, \r, \e (known used, also have escape notations)
\v, \f (have C escapes, pretty much never encountered though).
In text files, it is usually reduced to:
\t, \r, \n
In this case, it means that the conversion between UTF-8 ans 1252 is
fairly straightforward.
1252 -> UTF-8, simply remap anything in 80..FF into a 2-byte encoding.
UTF-8 -> 1252, remap 0000..00FF to bytes;
Potentially detect/reject if characters outside the range are used;
Some canonical Unicode characters mapped to 1252 range if possible.
Can further note:
00..FF:
Can also be represented in 6x8 font cells
Experimental GUI uses 6x8 for the console.
So, needs 480x200 pixels.
In addition to the 8x8 cells.
80..FF needed some twiddling in some cases to fit in 8x8.
Would have been easier with 8x12 cells or similar, but...
The 2-digit hexadecimal can be represented effectively in 8x8, but not
so well in 6x8, as we generally need 4x5 pixels for each hex digit. At
6x8, one has to leave out the space pixels, so the digits collide,
negatively effecting readability.
It is "mostly" possible to represent the ASCII range in 3x5 pixels
(padded to 4x6 or 4x8), though some characters need to get "creative"
and legibility is poor.
So, say, can't effectively do an 80x25 console at 320x200 pixels (and
still have passable legibility), but 40x25 and 52x25 are possible.
For variable-size text rendering, was mostly using SDF's (signed
distance fields).
Can cover most of the Unicode range by having converted Unifont into SDF
cells (via an offline tool), but most of Unifont not render effectively
at 8x8 or similar.
For best results at smaller sizes, for the 00..FF range, mostly still
using an SDF derived from my 8x8 font (which was generally a bit more
"robust" at the typical text sizes).
Had experimented with geometric "true type" style text rendering (1),
but drawing directly as small glyphs did not work effectively. Had
gotten best results by first drawing the glyphs at an "impractically
large" size (say, 64x64 pixels) and then using this to generate an SDF
image (usually represented as 16x16 pixels), then using the SDF to
generate other text sizes.
In this case, bitmap glyphs are used for the actual rendering, but the
SDF can be used to generate various size bitmap glyphs. Various stages
of caching are used here.
Rendering large text using SDF's is liable to look wonky, but large text
rendering is rare.
1: Although TrueType style font rendering originated in the 1980s, not
sure how it would have been practical with 1980s level technology (say,
machines with 1MHz CPUs and kB of RAM).
Strategies I had found were either computationally intensive or require
first drawing the glyph at a large size (and then down-sampling in some
way to get to the target size). Seemingly, Bitmap fonts would have
presumably been a more practical option.
One downside of SDF's is that they are comparably bulky in terms of
memory use, generally requiring around 8 bits per pixel (4b X, 4b Y).
So, representing the entire Unicode BMP in uncompressed SDF form would
need roughly 16MB. For the font, generally the images are stored in
compressed (2) form (with each "plane" of 16x16 glyphs being
decompressed as needed).
Then say, one has a cache of several planes (each needing 64K), noting
that typically text rendering doesn't chaotically jump between planes.
Though, can note it isn't "that" much worse than using a binary
conversion of Unifont (in 1bpp form), where, even if stored at 1bpp, is
still around 1MB.
2: Decided to keep it shorter. Thus far, images are 256x256 and naively
compressed with a byte-oriented (no entropy coder) LZ77 variant. More
effective would be something with a pixel predictor and entropy coder
(say, like PNG), but PNG decoding is too expensive. Budget option might
be to simply subtract all the bytes from the previous bytes, and use an
AdRice+STF+LZ77 style compressor (arguably "not as good" in terms of
compression, but lower overheads vs something like Deflate).
>> [...]
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 14:13 -0700 |
| Message-ID | <87v7qaerg8.fsf@nosuchdomain.example.com> |
| In reply to | #393262 |
BGB <cr88192@gmail.com> writes:
> On 5/8/2025 6:13 AM, Janis Papanagnou wrote:
>> On 08.05.2025 05:30, BGB wrote:
>>> [...]
>>>
>>> Though, even for the Latin alphabet, once one goes much outside of ASCII
>>> and Latin-1, it gets messy.
>> I noticed that in several places you were referring to
>> Latin-1. Since
>> decades that has been replaced by the Latin-9 (ISO 8859-15) character
>> set[*] for practical reasons ('€' sign, for example).
>> Why is your focus still on the old Latin-1 (ISO 8859-1) character
>> set?
>> Janis, just curious
>> [*] Unless Unicode and its encodings are used.
>>
>
> U+00A0..U+00FF are designated as Latin-1 in Unicode.
I don't think that's accurate. Do you have a reference for that?
It's true that those characters have the same names in Unicode
as in Latin-1. Though the Wikipedia article says that the ranges
0x00..0x1F and 0x7F..0x9F are *undefined*. (That doesn't match my
recollection; I thought they were defined as control characters.)
In any case, Latin-1 and Latin-9 treat those ranges in the same way.
Both can be seen as encodings for small subsets of Unicode.
[...]
> CP-1252, is the dominant remaining ASCII character set in use, is
> based on Latin-1, with a few characters from Latin-15 shoved into the
> places where control codes previously went.
CP-1252 is not an ASCII character set. ASCII is a 7-bit character set.
CP-1252 is an 8-bit character set as are the Latin-* sets. Most 8-bit
sets are *based on* ASCII.
--
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 | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-08 18:50 -0500 |
| Message-ID | <vvjg9u$28sh0$1@dont-email.me> |
| In reply to | #393263 |
On 5/8/2025 4:13 PM, Keith Thompson wrote:
> BGB <cr88192@gmail.com> writes:
>> On 5/8/2025 6:13 AM, Janis Papanagnou wrote:
>>> On 08.05.2025 05:30, BGB wrote:
>>>> [...]
>>>>
>>>> Though, even for the Latin alphabet, once one goes much outside of ASCII
>>>> and Latin-1, it gets messy.
>>> I noticed that in several places you were referring to
>>> Latin-1. Since
>>> decades that has been replaced by the Latin-9 (ISO 8859-15) character
>>> set[*] for practical reasons ('€' sign, for example).
>>> Why is your focus still on the old Latin-1 (ISO 8859-1) character
>>> set?
>>> Janis, just curious
>>> [*] Unless Unicode and its encodings are used.
>>>
>>
>> U+00A0..U+00FF are designated as Latin-1 in Unicode.
>
> I don't think that's accurate. Do you have a reference for that?
https://en.wikipedia.org/wiki/Latin-1_Supplement
Would seem to somewhat imply that this range of codepoints is known as
Latin-1...
> It's true that those characters have the same names in Unicode
> as in Latin-1. Though the Wikipedia article says that the ranges
> 0x00..0x1F and 0x7F..0x9F are *undefined*. (That doesn't match my
> recollection; I thought they were defined as control characters.)
>
0000..001F, usually understood as C0 control codes.
0080..009F, usually understood as C1 control codes.
But, I don't bother with C1 control codes, as they are unused, and
interpreting them as aliases for the other characters that appear in
1252 is more useful, and seemingly not entirely unorhodox.
> In any case, Latin-1 and Latin-9 treat those ranges in the same way.
> Both can be seen as encodings for small subsets of Unicode.
>
Latin-9 does not exactly match up with U+00A0..U+00FF though, whereas
for Latin-1, it does match up.
> [...]
>
>> CP-1252, is the dominant remaining ASCII character set in use, is
>> based on Latin-1, with a few characters from Latin-15 shoved into the
>> places where control codes previously went.
>
> CP-1252 is not an ASCII character set. ASCII is a 7-bit character set.
> CP-1252 is an 8-bit character set as are the Latin-* sets. Most 8-bit
> sets are *based on* ASCII.
>
It is 8-bit and byte-based, and informally I think, most extended-ASCII
codepages were collectively known as ASCII even if only the low 7-bit
range is ASCII proper (and I think more for sake of contrast with "Not
Unicode", eg, UTF-8 / UTF-16 / UCS-2 / ...).
But, say, we know it is CP-1252 and not, say, CP-437 or KOI8-R or
similar; which is the main relevant part.
In some contexts, may or may not also have ANSI escape sequences, though
generally no text editors deal with or make use of ANSI escapes.
Could almost make sense though if one wanted, say, a word-processor
whose format was a direct superset of normal text files rather than some
sort of specialized or proprietary format.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-05-08 17:19 -0700 |
| Message-ID | <87wmaqd49y.fsf@nosuchdomain.example.com> |
| In reply to | #393266 |
BGB <cr88192@gmail.com> writes:
> On 5/8/2025 4:13 PM, Keith Thompson wrote:
>> BGB <cr88192@gmail.com> writes:
>>> On 5/8/2025 6:13 AM, Janis Papanagnou wrote:
>>>> On 08.05.2025 05:30, BGB wrote:
>>>>> [...]
>>>>>
>>>>> Though, even for the Latin alphabet, once one goes much outside of ASCII
>>>>> and Latin-1, it gets messy.
>>>> I noticed that in several places you were referring to
>>>> Latin-1. Since
>>>> decades that has been replaced by the Latin-9 (ISO 8859-15) character
>>>> set[*] for practical reasons ('€' sign, for example).
>>>> Why is your focus still on the old Latin-1 (ISO 8859-1) character
>>>> set?
>>>> Janis, just curious
>>>> [*] Unless Unicode and its encodings are used.
>>>
>>> U+00A0..U+00FF are designated as Latin-1 in Unicode.
>> I don't think that's accurate. Do you have a reference for that?
>
> https://en.wikipedia.org/wiki/Latin-1_Supplement
>
> Would seem to somewhat imply that this range of codepoints is known as
> Latin-1...
The article says that range is called the "Latin-1 Supplement" (I
didn't know that). But it's a supplement derived from a *subset*
of the Latin-1 character set. Latin-1 itself is an 8-bit character
set representing 256 distinct characters (and matching ASCII for
0x00 to 0x7f). The "Latin-1 Supplement" is just U+0080 to U+00FF,
128 characters. The supplement consists of 64 obscure control
characters and 64 printable characters.
The Latin-1 8-bit character set is largely obsolete. Whatever point
you're making, I suspect you could make it much more clearly without
any reference to Latin-1 or Windows-1252.
I think the issue that led to this discussion was how to define case
mapping for case-insensitive file systems. My personal preference is to
use case-sensitive file systems, but that's not always an option.
NTFS is case-insensitive by default, which means it has to have rules
for mapping lowercase to uppercase and vice versa, and for determining
whether two distinct character values are "the same" ('a' and 'A', for
example). We could discuss at great length how NTFS *should* do this,
but surely that determination has already been made in the definition of
NFTS. (I don't know what the rules are.)
>> It's true that those characters have the same names in Unicode
>> as in Latin-1. Though the Wikipedia article says that the ranges
>> 0x00..0x1F and 0x7F..0x9F are *undefined*. (That doesn't match my
>> recollection; I thought they were defined as control characters.)
>>
>
> 0000..001F, usually understood as C0 control codes.
>
> 0080..009F, usually understood as C1 control codes.
>
> But, I don't bother with C1 control codes, as they are unused, and
> interpreting them as aliases for the other characters that appear in
> 1252 is more useful, and seemingly not entirely unorhodox.
The Windows 1252 character set, yet another 8-bit extension to 7-bit
ASCII, assigns printable characters to the range 0x80 to 0x9f (with some
gaps), where both Latin-1 and Unicode have obscure control characters.
But all those printable characters have Unicode code points.
If you want to use Windows-1252 or Latin-1, you can do that, but surely
just using Unicode (preferably with a UTF-8 encoding) is going to cause
fewer problems.
[...]
> It is 8-bit and byte-based, and informally I think, most
> extended-ASCII codepages were collectively known as ASCII even if only
> the low 7-bit range is ASCII proper (and I think more for sake of
> contrast with "Not Unicode", eg, UTF-8 / UTF-16 / UCS-2 / ...).
No, 8-bit character sets are not ASCII. Calling them "extended ASCII"
is reasonable.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-05-09 11:45 +0200 |
| Message-ID | <vvkisb$2ndv6$1@dont-email.me> |
| In reply to | #393267 |
On 09.05.2025 02:19, Keith Thompson wrote: > BGB <cr88192@gmail.com> writes: >> [...] > [...] > > The Latin-1 8-bit character set is largely obsolete. Whatever point > you're making, I suspect you could make it much more clearly without > any reference to Latin-1 or Windows-1252. Indeed. >> [...] > [...] > >> It is 8-bit and byte-based, and informally I think, most >> extended-ASCII codepages were collectively known as ASCII even if only >> the low 7-bit range is ASCII proper (and I think more for sake of >> contrast with "Not Unicode", eg, UTF-8 / UTF-16 / UCS-2 / ...). > > No, 8-bit character sets are not ASCII. Calling them "extended ASCII" > is reasonable. Back then when the ASCII character set got extended it may have been sensible (for a short period of time!) to use an informal term like "extended ASCII" but with the many different extensions it's IMO not reasonable any more to do so, since it inflicts more confusion than make intentions clear. Also "extended ASCII" sounds (in my ears) like a determined character set (as opposed to "_an_ ASCII extension"). Unicode is [roughly] also an ASCII extension. Janis
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-09 02:26 +0000 |
| Message-ID | <vvjp47$2bbhn$6@dont-email.me> |
| In reply to | #393266 |
On Thu, 8 May 2025 18:50:33 -0500, BGB wrote: > But, I don't bother with C1 control codes, as they are unused ... Mostly true. But I think terminal emulators do interpret CSI as equivalent to ESC followed by “[”. > In some contexts, may or may not also have ANSI escape sequences, though > generally no text editors deal with or make use of ANSI escapes. Editors (and other apps) running in “full-screen” mode within a terminal emulator would use them to control the display.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-09 12:50 -0500 |
| Message-ID | <vvlfi7$2uri7$1@dont-email.me> |
| In reply to | #393271 |
On 5/8/2025 9:26 PM, Lawrence D'Oliveiro wrote: > On Thu, 8 May 2025 18:50:33 -0500, BGB wrote: > >> But, I don't bother with C1 control codes, as they are unused ... > > Mostly true. But I think terminal emulators do interpret CSI as equivalent > to ESC followed by “[”. > Possibly, though generally, ESC+[ is used IME. Also creates uncertainty, as AFAIK the terminals traditionally operate on raw bytes regarding ANSI commands, whereas if the terminal interface is UTF-8, a CSI (as a 2-byte encoding) would not be equivalent to 0x9B (if encoded as a single byte). ... >> In some contexts, may or may not also have ANSI escape sequences, though >> generally no text editors deal with or make use of ANSI escapes. > > Editors (and other apps) running in “full-screen” mode within a terminal > emulator would use them to control the display. Doesn't mean you couldn't use a subset for formatting control. As for how a terminal based text-editor would deal with them, I don't know. I was thinking here more of a GUI based editor or pseudo-word processor; where Text + ANSI codes could, in theory, serve a similar role to the RTF format, although more as extended text rather than a sort of markup language (though, modern word processors typically use XML internally, as opposed to the more unusual markup scheme that RTF had used). Sometimes, it would also be nice if there was a sort of a standalone graphical viewer/editor that used MediaWiki or Markdown or AsciiDoc or similar. Well, looks like there is a standalone AsciiDoc editor at least... Now, why is it a 300MB download (and bigger once installed)?... Modern coding practices I guess... Unless it has a whole lot of graphics and sound or similar, this seems like around 1000x larger than it should be for what it sounds like it is. One could almost pose it as a challenge: Write AsciiDoc viewer and editor, but keep it as a single EXE that is under 1MB (well, and more preferably, under 300K, *). *: Though, allowing for dynamically linked MSVCRT on Windows, as the default static-linked MSVCRT is has also gotten needlessly large at this point (well, and combined with MSVC's bloated code generation; but, allowing for 1MB does at least compensate for these issues...). Well, or the challenge of old-times, people trying to keep everything in under 64K or so. ...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-15 07:33 +0000 |
| Message-ID | <10045bj$30sk8$3@dont-email.me> |
| In reply to | #393306 |
On Fri, 9 May 2025 12:50:10 -0500, BGB wrote:
> On 5/8/2025 9:26 PM, Lawrence D'Oliveiro wrote:
>>
>> On Thu, 8 May 2025 18:50:33 -0500, BGB wrote:
>>
>>> But, I don't bother with C1 control codes, as they are unused ...
>>
>> Mostly true. But I think terminal emulators do interpret CSI as
>> equivalent to ESC followed by “[”.
>>
> Possibly, though generally, ESC+[ is used IME.
Actually, several other C1 controls are also defined as equivalents to
sequences beginning with ESC.
> Also creates uncertainty, as AFAIK the terminals traditionally operate
> on raw bytes regarding ANSI commands, whereas if the terminal interface
> is UTF-8, a CSI (as a 2-byte encoding) would not be equivalent to 0x9B
> (if encoded as a single byte).
Yeah, I just checked KDE Konsole, and it doesn’t interpret 0x9B (CSI) as
equivalent to 0x1B followed by “[”.
I suppose I should check if changing the encoding makes any difference to
this ...
> I was thinking here more of a GUI based editor or pseudo-word processor;
> where Text + ANSI codes could, in theory, serve a similar role to the
> RTF format, although more as extended text rather than a sort of markup
> language (though, modern word processors typically use XML internally,
> as opposed to the more unusual markup scheme that RTF had used).
There’s an old thing called “sixel graphics”, which DEC invented back in
the day. I found out KDE Konsole supports it! I think some other terminal
emulators do, too. There is a libsixel library that allows converting
image formats. You only get 256 colours maximum, but that is still
potentially quite useful.
> Sometimes, it would also be nice if there was a sort of a standalone
> graphical viewer/editor that used MediaWiki or Markdown or AsciiDoc or
> similar.
pandoc -f markdown -t pdf «infile» | okular - &
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-05-15 12:29 -0500 |
| Message-ID | <10058ka$388h6$1@dont-email.me> |
| In reply to | #393420 |
On 5/15/2025 2:33 AM, Lawrence D'Oliveiro wrote:
> On Fri, 9 May 2025 12:50:10 -0500, BGB wrote:
>
>> On 5/8/2025 9:26 PM, Lawrence D'Oliveiro wrote:
>>>
>>> On Thu, 8 May 2025 18:50:33 -0500, BGB wrote:
>>>
>>>> But, I don't bother with C1 control codes, as they are unused ...
>>>
>>> Mostly true. But I think terminal emulators do interpret CSI as
>>> equivalent to ESC followed by “[”.
>>>
>> Possibly, though generally, ESC+[ is used IME.
>
> Actually, several other C1 controls are also defined as equivalents to
> sequences beginning with ESC.
>
>> Also creates uncertainty, as AFAIK the terminals traditionally operate
>> on raw bytes regarding ANSI commands, whereas if the terminal interface
>> is UTF-8, a CSI (as a 2-byte encoding) would not be equivalent to 0x9B
>> (if encoded as a single byte).
>
> Yeah, I just checked KDE Konsole, and it doesn’t interpret 0x9B (CSI) as
> equivalent to 0x1B followed by “[”.
>
> I suppose I should check if changing the encoding makes any difference to
> this ...
>
As noted, IME typically the ESC prefixes are used by software. Also
avoids creating ambiguity with UTF-8, and uses the same number of bytes
either way (if the CSI is UTF-8 encoded).
>> I was thinking here more of a GUI based editor or pseudo-word processor;
>> where Text + ANSI codes could, in theory, serve a similar role to the
>> RTF format, although more as extended text rather than a sort of markup
>> language (though, modern word processors typically use XML internally,
>> as opposed to the more unusual markup scheme that RTF had used).
>
> There’s an old thing called “sixel graphics”, which DEC invented back in
> the day. I found out KDE Konsole supports it! I think some other terminal
> emulators do, too. There is a libsixel library that allows converting
> image formats. You only get 256 colours maximum, but that is still
> potentially quite useful.
>
Early on in my project, I had created a scheme where ASCII escapes could
be used to encode 4x4 color-cell graphics, effectively allowing using an
80x50 console as a 320x200 pixel color-cell display (though, 320x100 if
in the 80x25 mode). IIRC, I was originally using 64-color (RGB222)
Not ended up used much. Sixel could be supported in theory as well.
For the consoles, I am using the traditional ANSI escapes (but had
extended them with color-cell stuff), ...
In my ISA project, the text mode, 320x200, 640x400, and 800x600
color-cell modes effectively use the same block formats.
There are some bitmap modes, ended up used some as well:
320x200 hi-color;
640x400 256-color (issues on HW with refresh mem-bandwidth);
800x600 256-color (basically unusable on real HW, broken mess).
In the text-mode (and 800x600 graphics mode), a commonly used block
format is uses 8x8 1-bpp (64 bits), with two RGB555 color endpoints.
In the 640x400 color-cell mode, it instead uses 4x4x2 color-cells, with
4 pairs of RGB555 endpoints (at 256 bits per logical color 8x8 color cell).
Early on, the design of the graphics hardware had a font ROM, but this
was dropped to save FPGA resource costs (so, instead, the text-modes are
primarily handled by using 8x8 color cells).
For 1024x768, thus far, only monochrome was usable. Did experiment with
a sub-mode of 1bpp with 2 8-bit colors per 8x8 cell (total of 1.25bpp,
can do 1024x768 in 128K). Image quality isn't great, as color-cell makes
the limits of the 256 color palette more obvious (but, technically,
still better than pure monochrome). This mode would break from the
previous pattern in that the pixel and color data would be stored
separately, so 96K of monochrome pixel data, followed by 32K of color data.
Getting screen refresh to happen quickly in these modes (for the
experimental GUI) is more difficult though, as, with a 50MHz CPU,
getting an RGB555 internal framebuffer transcoded into color-cells isn't
super fast (so, getting more than single-digit screen-refresh rates is
difficult).
Though, 640x400 is more doable for video playback, etc, if using a
color-cell codec design and bypassing the use of bitmap graphics
(directly redrawing that part of the screen as color cells).
In theory, the closest "standard" option would be to feed the graphics
data in as DXT1 (AKA: S3TC and BC1), though this still requires some
repacking into the on-screen format. I have another (less standard)
compressed texture format that is closer to what the display hardware uses.
Though for image quality, the color-cell modes are still a lot better
than equivalent bitmapped modes would be:
16-color (640x400)
Traditional RGBI ("EGA" color palette).
4-color (800x600)
Eg: black/white/cyan/magenta, black/yellow/red/green, ...
Similar to CGA graphics modes.
2-color (1024x768)
Though, with a selectable per-screen palette
black/white, black/green, black/amber, ...
Screen buffer is RAM backed, but ends up limited to around 128K as, much
over this, it is hard-pressed to get this streamed into the graphics
hardware at 60 Hz (256K is possible, but pushing it).
>> Sometimes, it would also be nice if there was a sort of a standalone
>> graphical viewer/editor that used MediaWiki or Markdown or AsciiDoc or
>> similar.
>
> pandoc -f markdown -t pdf «infile» | okular - &
Possibility...
Wouldn't be so great for interactive WYSIWYG style editing though...
Did find a program, but it is annoyingly bulky, apparently comes with a
crapton of JAR files...
Like, Java isn't really an advantage over C here, when it still ends up
being platform dependent and around 1000x bigger because they ship a
whole ecosystem of JAR files along with it...
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web