Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #395879 > unrolled thread
| Started by | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| First post | 2025-12-22 08:48 +0000 |
| Last post | 2026-01-08 02:57 +0000 |
| Articles | 20 on this page of 185 — 25 participants |
Back to article view | Back to comp.lang.c
srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-22 08:48 +0000
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 06:44 -0500
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 13:18 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-22 12:13 -0500
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 18:41 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-22 20:45 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-22 21:16 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:19 +0100
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:57 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 11:18 +0200
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 10:54 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-23 13:50 +0200
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 18:29 -0500
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 16:30 -0800
Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-23 17:54 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 00:08 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 02:02 +0000
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-23 23:43 -0500
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 05:34 +0000
Re: srand(0) antispam@fricas.org (Waldek Hebisch) - 2025-12-24 09:00 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 12:12 +0200
Article of Melissa O'Nail (Was: srand(0)) Michael S <already5chosen@yahoo.com> - 2025-12-28 02:44 +0200
Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2025-12-28 05:38 +0000
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2025-12-28 12:35 +0200
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-05 14:21 +0200
Re: Article of Melissa O'Nail antispam@fricas.org (Waldek Hebisch) - 2026-01-07 10:51 +0000
Re: Article of Melissa O'Nail Michael S <already5chosen@yahoo.com> - 2026-01-08 14:03 +0200
Re: Article of Melissa O'Nail Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:40 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-08 09:26 -0800
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 13:48 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 08:41 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-08 01:06 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 05:26 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-03 16:37 +0200
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-17 23:47 -0800
Re: srand(0) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-02-18 11:21 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 10:01 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-19 14:33 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-19 20:47 +0100
Re: srand(0) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-02-20 16:01 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-21 11:09 +0100
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-02-19 14:39 -0800
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-20 09:16 +0100
Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 08:32 -0500
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 16:05 +0100
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-02-23 19:59 +0200
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-23 20:06 +0100
Re: srand(0) Paul <nospam@needed.invalid> - 2026-02-23 15:24 -0500
Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-24 07:08 +0100
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2026-02-24 10:24 +0100
Re: srand(0) Axel Reichert <mail@axel-reichert.de> - 2026-02-26 19:13 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 05:22 -0600
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:09 -0600
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:51 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 04:24 -0600
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:50 -0800
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:46 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-07 18:14 +0200
Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-22 19:16 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-22 22:35 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:24 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-23 09:59 +0100
Re: srand(0) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2025-12-23 11:09 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:49 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:13 +0000
Re: srand(0) richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-12-23 19:05 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-23 02:16 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:47 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-23 16:08 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:44 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:17 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 08:25 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:45 +0000
Re: srand(0) David Brown <david.brown@hesbynett.no> - 2025-12-23 19:15 +0100
Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 00:39 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-23 02:17 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 14:55 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-24 23:35 -0600
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:23 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 14:48 -0600
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 15:12 -0600
Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-23 06:49 +0000
Re: srand(0) John McCue <jmclnx@gmail.com.invalid> - 2025-12-23 20:37 +0000
Re: srand(0) Ike Naar <ike@sdf.org> - 2025-12-24 15:22 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-23 07:25 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 06:16 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:21 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-24 19:00 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 03:07 -0600
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 19:31 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 21:14 +0100
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 15:29 -0600
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-25 23:25 -0500
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-25 23:41 -0600
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 05:42 +0000
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-26 01:52 -0500
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-26 07:56 +0000
Re: srand(0) BGB <cr88192@gmail.com> - 2025-12-26 04:48 -0600
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 10:51 +0200
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-24 00:59 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:28 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 17:44 +0200
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 16:17 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 17:53 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:27 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 17:33 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-24 20:16 +0200
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-25 03:17 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:13 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 04:30 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-25 09:10 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-26 08:08 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 06:07 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-30 18:42 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 03:10 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 03:28 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 09:37 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:32 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:02 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 19:20 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 21:53 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 23:50 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 14:32 +0200
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-02 16:18 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:52 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-02 20:46 +0000
Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-03 04:08 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-03 04:39 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-03 14:24 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-03 20:38 +0200
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:37 -0800
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-31 17:24 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:17 -0800
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 12:30 -0500
Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 18:42 +0000
Re: srand(0) Paul <nospam@needed.invalid> - 2025-12-31 15:07 -0500
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 22:18 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:55 +0000
Re: srand(0) bart <bc@freeuk.com> - 2025-12-31 22:57 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:00 -0800
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 01:03 +0000
Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 14:05 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 19:03 +0000
Re: srand(0) bart <bc@freeuk.com> - 2026-01-01 20:28 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:29 -0800
Re: srand(0) highcrew <high.crew3868@fastmail.com> - 2026-01-01 00:31 +0100
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:05 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:29 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:52 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:14 -0800
Re: srand(0) Geoff <geoff@invalid.invalid> - 2026-01-05 20:00 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:03 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-30 19:35 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-31 04:51 +0000
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2025-12-31 15:15 +0200
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-31 20:51 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 15:00 -0800
Re: srand(0) Michael S <already5chosen@yahoo.com> - 2026-01-01 01:45 +0200
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-31 16:34 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-01 07:23 +0000
Re: srand(0) Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2026-01-01 02:01 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-01-01 02:29 +0000
Re: srand(0) Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-30 06:34 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-30 14:05 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-28 05:51 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2025-12-24 17:08 +0000
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-07 07:39 -0800
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-07 13:54 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 15:34 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 14:44 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 06:06 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-08 22:46 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-09 22:38 +0000
Re: srand(0) scott@slp53.sl.home (Scott Lurndal) - 2026-01-09 23:27 +0000
Re: srand(0) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-01-09 17:09 -0800
Re: srand(0) Kaz Kylheku <046-301-5902@kylheku.com> - 2026-01-10 19:44 +0000
Re: srand(0) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-09 00:36 -0800
Re: srand(0) Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-23 11:04 +0100
Re: srand(0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-23 21:44 -0800
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-24 15:41 +0000
Re: srand(0) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-24 18:04 +0100
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2025-12-25 05:41 +0000
Re: srand(0) Michael Sanders <porkchop@invalid.foo> - 2026-01-08 02:57 +0000
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 16:34 -0800 |
| Message-ID | <87cy3uuq57.fsf@example.invalid> |
| In reply to | #396047 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 31 Dec 2025 15:00:24 -0800
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
[...]
>> If I were going to look into the behavior on Windows, I'd probably
>> want to use Windows native features. (I tried my test on Cygwin,
>> and the callee wasn't invoked.)
>
> That's likely because under Windows callee is named callee.exe.
> I didn't try on cygwin, but that was the reason of failure under msys2.
> Also, I am not sure if slash in the name is allowed. May be, backslash
> is required.
No, that's definitely not it. Cygwin emulates a Unix-like system
on top of Windows. It creates executables with a ".exe" suffix,
but plays some tricks so that "foo.exe" also looks like "foo".
Also, Cygwin uses "/" as a directory separator. When I modified
the caller program to set argv[0], it worked correctly.
I've updated the caller to show the result of execve() (which
normally doesn't return). It returns -1 to indicate an error and
sets errno to 7 (E2BIG, Argument list too long) -- which is a bit
odd, but there's no E2SMALL code.
[...]
--
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 | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-01 07:23 +0000 |
| Message-ID | <10j57cq$3aao2$1@dont-email.me> |
| In reply to | #396050 |
On Wed, 31 Dec 2025 16:34:44 -0800, Keith Thompson wrote: > [...] > > It creates executables with a ".exe" suffix, > but plays some tricks so that "foo.exe" also looks like "foo". Small aside... Minus the suffix, path in order of search is (if i recall correctly): 1. an associated 'opener' if any (can be defined by associating suffix .foo with notepad.exe or whatever, also inherits the calling app's icon) 2. in memory 'alias' via script/batch (set var=foo) 3. current folder 4. system path but... this also depends on %COMSPEC% ($SHELL in Windows) typically: powershell.exe cmd.exe command.exe user defined (like perl.exe for .pl or "busybox sh" for .sh) -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2026-01-01 02:01 +0000 |
| Message-ID | <10j4khr$339qm$1@dont-email.me> |
| In reply to | #396038 |
On 31/12/2025 23:00, Keith Thompson wrote: > Michael S <already5chosen@yahoo.com> writes: >> On Tue, 30 Dec 2025 19:35:12 -0800 >> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > [...] >>> For more information, see >>> <https://github.com/Keith-S-Thompson/argv0>. >> >> If you are interested in behavior on non-POSIX systems, primarily >> Windows, but possibly others as well (e.g. VMS) then using exec() in >> caller sounds like a bad idea. It just not how these systems work and >> not how people write programs on them. >> Even when exec() *appears* to works in some environments (like >> msys2) it likely emulated by spawn() followed by exit(). >> >> I'd implement caller with spawn(). I suppose that even on POSIX it is >> more idiomatic. > > If I were going to look into the behavior on Windows, I'd probably > want to use Windows native features. (I tried my test on Cygwin, > and the callee wasn't invoked.) > > Apparently the Windows way to invoke a program is CreateProcessA(). > But it takes the command line as a single string. There might not > be a Windows-native way to exercise the kind of control over argc > and argv provided by POSIX execve(). On Windows there is a command-line provided to applications via GetCommandLine() api. This is a single zero-terminated string. There is no mention of the possibility of GetCommandLine returning NULL. Windows (and in general non-*nix OS's) does not have a concept of processes having a list of strings as their basic start up mechanism. [Windows processes have an environment strings block, similar to *nix and used in the same way, but the "command line" is just a string...] Windows views parsing of the command-line string to be in the application domain, I guess. The MSVC compiler provides console-mode applications with the usual (argc, argv) but the MSVC application start-up code does this rather than the OS. For GUI-mode apps, MSVC provides a different interface to the user entry point. (Of course, if the app wants the command-line it can call the Windows api to get it, and if it wants command-line tokens it can parse it itself, or call CommandLineToArgv() api which is part of the shell api and replicates MSVC startup behaviour...) Mike.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-01 02:29 +0000 |
| Message-ID | <10j4m77$33tuu$1@dont-email.me> |
| In reply to | #396052 |
On Thu, 1 Jan 2026 02:01:29 +0000, Mike Terry wrote: > On Windows there is a command-line provided to applications via > GetCommandLine() api. This is a single zero-terminated string. This idea comes from CP/M, which in turn copied it from the old DEC operating systems. This is a very primitive model, which never envisioned the more advanced kinds of things a Unix-style command line makes possible. > Windows views parsing of the command-line string to be in the > application domain, I guess. Consider a basic thing like quoting words on the command line, to allow the passing of arguments with spaces and other odd characters in them: with a raw command string, both ends have to agree on the same conventions for doing such things. Getting this wrong leads to great sadness. On *nix systems, there is no need for such conventions: the argv array will be passed literally from invoking program to invoking one, with no need for special quoting at all.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-30 06:34 +0000 |
| Message-ID | <10ivrpq$1jmuu$1@dont-email.me> |
| In reply to | #395981 |
On Fri, 26 Dec 2025 08:08:57 -0000 (UTC), Michael Sanders wrote: > Check out <https://jrgraphix.net/r/Unicode/2500-257F> > > Lots of useful glyphs there. Assuming the reader's software can > render these, here's some tree glyphs that provide a smart visual > representation of branching hierarchical taxonomies. Another possibility is sixel graphics <https://www.arewesixelyet.com/>. Seems to be enjoying a mini-revival at the moment.
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-30 14:05 +0000 |
| Message-ID | <10j0m6v$1qv0i$1@dont-email.me> |
| In reply to | #396017 |
On Tue, 30 Dec 2025 06:34:35 -0000 (UTC), Lawrence D’Oliveiro wrote: > Another possibility is sixel graphics > <https://www.arewesixelyet.com/>. Seems to be enjoying a mini-revival > at the moment. Hey neato-burrito! Many thanks for the pointer Lawrence, appreciate that =) I was sort of dimly of aware of sixel somehow or another, but you've rattled me out of hibernation with this. Think I'll to try to cook up something I can play around with. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-28 05:51 +0000 |
| Message-ID | <10iqggf$1klk$1@dont-email.me> |
| In reply to | #395961 |
On Thu, 25 Dec 2025 04:30:45 -0000 (UTC), Michael Sanders wrote: > ... built in help too. Help is complete (err... except for man page) <https://drive.google.com/file/d/1m_9oOQX4KRrMVYpPobjfTGkC2UFSoiKk/view?usp=sharing> -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-12-24 17:08 +0000 |
| Message-ID | <A6V2R.199267$79B9.90065@fx14.iad> |
| In reply to | #395947 |
Michael S <already5chosen@yahoo.com> writes:
>On Wed, 24 Dec 2025 15:28:24 -0000 (UTC)
>Michael Sanders <porkchop@invalid.foo> wrote:
>
>> On Wed, 24 Dec 2025 10:51:14 +0200, Michael S wrote:
>>
>> > On Tue, 23 Dec 2025 07:25:42 -0000 (UTC)
>> > Michael Sanders <porkchop@invalid.foo> wrote:
>> >
>> >> On Tue, 23 Dec 2025 00:39:49 -0000 (UTC), John McCue wrote:
>> >>
>> >> > I like to just read /dev/urandom when I need a random
>> >> > number. Seem easier and more portable across Linux &
>> >> > the *BSDs.
>> >> >
>> >> > int s;
>> >> > read(fd, &s, sizeof(int));
>> >>
>> >> Thanks John. Wish there was such a 'device' under Windows...
>> >>
>> >
>> > There is.
>> > Windows XP/Vista/7:
>> > https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom
>> > Win8 and later:
>> > https://learn.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptgenrandom
>> >
>>
>> Was referring to the concept of a device in the same idiom of
>> BSD/Linux/Apple...
>>
>> Something that is just as easy to use.
>>
>
>What is not easy in the functions referred above? You do the same
>couple of steps as on Unix: open device then read few bytes from it.
>Only names are different.
Even easier in the GCC; one can just generate the rdrand instruction directly
for intel targets:
unsigned int __builtin_ia32_rdrand16_step (unsigned short *);
unsigned int __builtin_ia32_rdrand32_step (unsigned int *);
unsigned int __builtin_ia32_rdrand64_step (unsigned long long *);
ARM64 provides a system register (RNDR) which is accessible at
all exception levels. The Neoverse implementations provide
implementation-defined system registers that convert the
read of the register into a bus transaction to a device which
satisfies the random number request (set up by the boot firmware);
so the characteristics of the hardware generator are specific to
an implementation of a neoverse core.
int __builtin_arm_rndr(uint64_t *val);
int __builtin_arm_rndrrs(uint64_t *val);
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-07 07:39 -0800 |
| Message-ID | <867bttph43.fsf@linuxsc.com> |
| In reply to | #395895 |
John McCue <jmclnx@gmail.com.invalid> writes: > Michael Sanders <porkchop@invalid.foo> wrote: > >> Is it incorrect to use 0 (zero) to seed srand()? >> >> int seed = (argc >= 2 && strlen(argv[1]) == 9) >> ? atoi(argv[1]) >> : (int)(time(NULL) % 900000000 + 100000000); >> >> srand(seed); > > I like to just read /dev/urandom when I need a random > number. Seem easier and more portable across Linux & > the *BSDs. > > int s; > read(fd, &s, sizeof(int)); Apples and oranges. Many applications that use random numbers need a stream of numbers that is deterministic and reproducible, which /dev/urandom is not.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-07 13:54 -0800 |
| Message-ID | <87ikddgkc2.fsf@example.invalid> |
| In reply to | #396266 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> John McCue <jmclnx@gmail.com.invalid> writes:
>> Michael Sanders <porkchop@invalid.foo> wrote:
>>> Is it incorrect to use 0 (zero) to seed srand()?
>>>
>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
>>> ? atoi(argv[1])
>>> : (int)(time(NULL) % 900000000 + 100000000);
>>>
>>> srand(seed);
>>
>> I like to just read /dev/urandom when I need a random
>> number. Seem easier and more portable across Linux &
>> the *BSDs.
>>
>> int s;
>> read(fd, &s, sizeof(int));
>
> Apples and oranges. Many applications that use random numbers
> need a stream of numbers that is deterministic and reproducible,
> which /dev/urandom is not.
And neither is the non-conforming rand() on OpenBSD.
The rand(1) man page on OpenBSD 7.8 says:
Standards insist that this interface return deterministic
results. Unsafe usage is very common, so OpenBSD changed the
subsystem to return non-deterministic results by default.
To satisfy portable code, srand() may be called to initialize
the subsystem. In OpenBSD the seed variable is ignored,
and strong random number results will be provided from
arc4random(3). In other systems, the seed variable primes a
simplistic deterministic algorithm.
It does provide an srand_deterministic() function that behaves the way
srand() is supposed to.
And a program that calls rand() produces a link-time warning, even
though OpenBSD's rand() *doesn't* return deterministic values.
ld: warning: rand_test.c(rand_test.o:(main)): warning: rand() may return deterministic values, is that what you want?
(In a similarly questionable decision, OpenBSD's printf triggers a
SIGABRT signal if the format string uses "%n".)
--
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 | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-08 15:34 +0000 |
| Message-ID | <10joipc$1jc43$1@dont-email.me> |
| In reply to | #396283 |
On Wed, 07 Jan 2026 13:54:21 -0800, Keith Thompson wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> John McCue <jmclnx@gmail.com.invalid> writes:
>>> Michael Sanders <porkchop@invalid.foo> wrote:
>>>> Is it incorrect to use 0 (zero) to seed srand()?
>>>>
>>>> int seed = (argc >= 2 && strlen(argv[1]) == 9)
>>>> ? atoi(argv[1])
>>>> : (int)(time(NULL) % 900000000 + 100000000);
>>>>
>>>> srand(seed);
>>>
>>> I like to just read /dev/urandom when I need a random
>>> number. Seem easier and more portable across Linux &
>>> the *BSDs.
>>>
>>> int s;
>>> read(fd, &s, sizeof(int));
>>
>> Apples and oranges. Many applications that use random numbers
>> need a stream of numbers that is deterministic and reproducible,
>> which /dev/urandom is not.
>
> And neither is the non-conforming rand() on OpenBSD.
>
> The rand(1) man page on OpenBSD 7.8 says:
>
> Standards insist that this interface return deterministic
> results. Unsafe usage is very common, so OpenBSD changed the
> subsystem to return non-deterministic results by default.
>
> To satisfy portable code, srand() may be called to initialize
> the subsystem. In OpenBSD the seed variable is ignored,
> and strong random number results will be provided from
> arc4random(3). In other systems, the seed variable primes a
> simplistic deterministic algorithm.
>
> It does provide an srand_deterministic() function that behaves the way
> srand() is supposed to.
So then clang would use:
#ifdef __OpenBSD__
srand_deterministic(seed);
#else
srand(seed);
#endif
But I don't know (yet) that gcc does as well under OpenBSD.
--
:wq
Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-08 14:44 -0800 |
| Message-ID | <87344fhghg.fsf@example.invalid> |
| In reply to | #396299 |
Michael Sanders <porkchop@invalid.foo> writes:
> On Wed, 07 Jan 2026 13:54:21 -0800, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
>>> Apples and oranges. Many applications that use random numbers
>>> need a stream of numbers that is deterministic and reproducible,
>>> which /dev/urandom is not.
>>
>> And neither is the non-conforming rand() on OpenBSD.
>>
>> The rand(1) man page on OpenBSD 7.8 says:
>>
>> Standards insist that this interface return deterministic
>> results. Unsafe usage is very common, so OpenBSD changed the
>> subsystem to return non-deterministic results by default.
>>
>> To satisfy portable code, srand() may be called to initialize
>> the subsystem. In OpenBSD the seed variable is ignored,
>> and strong random number results will be provided from
>> arc4random(3). In other systems, the seed variable primes a
>> simplistic deterministic algorithm.
>>
>> It does provide an srand_deterministic() function that behaves the way
>> srand() is supposed to.
>
> So then clang would use:
>
> #ifdef __OpenBSD__
> srand_deterministic(seed);
> #else
> srand(seed);
> #endif
>
> But I don't know (yet) that gcc does as well under OpenBSD.
I don't know what you mean when you say that clang "would use"
that code.
I'm not aware that either clang or gcc uses random numbers
internally. I don't know why they would.
You could certainly write the above code and compile it with either
gcc or clang (or any other C compiler on OpenBSD). I've confirmed
that gcc on OpenBSD does predefine the symbol __OpenBSD__. There
should be no relevant difference between gcc and clang; random
number generation is implemented in the library, not in the compiler.
If your point is that a programmer using either gcc or clang could
use the above code to get the required deterministic behavior
for rand(), I agree. (Though it shouldn't be necessary; IMHO the
OpenBSD folks made a very bad decision.)
Relatedly, the NetBSD implementation of rand() is conforming, but
of very low quality. The low-order bit alternates between 0 and
1 on successive rand() calls, the two low-order bits repeat with
a cycle of 4, and so on. Larry Jones wrote about it here in 2010:
The even/odd problem was caused at Berkeley by a well meaning
but clueless individual who increased the range of the generator
(which originally matched the sample implementation) by returning
the *entire* internal state rather than just the high-order
bits of it. BSD was very popular, so that defective generator
got around a lot, unfortunately.
And I've just discovered that the OpenBSD rand() returns alternating
odd and even results after a call to srand_determinstic().
It's disturbing that this has never been fixed.
--
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 | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-09 06:06 +0000 |
| Message-ID | <10jq5u1$23nps$1@dont-email.me> |
| In reply to | #396310 |
On Thu, 08 Jan 2026 14:44:27 -0800, Keith Thompson wrote: > Michael Sanders <porkchop@invalid.foo> writes: >> On Wed, 07 Jan 2026 13:54:21 -0800, Keith Thompson wrote: >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > [...] >>>> Apples and oranges. Many applications that use random numbers >>>> need a stream of numbers that is deterministic and reproducible, >>>> which /dev/urandom is not. >>> >>> And neither is the non-conforming rand() on OpenBSD. >>> >>> The rand(1) man page on OpenBSD 7.8 says: >>> >>> Standards insist that this interface return deterministic >>> results. Unsafe usage is very common, so OpenBSD changed the >>> subsystem to return non-deterministic results by default. >>> >>> To satisfy portable code, srand() may be called to initialize >>> the subsystem. In OpenBSD the seed variable is ignored, >>> and strong random number results will be provided from >>> arc4random(3). In other systems, the seed variable primes a >>> simplistic deterministic algorithm. >>> >>> It does provide an srand_deterministic() function that behaves the way >>> srand() is supposed to. >> >> So then clang would use: >> >> #ifdef __OpenBSD__ >> srand_deterministic(seed); >> #else >> srand(seed); >> #endif >> >> But I don't know (yet) that gcc does as well under OpenBSD. > > I don't know what you mean when you say that clang "would use" > that code. > > I'm not aware that either clang or gcc uses random numbers > internally. I don't know why they would. Well, I meant the macro itself is (I'm guessing) probably defined by clang since its the default compiler. > You could certainly write the above code and compile it with either > gcc or clang (or any other C compiler on OpenBSD). I've confirmed > that gcc on OpenBSD does predefine the symbol __OpenBSD__. There > should be no relevant difference between gcc and clang; random > number generation is implemented in the library, not in the compiler. This is the info I'm, wondering about: both clang & gcc predefine the symbol. > If your point is that a programmer using either gcc or clang could > use the above code to get the required deterministic behavior > for rand(), I agree. (Though it shouldn't be necessary; IMHO the > OpenBSD folks made a very bad decision.) > > Relatedly, the NetBSD implementation of rand() is conforming, but > of very low quality. The low-order bit alternates between 0 and > 1 on successive rand() calls, the two low-order bits repeat with > a cycle of 4, and so on. Larry Jones wrote about it here in 2010: > > The even/odd problem was caused at Berkeley by a well meaning > but clueless individual who increased the range of the generator > (which originally matched the sample implementation) by returning > the *entire* internal state rather than just the high-order > bits of it. BSD was very popular, so that defective generator > got around a lot, unfortunately. > > And I've just discovered that the OpenBSD rand() returns alternating > odd and even results after a call to srand_determinstic(). > > It's disturbing that this has never been fixed. Yikes! Thanks Keith. This is sort of odd for OpenBSD. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-08 22:46 -0800 |
| Message-ID | <87tswvnuzx.fsf@example.invalid> |
| In reply to | #396314 |
Michael Sanders <porkchop@invalid.foo> writes:
> On Thu, 08 Jan 2026 14:44:27 -0800, Keith Thompson wrote:
>> Michael Sanders <porkchop@invalid.foo> writes:
[...]
>>> So then clang would use:
>>>
>>> #ifdef __OpenBSD__
>>> srand_deterministic(seed);
>>> #else
>>> srand(seed);
>>> #endif
>>>
>>> But I don't know (yet) that gcc does as well under OpenBSD.
>>
>> I don't know what you mean when you say that clang "would use"
>> that code.
>>
>> I'm not aware that either clang or gcc uses random numbers
>> internally. I don't know why they would.
>
> Well, I meant the macro itself is (I'm guessing) probably defined
> by clang since its the default compiler.
You mean the macro __OpenBSD__? Yes, that and other similar macros
are predefined by the compiler, which is configured for each OS.
gcc on OpenBSD also predefines it. (I don't know whether it's
predefined by the preprocessor directly or by some header that's
included implicitly. That doesn't really matter.) Compilers on
other platforms will not predefine __OpenBSD__.
But your original statement implied that clang would *use* that
particular piece of code, which didn't make much sense. Were you
just asking about how the __OpenBSD__ macro is defined, without
reference to srand?
[...]
--
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 | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-09 22:38 +0000 |
| Message-ID | <10js023$2nrdh$1@dont-email.me> |
| In reply to | #396315 |
On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote:
> But your original statement implied that clang would *use* that
> particular piece of code, which didn't make much sense. Were you
> just asking about how the __OpenBSD__ macro is defined, without
> reference to srand?
Well, under OpenBSD I plan on using:
#ifdef __OpenBSD__
srand_deterministic(seed);
#else
srand(seed);
#endif
But what I was asking is whether or not gcc would recognize
the __OpenBSD__ macro (why wouldn't I'm assuming) since clang
is the default compiler.
But also about srand()... you've got me really wondering why
OpenBSD would deviate from the standard as they have. I get
that the those folks disagree because its deterministic, but
its the accepted standard to be deterministic with srand().
Only speaking for myself here, rather than srand_deterministic()
and srand() (that's not deterministic under OpenBSD) it
would've made more sense to've implemented srand_non_deterministic()
and left srand() alone. That design decision on their part only
muddies the waters in my thinking. Live & learn =)
--
:wq
Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-01-09 23:27 +0000 |
| Message-ID | <n9g8R.1555881$hd86.484241@fx13.iad> |
| In reply to | #396329 |
Michael Sanders <porkchop@invalid.foo> writes: >On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote: > >> But your original statement implied that clang would *use* that >> particular piece of code, which didn't make much sense. Were you >> just asking about how the __OpenBSD__ macro is defined, without >> reference to srand? > >Well, under OpenBSD I plan on using: > >#ifdef __OpenBSD__ > srand_deterministic(seed); >#else > srand(seed); >#endif > >But what I was asking is whether or not gcc would recognize >the __OpenBSD__ macro (why wouldn't I'm assuming) since clang >is the default compiler. $ gcc -dM -E - < /dev/null will show all the preprocessor macros predefined by the compiler. There 397 predefined macros on my Fedora gcc 14 installation. Note that other macros may be defined in header files. > >But also about srand()... you've got me really wondering why >OpenBSD would deviate from the standard as they have. I get >that the those folks disagree because its deterministic, but >its the accepted standard to be deterministic with srand(). I expect they were primary concerned with the security implications of a deterministic algorithm. > >Only speaking for myself here, rather than srand_deterministic() >and srand() (that's not deterministic under OpenBSD) it >would've made more sense to've implemented srand_non_deterministic() >and left srand() alone. That design decision on their part only >muddies the waters in my thinking. Live & learn =) I'm sure they wanted the change to apply by default to existing applications (many of them likely distributed with various BSD releases).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-01-09 17:09 -0800 |
| Message-ID | <87ms2m2rz8.fsf@example.invalid> |
| In reply to | #396329 |
Michael Sanders <porkchop@invalid.foo> writes:
> On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote:
>> But your original statement implied that clang would *use* that
>> particular piece of code, which didn't make much sense. Were you
>> just asking about how the __OpenBSD__ macro is defined, without
>> reference to srand?
>
> Well, under OpenBSD I plan on using:
>
> #ifdef __OpenBSD__
> srand_deterministic(seed);
> #else
> srand(seed);
> #endif
>
> But what I was asking is whether or not gcc would recognize
> the __OpenBSD__ macro (why wouldn't I'm assuming) since clang
> is the default compiler.
OK.
Do you understand that your original question was unclear?
You said that "clang would use" the quoted 5-line code snippet,
and asked whether "gcc does as well". It's not clang or gcc that
would use that code. It would be used by a programmer writing code
to be compiled with clang or gcc.
I understand now what you meant. I'd like to be sure that you
understand the problem with the question as you originally wrote it.
I have clang 19.1.7 and gcc 13.2.0 installed on OpenBSD 7.8, and
both predefine the macro __OpenBSD__.
> But also about srand()... you've got me really wondering why
> OpenBSD would deviate from the standard as they have. I get
> that the those folks disagree because its deterministic, but
> its the accepted standard to be deterministic with srand().
>
> Only speaking for myself here, rather than srand_deterministic()
> and srand() (that's not deterministic under OpenBSD) it
> would've made more sense to've implemented srand_non_deterministic()
> and left srand() alone. That design decision on their part only
> muddies the waters in my thinking. Live & learn =)
I don't know why they made that decision. It was clearly deliberate.
I agree that adding an srand_non_deterministic() function would
have been better.
--
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 | Kaz Kylheku <046-301-5902@kylheku.com> |
|---|---|
| Date | 2026-01-10 19:44 +0000 |
| Message-ID | <20260110112849.954@kylheku.com> |
| In reply to | #396329 |
On 2026-01-09, Michael Sanders <porkchop@invalid.foo> wrote: > On Thu, 08 Jan 2026 22:46:42 -0800, Keith Thompson wrote: > >> But your original statement implied that clang would *use* that >> particular piece of code, which didn't make much sense. Were you >> just asking about how the __OpenBSD__ macro is defined, without >> reference to srand? > > Well, under OpenBSD I plan on using: > > #ifdef __OpenBSD__ > srand_deterministic(seed); > #else > srand(seed); > #endif This is is better // In some common configuration header: #ifdef __OpenBSD__ #define HAVE_SRAND_DETERMINISTIC 1 #define HAVE_... /* other such macros */ #endif (Or the configuration can be generated by scripts which detect features in environment.) Then in the code: #if HAVE_SRAND_DETERMINISTIC srand_deterministic(seed); #else srand(seed); #endif If a platform other than __OpenBSD__ comes along which has srand_deterministic you just make sure HAVE_SRAND_DETERMINISTIC 1 is turned on; you don't have to edit the code where that is used. This idea is seen in the configuration of GNU programs and such. There is a "GDB Internals" document which discusses it in a section called "Clean Design" Partial quote: New #ifdef’s which test for specific compilers or manufacturers or operating systems are unacceptable. All #ifdef’s should test for features. The information about which configurations contain which features should be segregated into the configuration files. Experience has proven far too often that a feature unique to one particular system often creeps into other systems; and that a conditional based on some predefined macro for your current system will become worthless over time, as new versions of your system come out that behave differently with regard to this feature. [ ... more discussion ... ] https://www.sourceware.org/gdb/5/onlinedocs/gdbint.pdf I think the GNU Coding Standards document may have had a similar discussion; I don't see it in the current version though. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-01-09 00:36 -0800 |
| Message-ID | <86qzrzmbcq.fsf@linuxsc.com> |
| In reply to | #396283 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> John McCue <jmclnx@gmail.com.invalid> writes: >> >>> Michael Sanders <porkchop@invalid.foo> wrote: >>> >>>> Is it incorrect to use 0 (zero) to seed srand()? >>>> >>>> int seed = (argc >= 2 && strlen(argv[1]) == 9) >>>> ? atoi(argv[1]) >>>> : (int)(time(NULL) % 900000000 + 100000000); >>>> >>>> srand(seed); >>> >>> I like to just read /dev/urandom when I need a random >>> number. Seem easier and more portable across Linux & >>> the *BSDs. >>> >>> int s; >>> read(fd, &s, sizeof(int)); >> >> Apples and oranges. Many applications that use random numbers >> need a stream of numbers that is deterministic and reproducible, >> which /dev/urandom is not. > > And neither is the non-conforming rand() on OpenBSD. > > The rand(1) man page on OpenBSD 7.8 says: > > Standards insist that this interface return deterministic > results. Unsafe usage is very common, so OpenBSD changed the > subsystem to return non-deterministic results by default. > > To satisfy portable code, srand() may be called to initialize > the subsystem. In OpenBSD the seed variable is ignored, > and strong random number results will be provided from > arc4random(3). In other systems, the seed variable primes a > simplistic deterministic algorithm. Apparently the OpenBSD folks have seen fit to remove the only desirable property that ISO C actually specifies for the standard library random number generator. Bravo!
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-12-23 11:04 +0100 |
| Message-ID | <10idpcr$68km$2@raubtier-asyl.eternal-september.org> |
| In reply to | #395879 |
Am 22.12.2025 um 09:48 schrieb Michael Sanders: > Is it incorrect to use 0 (zero) to seed srand()? > > int seed = (argc >= 2 && strlen(argv[1]) == 9) > ? atoi(argv[1]) > : (int)(time(NULL) % 900000000 + 100000000); > > srand(seed); > Use mt19993_64 ! ;-)
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web