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 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-26 15:12 -0600 |
| Message-ID | <10imtoh$2u2k7$2@dont-email.me> |
| In reply to | #395986 |
On 12/26/2025 2:48 PM, BGB wrote: > > Though one possibility could be to increase the strength of stack- > canaries by flagging them with relocs, allowing the program loader to > itself re-jitter the canary values without needing a recompile. > > > Well, and GCC compiled code has an additional weakness here in that GCC > doesn't normally use stack canaries (they seemingly do very little to > give binaries any kind of resistance against buffer overflow exploits). > Groan... Self clarification: GCC does have an option to enable stack canaries, but it is opt-in rather than enabled by default (say, in MSVC one would need to opt-out instead). What I wrote could be misinterpreted, I meant GCC's default settings do little in the case of protecting against stack overflows (and was *not* implying that canaries were ineffective). But, alas, now people will probably be misinterpreting what I wrote and now I will need to deal with this, grr...
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2025-12-23 06:49 +0000 |
| Message-ID | <slrn10kkeri.l3s.ike@iceland.freeshell.org> |
| In reply to | #395895 |
On 2025-12-23, John McCue <jmclnx@gmail.com.invalid> wrote: > 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)); srand takes an unsigned argument. unsigned s; read(fd, &s, sizeof s);
[toc] | [prev] | [next] | [standalone]
| From | John McCue <jmclnx@gmail.com.invalid> |
|---|---|
| Date | 2025-12-23 20:37 +0000 |
| Message-ID | <10ieuim$i2p9$1@dont-email.me> |
| In reply to | #395897 |
Ike Naar <ike@sdf.org> wrote:
> On 2025-12-23, John McCue <jmclnx@gmail.com.invalid> wrote:
>> 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));
>
> srand takes an unsigned argument.
>
> unsigned s;
> read(fd, &s, sizeof s);
I am not quite sure what you are saying about srand(3).
If you decide to read /dev/urandom, there is no need to
call srand(3), the OS maintains random data itself. So
read(2) will just return the random number of the type
you want based upon the call.
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sdf.org> |
|---|---|
| Date | 2025-12-24 15:22 +0000 |
| Message-ID | <slrn10ko1a7.83t.ike@iceland.freeshell.org> |
| In reply to | #395918 |
On 2025-12-23, John McCue <jmclnx@gmail.com.invalid> wrote: > Ike Naar <ike@sdf.org> wrote: >> On 2025-12-23, John McCue <jmclnx@gmail.com.invalid> wrote: >>> 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)); >> >> srand takes an unsigned argument. >> >> unsigned s; >> read(fd, &s, sizeof s); > > I am not quite sure what you are saying about srand(3). > > If you decide to read /dev/urandom, there is no need to > call srand(3), the OS maintains random data itself. So > read(2) will just return the random number of the type > you want based upon the call. Sorry, my misunderstanding. I thought you wanted to use a random number (from /dev/urandom instead of time(NULL)) to seed srand().
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 07:25 +0000 |
| Message-ID | <10idg5m$3k87$3@dont-email.me> |
| In reply to | #395895 |
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... -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-24 06:16 +0000 |
| Message-ID | <10ig0gj$qjm9$2@dont-email.me> |
| In reply to | #395900 |
On Tue, 23 Dec 2025 07:25:42 -0000 (UTC), Michael Sanders wrote: > Wish there was such a 'device' under Windows... You should get one if you install WSL2.
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-24 15:21 +0000 |
| Message-ID | <10ih0d7$13hnn$1@dont-email.me> |
| In reply to | #395929 |
On Wed, 24 Dec 2025 06:16:51 -0000 (UTC), Lawrence D’Oliveiro wrote: >> Wish there was such a 'device' under Windows... > > You should get one if you install WSL2. To be fair there is the 'Windows entropy pool' & its non-deterministic too but its only available via API. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-24 19:00 +0000 |
| Message-ID | <10ihd8g$1aaqu$3@dont-email.me> |
| In reply to | #395942 |
On Wed, 24 Dec 2025 15:21:11 -0000 (UTC), Michael Sanders wrote: > On Wed, 24 Dec 2025 06:16:51 -0000 (UTC), Lawrence D’Oliveiro wrote: > >>> Wish there was such a 'device' under Windows... >> >> You should get one if you install WSL2. > > To be fair there is the 'Windows entropy pool' & its > non-deterministic too but its only available via API. You begin to see why Microsoft is supporting Linux more and more.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-25 03:07 -0600 |
| Message-ID | <10iiurn$1ntgo$1@dont-email.me> |
| In reply to | #395957 |
On 12/24/2025 1:00 PM, Lawrence D’Oliveiro wrote:
> On Wed, 24 Dec 2025 15:21:11 -0000 (UTC), Michael Sanders wrote:
>
>> On Wed, 24 Dec 2025 06:16:51 -0000 (UTC), Lawrence D’Oliveiro wrote:
>>
>>>> Wish there was such a 'device' under Windows...
>>>
>>> You should get one if you install WSL2.
>>
>> To be fair there is the 'Windows entropy pool' & its
>> non-deterministic too but its only available via API.
>
> You begin to see why Microsoft is supporting Linux more and more.
Usual strategy IME is usually to save a file or similar with RNG state
for a big RNG hidden inside somewhere, and then the program loads the
file, goes through an "entropy mining" step, and then either immediately
or eventually saves the file again.
This approach is generally portable.
In some other types of programs, the RNG state is hidden inside some
other type of data that tends to be saved and reloaded (such as the
player state in a 3D engine).
One entropy-mining process is to use "clock()" or similar and then spin
in a loop for a certain amount of time effectively building a hash of
the values returned by clock. The exact timing when the values change
will tend to carry a certain amount of entropy.
Say, for example:
t0=clock();
t0e=t0+(0.1*CLOCKS_PER_SEC); //usually not too obnoxious.
t1=t0;
seed1=1; seed2=1;
while(t1<t0e)
{ t1=clock(); seed1+=t1; seed2+=seed1; }
seed1+=((uint32_t)seed1)+(seed1>>32);
seed2+=((uint32_t)seed2)+(seed2>>32);
seed=seed1^seed2;
This can be combined with the saved/restored RNG state.
This entropy-mining approach seems to work reasonably well despite its
limitations (will typically give a unique value each run).
granted, doesn't work if the system as a whole is sufficiently
deterministic (doesn't really work on microcontrollers or similar).
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-25 19:31 +0000 |
| Message-ID | <10ik3ee$241nk$1@dont-email.me> |
| In reply to | #395969 |
On Thu, 25 Dec 2025 03:07:03 -0600, BGB wrote: > One entropy-mining process is to use "clock()" or similar and then > spin in a loop for a certain amount of time effectively building a > hash of the values returned by clock. The exact timing when the > values change will tend to carry a certain amount of entropy. The turbulence of the air/gas inside disk drives is apparently a good source of randomness.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-25 21:14 +0100 |
| Message-ID | <10ik5u8$25ihh$7@dont-email.me> |
| In reply to | #395972 |
On 2025-12-25 20:31, Lawrence D’Oliveiro wrote: > > The turbulence of the air/gas inside disk drives is apparently a good > source of randomness. $ ln /dev/sda /dev/rnd # ;-) Too bad that I recently switched to SSDs. :-/ Janis
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-25 15:29 -0600 |
| Message-ID | <10ikacr$26oas$1@dont-email.me> |
| In reply to | #395972 |
On 12/25/2025 1:31 PM, Lawrence D’Oliveiro wrote:
> On Thu, 25 Dec 2025 03:07:03 -0600, BGB wrote:
>
>> One entropy-mining process is to use "clock()" or similar and then
>> spin in a loop for a certain amount of time effectively building a
>> hash of the values returned by clock. The exact timing when the
>> values change will tend to carry a certain amount of entropy.
>
> The turbulence of the air/gas inside disk drives is apparently a good
> source of randomness.
Yeah, but one doesn't easily have access to this information.
Likewise to access from the low order bits of CPU thermometers or
similar, etc.
For some of my targets, there is also no HDD (typically, everything runs
off of SD cards).
FWIW, in my own CPU design, there is actually a hardware RNG where
internal signals are basically gathered up and fed around the bus in a
special noise channel and used to continuously feed into a hardware RNG
for which a value can be read with a special CPU instruction.
But, alas, mainline CPUs lack such a feature.
On x86, it is also possible to get some level of entropy from mining
RDTSC, but this is non-portable.
But, yeah, tested out a few more RNG designs, and ATM:
seed1 ^= ~(seed2>>47); seed2 ^= ~(seed1>>43); // 4 cycles
seed1 ^= (seed1<<13); seed2 ^= (seed2>>11); // 4 cycles
seed1 ^= (seed1>>19); seed2 ^= (seed2<<17); // 4 cycles
val = ((seed1 ^ seed2) >> 32) & 0x7FFF; // 6 cycles
Seems to be working pretty OK (decent randomness), and is moderately fast.
Add cost of +4 cycles for LD (2c penalty), +2 ST
Est cost: Around 24 clock cycles.
Though, breaking up the shifts and xors using temporaries could be used
to micro-optimize it a little more (vs trying to rely on compile-time
instruction shuffling).
Downside as that this particular approach (XOR'ing values with
themselves and modifying the original variable before the next step),
creates a lot of dependencies which limits the potential ILP (can't get
ILP over 2 in this case).
Where, the interleaved "seed1 = (seed1<<SH1) ^ (seed1>>SH2);" pattern
allows for slightly higher ILP, but seemingly gets less randomness per
shift (so the total dependency length ends up similar).
In the CPU in question, would effectively need 4 seed values to get
better ILP, say:
seed1 ^= ~(seed2>>47); seed2 ^= ~(seed3>>43);
seed3 ^= ~(seed4>>53); seed4 ^= ~(seed1>>41);
// ~ 4 cycles
seed1 ^= (seed1<<13); seed2 ^= (seed2>>11);
seed3 ^= (seed3<< 7); seed4 ^= (seed4>> 5);
seed1 ^= (seed1>>19); seed2 ^= (seed2<<17);
seed3 ^= (seed3>>23); seed4 ^= (seed4<<29);
// ~ 6 cycles
val = ((seed1 ^ seed2) >> 32) & 0x7FFF; // 6 cycles
//+ 8 cycles (Global LD/ST)
Est Cost: Around 24 clock cycles.
(24 cycle estimate assuming compiler shuffles instructions into a
roughly optimal order).
Though, with more operations still likely to be slower, despite the
higher ILP potential (the higher ILP would merely reduce the slowdown
from having more operations).
In this case, ideally one wants to be able to have groups of 6
non-dependent ALU operations on a 3-wide CPU with 2-cycle ALU latency.
Though, in this case, achieving peak ILP would actually require ~ 6 or 8
seed registers. Though, in this case, would require using XG3, for
RISC-V it would also suffer due to RV64 only having 32 GPRs rather than
64, so trying to use 8 seeds in parallel would run out of GPRs on RISC-V
(don't want to spill, this will hurt a lot worse than the lost ILP).
Where, if ILP is maximized, one can get to around 0.3 clock cycles per
operation.
But, on the target in question, 2 or 4 seeds is still likely to be
considerably faster than, say:
seed = seed * 0x0000FC4BA2F7ACABULL + 1;
Which suffers from the "great evil" known as "slow 64-bit multiply"
(needs 68 cycles to do a 64-bit multiply, similar to performing a divide).
Where, the cost of the 64-bit integer multiply will stomp all over the
cycle cost of the former (well, and not like "rand()" tends to be used
all that heavily in any case).
Well, contrast to the naive lookup-table approach:
index=(index+1)&255; //latency = 8 cycles (3 LD, 2 ADD, 2 AND, 1 ST)
val=table[index]; //latency = 5 cycles (2 ADD, 3 LD).
So: ~ 13 cycles of latency.
So, looks simple, but not great in this case (both weak, and latency
isn't great for its weakness).
Then again:
seed = seed * 0x0000FC4BA2F7ACABULL + 1;
//75 cycles: 3 LD, 1 const, 68 MUL, 2 ADD, 1 ST
ret = (myseed >> 48) & 0x7FFF; //4 cycles: 2 SHR, 2 AND
Cost: Around 80 cycles.
...
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-25 23:25 -0500 |
| Message-ID | <10il2o6$2cu9b$1@dont-email.me> |
| In reply to | #395974 |
On Thu, 12/25/2025 4:29 PM, BGB wrote: > On 12/25/2025 1:31 PM, Lawrence D’Oliveiro wrote: >> On Thu, 25 Dec 2025 03:07:03 -0600, BGB wrote: >> >>> One entropy-mining process is to use "clock()" or similar and then >>> spin in a loop for a certain amount of time effectively building a >>> hash of the values returned by clock. The exact timing when the >>> values change will tend to carry a certain amount of entropy. >> >> The turbulence of the air/gas inside disk drives is apparently a good >> source of randomness. > > Yeah, but one doesn't easily have access to this information. > Likewise to access from the low order bits of CPU thermometers or similar, etc. > > For some of my targets, there is also no HDD (typically, everything runs off of SD cards). > > > FWIW, in my own CPU design, there is actually a hardware RNG where internal signals are basically gathered up and fed around the bus in a special noise channel and used to continuously feed into a hardware RNG for which a value can be read with a special CPU instruction. > > But, alas, mainline CPUs lack such a feature. How have you concluded such a thing ? My CPU happens to have a random number generator running at 500MB/sec. And it works on the same principle as other RNGs. It uses one physical process for entropy, and it uses a pseudo random number generator for the at-speed part (the 500MB/sec). On mine, there are 16 ring oscillators, with one ring oscillator having three inverters in a ring. The slowest oscillator has 59 inverters in a row. (The number of inverters must be an odd number, in order to ensure the oscillators start OK.) A sampling circuit samples all sixteen RO and creates a 16 bit number. The 16 bit number is a "seed" to the pseudo random number generator. Keywords like: "RDRAND, RDSEED" https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/amd-random-number-generator.pdf There are other implementations. Intel has more than one method for doing this, historically. https://www.electronicdesign.com/resources/article/21796238/understanding-intels-ivy-bridge-random-number-generator The Linux people happen not to like those, but, they exist anyway, chugging away. And completely unrelated. https://www.2uo.de/myths-about-urandom/ Paul
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-25 23:41 -0600 |
| Message-ID | <10il75o$2du47$1@dont-email.me> |
| In reply to | #395976 |
On 12/25/2025 10:25 PM, Paul wrote:
> On Thu, 12/25/2025 4:29 PM, BGB wrote:
>> On 12/25/2025 1:31 PM, Lawrence D’Oliveiro wrote:
>>> On Thu, 25 Dec 2025 03:07:03 -0600, BGB wrote:
>>>
>>>> One entropy-mining process is to use "clock()" or similar and then
>>>> spin in a loop for a certain amount of time effectively building a
>>>> hash of the values returned by clock. The exact timing when the
>>>> values change will tend to carry a certain amount of entropy.
>>>
>>> The turbulence of the air/gas inside disk drives is apparently a good
>>> source of randomness.
>>
>> Yeah, but one doesn't easily have access to this information.
>> Likewise to access from the low order bits of CPU thermometers or similar, etc.
>>
>> For some of my targets, there is also no HDD (typically, everything runs off of SD cards).
>>
>>
>> FWIW, in my own CPU design, there is actually a hardware RNG where internal signals are basically gathered up and fed around the bus in a special noise channel and used to continuously feed into a hardware RNG for which a value can be read with a special CPU instruction.
>>
>> But, alas, mainline CPUs lack such a feature.
>
> How have you concluded such a thing ?
>
> My CPU happens to have a random number generator running at 500MB/sec.
>
> And it works on the same principle as other RNGs. It uses one physical
> process for entropy, and it uses a pseudo random number generator for
> the at-speed part (the 500MB/sec).
>
> On mine, there are 16 ring oscillators, with one ring oscillator
> having three inverters in a ring. The slowest oscillator has 59 inverters
> in a row. (The number of inverters must be an odd number, in order
> to ensure the oscillators start OK.) A sampling circuit samples all
> sixteen RO and creates a 16 bit number. The 16 bit number is a "seed" to
> the pseudo random number generator.
>
> Keywords like: "RDRAND, RDSEED"
>
> https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/white-papers/amd-random-number-generator.pdf
>
> There are other implementations. Intel has more than one method for doing this, historically.
>
> https://www.electronicdesign.com/resources/article/21796238/understanding-intels-ivy-bridge-random-number-generator
>
> The Linux people happen not to like those, but, they exist anyway, chugging away.
>
> And completely unrelated.
>
> https://www.2uo.de/myths-about-urandom/
>
OK.
I hadn't heard about it; seems my PC's CPU is just barely new enough to
support it (apparently with a timing of around 1300 cycles per RDRAND on
the Zen+).
Would theoretically give around 2.85 million RNG's per second.
Though, either way, relying on it wouldn't be particularly portable
(would need something x86+compiler+CPU specific). Could maybe make sense
for seeding a PRNG though if target-specific code is OK in this sense.
Quick check:
One of the RNG's algos mentioned previously runs at roughly 300 million
RNGs in one second.
One of the slightly faster designs pulls off around 800 million RNGs in
one second.
...
Though, one can maybe divide RNGs into categories:
Needs to be true random;
Pseudorandom is OK, but it doesn't matter;
Needs to be deterministic.
RNG only provides appearance of randomness,
but said randomness needs to play out the same for each run.
It is not "one size fits all" in this case...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-26 05:42 +0000 |
| Message-ID | <10il77q$2dsmo$1@dont-email.me> |
| In reply to | #395976 |
On Thu, 25 Dec 2025 23:25:39 -0500, Paul wrote: > My CPU happens to have a random number generator running at > 500MB/sec. > > ... > > The Linux people happen not to like those, but, they exist anyway, > chugging away. Because it’s difficult to see how you can trust them. Not without thoroughly mashing them through something like this <https://en.wikipedia.org/wiki/Fortuna_(PRNG)>, anyway.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-26 01:52 -0500 |
| Message-ID | <10ilbb1$2eri7$1@dont-email.me> |
| In reply to | #395978 |
On Fri, 12/26/2025 12:42 AM, Lawrence D’Oliveiro wrote: > On Thu, 25 Dec 2025 23:25:39 -0500, Paul wrote: > >> My CPU happens to have a random number generator running at >> 500MB/sec. >> >> ... >> >> The Linux people happen not to like those, but, they exist anyway, >> chugging away. > > Because it’s difficult to see how you can trust them. > > Not without thoroughly mashing them through something like this > <https://en.wikipedia.org/wiki/Fortuna_(PRNG)>, anyway. > The claim was, that x86 processors didn't have anything. They do have something. And it has a source of entropy to do re-seed with. Not all the Intel ones have the same arch. And they're good enough for a "guess-a-number" game in C. If you want a conventional "repeatable-upon-request" sequence, then a regular PRNG can be used, and you can just make your own if you're bored. As long as it doesn't have zeros sensitivity (gets "stuck" in the all zeros state). A general rule of thumb, is "quality random numbers take time". Based on that, the 500MB/sec output I got from my processor, I wouldn't be using that for any serious purpose, without further study. I just thought it amusing that such a firehose existed on the processor, not that such a rate was safe to use. Paul
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-26 07:56 +0000 |
| Message-ID | <10ilf4a$2fn32$1@dont-email.me> |
| In reply to | #395979 |
On Fri, 26 Dec 2025 01:52:15 -0500, Paul wrote: > On Fri, 12/26/2025 12:42 AM, Lawrence D’Oliveiro wrote: >> >> On Thu, 25 Dec 2025 23:25:39 -0500, Paul wrote: >> >>> My CPU happens to have a random number generator running at >>> 500MB/sec. >>> >>> ... >>> >>> The Linux people happen not to like those, but, they exist anyway, >>> chugging away. >> >> Because it’s difficult to see how you can trust them. >> >> Not without thoroughly mashing them through something like this >> <https://en.wikipedia.org/wiki/Fortuna_(PRNG)>, anyway. > > The claim was, that x86 processors didn't have anything. Not what I was responding to. I said nothing about such a claim, either way.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-26 04:48 -0600 |
| Message-ID | <10ilp5i$2jk2o$1@dont-email.me> |
| In reply to | #395980 |
On 12/26/2025 1:56 AM, Lawrence D’Oliveiro wrote: > On Fri, 26 Dec 2025 01:52:15 -0500, Paul wrote: > >> On Fri, 12/26/2025 12:42 AM, Lawrence D’Oliveiro wrote: >>> >>> On Thu, 25 Dec 2025 23:25:39 -0500, Paul wrote: >>> >>>> My CPU happens to have a random number generator running at >>>> 500MB/sec. >>>> >>>> ... >>>> >>>> The Linux people happen not to like those, but, they exist anyway, >>>> chugging away. >>> >>> Because it’s difficult to see how you can trust them. >>> >>> Not without thoroughly mashing them through something like this >>> <https://en.wikipedia.org/wiki/Fortuna_(PRNG)>, anyway. >> >> The claim was, that x86 processors didn't have anything. > > Not what I was responding to. I said nothing about such a claim, either > way. In my case, I was not aware of such a feature having been added, but I haven't really been keeping up with every new feature being added to x86 in recent years. Some years ago, I got sorta burned on AVX, as it wasn't until comparably recently that I got a CPU that could actually run it (I tend to build PCs with parts that are a few generations behind, to keep cost more reasonable). And, it wasn't until very recently (a few months ago) that I got something where using AVX didn't make things actively slower (my main PC can run AVX, technically, but doing so performs poorly). Much after AVX, I sorta lost motivation to keep up on newer additions to the ISA; as often it would be a painfully long time before I would actually be able to use it (and I still don't have any PC's with CPUs made in this decade). Well, and then it has started seeming like in a longer term sense, x86 may be doomed. Granted, its end has been predicted for a long time, though its main threat may be in part the end of Moore's law, which in a mostly steady-state it is likely that performance per area and performance per watt will become the dominant factors, and conventional x86 processors haven't been great on either front here (combined with a longer term timeframe making JIT compilation and eventually abandonment the more likely endgame). Well, and after Moore's law hits its limit, it may backslide slightly as things settle on whichever process node is most economical in a perf/$ sense. Though, this is unlikely to happen quickly (more likely over a period of decades). Well, and then there are more near-term things, like the mess of things the whole "AI" thing is creating, and MS repeatedly shooting itself in the foot (maybe not enough to dethrone themselves, but they are pushing it). ...
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-24 10:51 +0200 |
| Message-ID | <20251224105114.0000714b@yahoo.com> |
| In reply to | #395900 |
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
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2025-12-24 00:59 -0800 |
| Message-ID | <10iga15$t087$1@dont-email.me> |
| In reply to | #395933 |
On 12/24/2025 12:51 AM, 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 > > CSPRNG, vs an actual TRNG?
[toc] | [prev] | [next] | [standalone]
Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web