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 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 07:24 +0000 |
| Message-ID | <10idg3i$3k87$2@dont-email.me> |
| In reply to | #395882 |
On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote: > There's number sequence generators that produce 0 sequences if seeded > with 0. And maybe the comment in 'man 3 rand', "If no seed value is > provided, the rand() function is automatically seeded with a value > of 1.", may have fostered his doubt. Janis - naive question for you... How do I bring up *posix only* man pages using 3? I see no difference when invoking any of: man 3 srand or: man 3 posix srand or: man posix 3 srand What I'm doing wrong here? -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2025-12-23 09:59 +0100 |
| Message-ID | <10idllf$25ihi$6@dont-email.me> |
| In reply to | #395899 |
On 2025-12-23 08:24, Michael Sanders wrote:
> On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote:
>
>> There's number sequence generators that produce 0 sequences if seeded
>> with 0. And maybe the comment in 'man 3 rand', "If no seed value is
>> provided, the rand() function is automatically seeded with a value
>> of 1.", may have fostered his doubt.
>
> Janis - naive question for you...
>
> How do I bring up *posix only* man pages using 3?
Sorry, can't help you here. Maybe someone else can.
Myself I only access the Unix man pages as they come,
i.e. using either 'man entry' or 'man section entry'.
The POSIX information is usually textually integrated
in the man pages.
>
> I see no difference when invoking any of:
>
> man 3 srand
That's what I'm doing, and I see, for example,
...
HISTORY
rand()
srand()
SVr4, 4.3BSD, C89, POSIX.1-2001.
rand_r()
POSIX.1-2001. Obsolete in POSIX.1-2008.
...
Janis
> or: man 3 posix srand
> or: man posix 3 srand
>
> What I'm doing wrong here?
>
[toc] | [prev] | [next] | [standalone]
| From | Michael Bäuerle <michael.baeuerle@stz-e.de> |
|---|---|
| Date | 2025-12-23 11:09 +0100 |
| Message-ID | <AABpSmo+L7wAAAOf.A3.flnews@WStation5.stz-e.de> |
| In reply to | #395902 |
Janis Papanagnou wrote: > On 2025-12-23 08:24, Michael Sanders wrote: > > > > [...] > > How do I bring up *posix only* man pages using 3? > > Sorry, can't help you here. Maybe someone else can. Manual pages are for the implementation of the operating system. The current standard version can be viewed here: <https://pubs.opengroup.org/onlinepubs/9799919799/functions/srand.html> This is the older standard version, still containing rand_r(): <https://pubs.opengroup.org/onlinepubs/9699919799/functions/srand.html>
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 14:49 +0000 |
| Message-ID | <10iea5o$b8ho$3@dont-email.me> |
| In reply to | #395906 |
On Tue, 23 Dec 2025 11:09:02 +0100 (CET), Michael Bäuerle wrote: > Manual pages are for the implementation of the operating system. > > The current standard version can be viewed here: > <https://pubs.opengroup.org/onlinepubs/9799919799/functions/srand.html> > This is the older standard version, still containing rand_r(): > <https://pubs.opengroup.org/onlinepubs/9699919799/functions/srand.html> Thank you for the pointers, I appreciate your insight. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-12-23 16:13 +0000 |
| Message-ID | <ycz2R.198208$79B9.129561@fx14.iad> |
| In reply to | #395902 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 2025-12-23 08:24, Michael Sanders wrote: >> On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote: >> >>> There's number sequence generators that produce 0 sequences if seeded >>> with 0. And maybe the comment in 'man 3 rand', "If no seed value is >>> provided, the rand() function is automatically seeded with a value >>> of 1.", may have fostered his doubt. >> >> Janis - naive question for you... >> >> How do I bring up *posix only* man pages using 3? > >Sorry, can't help you here. Maybe someone else can. > >Myself I only access the Unix man pages as they come, >i.e. using either 'man entry' or 'man section entry'. >The POSIX information is usually textually integrated >in the man pages. > >> >> I see no difference when invoking any of: >> >> man 3 srand > >That's what I'm doing, and I see, for example, > >... >HISTORY > rand() > srand() > SVr4, 4.3BSD, C89, POSIX.1-2001. Those interfaces were originally documented in the SVID (System V Interface Definition). The third edition (1989) states: "The function rand() uses a multiplicative congruential random-number generator with a period 2^32 that returns successive psuedo-random numbers in the range 0 to 32767." In the FUTURE DIRECTIONS section, it notes: "The algorithms used in rand() and srand() are obsolete and will be replaced with algorithms providing better pseudo-random characteristics in a future issue". There was never a fourth edition.
[toc] | [prev] | [next] | [standalone]
| From | richard@cogsci.ed.ac.uk (Richard Tobin) |
|---|---|
| Date | 2025-12-23 19:05 +0000 |
| Message-ID | <10iep5o$15tqc$1@artemis.inf.ed.ac.uk> |
| In reply to | #395914 |
In article <ycz2R.198208$79B9.129561@fx14.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>HISTORY >> rand() >> srand() >> SVr4, 4.3BSD, C89, POSIX.1-2001. >Those interfaces were originally documented in the SVID >(System V Interface Definition). Not "originally". >The third edition (1989) states: > > "The function rand() uses a multiplicative congruential random-number > generator with a period 2^32 that returns successive psuedo-random > numbers in the range 0 to 32767." Unix 5th edition (page dated 1/15/73) says: Rand uses a multiplicative congruential random number generator to return successive pseudo-random numbers (in r0) in the range from 1 to 2^15-1. (In those days they documented the assembler interface as well.) The SVID r3 text is almost identical to 7th edition's (1979). >In the FUTURE DIRECTIONS section, it notes: > > "The algorithms used in rand() and srand() are obsolete and will > be replaced with algorithms providing better pseudo-random characteristics > in a future issue". > >There was never a fourth edition. There was, but it was post-Posix. Rather than having improved algorithms in [s]rand() it has "see also drand48". https://www.sco.com/developers/devspecs/vol1a.pdf -- Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-23 02:16 -0800 |
| Message-ID | <875x9xwliw.fsf@example.invalid> |
| In reply to | #395899 |
Michael Sanders <porkchop@invalid.foo> writes:
> On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote:
>> There's number sequence generators that produce 0 sequences if seeded
>> with 0. And maybe the comment in 'man 3 rand', "If no seed value is
>> provided, the rand() function is automatically seeded with a value
>> of 1.", may have fostered his doubt.
>
> Janis - naive question for you...
>
> How do I bring up *posix only* man pages using 3?
>
> I see no difference when invoking any of:
>
> man 3 srand
> or: man 3 posix srand
> or: man posix 3 srand
>
> What I'm doing wrong here?
On Debian, Ubuntu, and similar systems, you can install the
"manpages-posix" (section 1) and "manpages-posix-dev" (sections 3
and 7) packages. You can then view the POSIX man page for srand
by typing any of:
man 3posix srand
man -s 3posix srand
man srand.3posix
I'd expect similar packages to be available on (some) other systems.
--
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 | 2025-12-23 14:47 +0000 |
| Message-ID | <10iea2v$b8ho$2@dont-email.me> |
| In reply to | #395907 |
On Tue, 23 Dec 2025 02:16:39 -0800, Keith Thompson wrote: > On Debian, Ubuntu, and similar systems, you can install the > "manpages-posix" (section 1) and "manpages-posix-dev" (sections 3 > and 7) packages. You can then view the POSIX man page for srand > by typing any of: > > man 3posix srand > man -s 3posix srand > man srand.3posix > > I'd expect similar packages to be available on (some) other systems. Great! Thanks Keith, you sir are a walking encyclopedia. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-12-23 16:08 +0000 |
| Message-ID | <l8z2R.198207$79B9.87685@fx14.iad> |
| In reply to | #395899 |
Michael Sanders <porkchop@invalid.foo> writes: >On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote: > >> There's number sequence generators that produce 0 sequences if seeded >> with 0. And maybe the comment in 'man 3 rand', "If no seed value is >> provided, the rand() function is automatically seeded with a value >> of 1.", may have fostered his doubt. > >Janis - naive question for you... > >How do I bring up *posix only* man pages using 3? > >I see no difference when invoking any of: > >man 3 srand >or: man 3 posix srand >or: man posix 3 srand > >What I'm doing wrong here? You're looking in the wrong place. https://pubs.opengroup.org/onlinepubs/9799919799/ Select <System Interface> in the top left frame, select (3) in the subsequent bottom left frame and select the interface name in the bottom left frame. The manual page will be in the right frame. https://pubs.opengroup.org/onlinepubs/9799919799/functions/rand.html
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-24 15:44 +0000 |
| Message-ID | <10ih1p1$13hnn$4@dont-email.me> |
| In reply to | #395913 |
On Tue, 23 Dec 2025 16:08:49 GMT, Scott Lurndal wrote: > Michael Sanders <porkchop@invalid.foo> writes: >>On Mon, 22 Dec 2025 13:18:19 +0100, Janis Papanagnou wrote: >> >>> There's number sequence generators that produce 0 sequences if seeded >>> with 0. And maybe the comment in 'man 3 rand', "If no seed value is >>> provided, the rand() function is automatically seeded with a value >>> of 1.", may have fostered his doubt. >> >>Janis - naive question for you... >> >>How do I bring up *posix only* man pages using 3? >> >>I see no difference when invoking any of: >> >>man 3 srand >>or: man 3 posix srand >>or: man posix 3 srand >> >>What I'm doing wrong here? > > You're looking in the wrong place. > > https://pubs.opengroup.org/onlinepubs/9799919799/ > > Select <System Interface> in the top left frame, > select (3) in the subsequent bottom left frame and > select the interface name in the bottom left frame. The > manual page will be in the right frame. > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/rand.html Thank you Scott. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 07:17 +0000 |
| Message-ID | <10idflh$3k87$1@dont-email.me> |
| In reply to | #395881 |
On Mon, 22 Dec 2025 06:44:42 -0500, James Kuyper wrote:
> On 2025-12-22 03:48, Michael Sanders 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);
>
> No, why whould you think so?
Excuse my delayed reply James (net provider was down most of today).
Well, I guess I did not expect such large differences between
gcc & musl somehow (cant test with clang just yet). I understand the
sequence is deterministic & likely still some differences with musl,
yet I wrongly assumed it seems, the sequences would be the same...
#include <stdio.h>
#include <stdlib.h>
int main(void) {
srand(0);
printf("%d\n", rand());
return 0;
}
/*
$ gcc -O2 -o rnd rnd.c && ./rnd
1804289383
$ musl-gcc -static -O2 -o rnd rnd.c && ./rnd
2049033599
*/
--
:wq
Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-23 08:25 +0100 |
| Message-ID | <10idg67$3ohi$1@dont-email.me> |
| In reply to | #395898 |
On 23/12/2025 08:17, Michael Sanders wrote:
> On Mon, 22 Dec 2025 06:44:42 -0500, James Kuyper wrote:
>
>> On 2025-12-22 03:48, Michael Sanders 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);
>>
>> No, why whould you think so?
>
> Excuse my delayed reply James (net provider was down most of today).
>
> Well, I guess I did not expect such large differences between
> gcc & musl somehow (cant test with clang just yet). I understand the
> sequence is deterministic & likely still some differences with musl,
> yet I wrongly assumed it seems, the sequences would be the same...
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
> srand(0);
> printf("%d\n", rand());
> return 0;
> }
>
> /*
>
> $ gcc -O2 -o rnd rnd.c && ./rnd
> 1804289383
>
> $ musl-gcc -static -O2 -o rnd rnd.c && ./rnd
> 2049033599
>
> */
>
It is not the compilers that are different, it is the C standard
libraries that are different. gcc is a compiler, not a library, but you
are probably using glibc with it by default. musl is a library, not a
compiler. There is no reason to suppose that different C standard
libraries use the same implementation of rand()and srand(), so no reason
to suppose they would give the same sequences - though each on their own
will give a deterministic pseudo-random sequence based on their seeds.
If you swap gcc with clang you will get the same results - it will
depend on whether you are linking with glibc, musl, or another C library.
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 14:45 +0000 |
| Message-ID | <10ie9u5$b8ho$1@dont-email.me> |
| In reply to | #395901 |
On Tue, 23 Dec 2025 08:25:59 +0100, David Brown wrote: > It is not the compilers that are different, it is the C standard > libraries that are different. gcc is a compiler, not a library, but you > are probably using glibc with it by default. musl is a library, not a > compiler. There is no reason to suppose that different C standard > libraries use the same implementation of rand()and srand(), so no reason > to suppose they would give the same sequences - though each on their own > will give a deterministic pseudo-random sequence based on their seeds. > > If you swap gcc with clang you will get the same results - it will > depend on whether you are linking with glibc, musl, or another C library. Sure enough & thank you David - I appreciate your explanation. I see where my thinking was off now. You're 100% correct (I'm still learning as you noticed). -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2025-12-23 19:15 +0100 |
| Message-ID | <10iem7s$f9sv$1@dont-email.me> |
| In reply to | #395909 |
On 23/12/2025 15:45, Michael Sanders wrote: > On Tue, 23 Dec 2025 08:25:59 +0100, David Brown wrote: > >> It is not the compilers that are different, it is the C standard >> libraries that are different. gcc is a compiler, not a library, but you >> are probably using glibc with it by default. musl is a library, not a >> compiler. There is no reason to suppose that different C standard >> libraries use the same implementation of rand()and srand(), so no reason >> to suppose they would give the same sequences - though each on their own >> will give a deterministic pseudo-random sequence based on their seeds. >> >> If you swap gcc with clang you will get the same results - it will >> depend on whether you are linking with glibc, musl, or another C library. > > Sure enough & thank you David - I appreciate your explanation. > > I see where my thinking was off now. You're 100% correct > (I'm still learning as you noticed). > There are people who have been in this group for decades that still have trouble understanding the distinction between a C compiler, a C standard library, and a C implementation (which combines both). There are C compilers that have a standard library tightly attached or "built in" in the same product, and others which can work with a number of different C standard libraries. There are C standard libraries that only work with a single compiler, and others that are much more general - though you can't write a complete C standard library purely in fully portable C. And C compilers can implement standard library functions in the compiler itself (this is typically done for small functions like memcpy, or maths functions - things that can be significantly more efficient when handled inline by the compiler). There are many nuances involved - but you've found a clear way to show a difference between two common C libraries, so that's a good start.
[toc] | [prev] | [next] | [standalone]
| From | John McCue <jmclnx@gmail.com.invalid> |
|---|---|
| Date | 2025-12-23 00:39 +0000 |
| Message-ID | <10icocl$3u4ua$1@dont-email.me> |
| In reply to | #395879 |
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));
--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-23 02:17 +0000 |
| Message-ID | <10icu2t$3vgt9$1@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. Not to mention a lot stronger, cryptographically.
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-23 14:55 +0000 |
| Message-ID | <10ieahv$b8ho$4@dont-email.me> |
| In reply to | #395896 |
On Tue, 23 Dec 2025 02:17:01 -0000 (UTC), Lawrence D’Oliveiro 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. > > Not to mention a lot stronger, cryptographically. No srand() combined with crypto on my end. Sounds like an invitation to get hacked from everything I've ever read about mixing the two. -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-24 23:35 -0600 |
| Message-ID | <10iiifu$1kph3$2@dont-email.me> |
| In reply to | #395912 |
On 12/23/2025 8:55 AM, Michael Sanders wrote: > On Tue, 23 Dec 2025 02:17:01 -0000 (UTC), Lawrence D’Oliveiro 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. >> >> Not to mention a lot stronger, cryptographically. > > No srand() combined with crypto on my end. Sounds like an invitation > to get hacked from everything I've ever read about mixing the two. > While arguably a typical C library "rand()" isn't that strong, if one has a number sequence of output random digits, it might still take an impractical amount of time to brute-force search the entire seed space for a 64-bit seed. So, for example, if used to encrypt a point-to-point session, it is likely whatever session would have ended long before the attacker could brute-force the pattern. And, AFAIK, with a typical LCG there is no good way to feed the numbers back into the RNG to get back the seed (though, such a strategy is possible with some of my shift-and-XOR RNG's, but these are usually more intended to generate numbers faster, as the C library "rand()" is sometimes not fast enough...).
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2025-12-26 08:23 +0000 |
| Message-ID | <10ilgmr$2fs21$3@dont-email.me> |
| In reply to | #395963 |
On Wed, 24 Dec 2025 23:35:55 -0600, BGB wrote: > While arguably a typical C library "rand()" isn't that strong, if one > has a number sequence of output random digits, it might still take an > impractical amount of time to brute-force search the entire seed space > for a 64-bit seed. That is a great point IMO. After reading this I used Gemini to get a guess on the number of permutations for A-Z, its reply was: 'over 403 quintillion millions' of permatations for A-Z... Now if we split that list (assuming each line was randomized 26 characters A-Z) & used each line exactly *once*, then destroyed it, we might maintain some privacy. At least till quantum stuff is in every day use... -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2025-12-26 14:48 -0600 |
| Message-ID | <10imsbe$2u2k7$1@dont-email.me> |
| In reply to | #395983 |
On 12/26/2025 2:23 AM, Michael Sanders wrote:
> On Wed, 24 Dec 2025 23:35:55 -0600, BGB wrote:
>
>> While arguably a typical C library "rand()" isn't that strong, if one
>> has a number sequence of output random digits, it might still take an
>> impractical amount of time to brute-force search the entire seed space
>> for a 64-bit seed.
>
> That is a great point IMO. After reading this I used Gemini to get a guess
> on the number of permutations for A-Z, its reply was:
>
> 'over 403 quintillion millions' of permatations for A-Z...
>
> Now if we split that list (assuming each line was randomized 26 characters
> A-Z) & used each line exactly *once*, then destroyed it, we might maintain
> some privacy. At least till quantum stuff is in every day use...
>
Though, to be fair, 26! is larger than 2^64.
But, yeah, if you have 64 bits of entropy, while it can be brute forced,
it wont happen very quickly (and most normal attackers aren't going to
have a supercomputer or similar on-call to crack it faster).
Contrast, say for something with a 32 seed, it could be possible that it
could be brute forced within a few seconds or so.
But, yeah, one of the main use-cases I had often had for large seed
state RNGs is things like UUID generation, which requires a reasonably
good RNG with 256 or preferably 512 bits or more of seed state.
Intermediate is ASLR, where something like a 64 or 128-bit RNG is mostly
fine. Well, and the effectiveness of ASLR is reduced by a few practical
limitations:
Can usually only do ASLR on page boundaries,
losing some bits of entropy;
May need to cluster ASLR into reused sections of the address space,
as full randomization results in mostly-empty page table pages.
Say, for example, you start with 48 bits,
Cut off 12 to 16 bits for page offset,
Cut off a few HOBs for userland (say 46b for userland space);
Maybe quantize high order address into 256 or so buckets.
...
Then one finds that effectively they have around 16 bits or so of
entropy here.
Well, say, for ASLR allocation, one might have a process like:
For N tries, with a counter:
Generate a random number to select a bucket;
If index is an unused bucket try again (decrementing counter);
Generate a random address within this bucket;
Check if the span of pages is free;
If so, allocate these pages, call it done.
Else, retry (decrementing counter).
For N more tries:
Generate a full address over the allowed range;
Check if pages are free;
If so, allocate pages;
Set up a bucket for this area of address space;
Done.
If we get here, likely the whole address space is full...
Or the user is trying to allocate vast areas of address space,
and fragmentation has won the day.
The first step for allocation is to mark pages as reserved, then return
the base address for the region. then generally the pages are modified
to have the desired attributes. Typically (at least in my case) pages
are not immediately assigned a backing location in the page-file, but
this may happen lazily.
On first access, if a read, it may be assigned initially to a read-only
zero page (no dedicated backing RAM); on first write it is given backing
RAM (and assigned a location in the pagefile). If something is paged
out, it may detect if the page is all zeroes and potentially revert it
back to an initial zeroed-page state (freeing the backing page rather
than writing it to the pagefile). This can be used to reduce wasting RAM
and pagefile space on bulk zeroed memory (can often be a significant
chunk of RAM in some cases).
Though, by itself has a risk of resulting in a situation where the
pagefile is over-committed (there is more active memory allocated than
available pagefile space should all this RAM actually be used). So,
better to keep track of this and have allocations fail should the total
number of committed pages would exceed the size of the pagefile
regardless of whether or not all the pagefile pages are actually being
used (well, could go the other way; but then there is a bad situation
where backing storage runs out in the absence of new memory allocations,
potentially resulting in processes crashing at random, rather than
failing earlier by a "mmap()" call or similar returning NULL).
Well, as can note my memory map (custom OS on a custom ISA, though I am
also running RISC-V code on this to some extent) looks sorta like (47:32
only):
0000: Low 4GB region (system, direct-mapped memory)
0001..3FFF: Shared / Global Alloc region;
4000..7FFF: Private Alloc (per-process private VAS)
8000..BFFF: System Reserved (MMU)
C000..FFFF: Hardware memory map stuff (NOMMU RAM and MMIO, etc)
...
The idea here being that private address space is only visible to the
process in question, but stuff in the global space may potentially be
visible between processes (though is not necessarily accessible to all
processes; idea is that an ACL based protection scheme would be used
here rather than by address-space isolation).
There is a region for direct-mapped RAM currently located in
0000_40000000..0000_7FFFFFFF; this is generally read-only from userland.
Addresses in this range have virtual-address translation, but are mapped
1:1 with backing RAM pages (so its size is naturally more limited).
A sort of ASLR is used in the direct-mapping space as well, but less
effective since the space is smaller. In this case, RNG tries to
generate starting page addresses directly.
Well, and, say (low 4GB):
00xxxxxx: Mostly ROM, some SRAM for IRQs, and read-only niche pages.
There are ROM pages whose sole purpose is to be all zeroes, etc.
010xxxxx: RAM area, reserved for kernel stacks and similar
011xxxxx: RAM area, kernel image starts here.
...
Can note about how programs work in my case:
The executable parts of an EXE or DLL are separate from the
user-writable parts;
Currently, the executable parts are held in direct-mapped memory rather
than pagefile backed memory (stuff tended to break if these parts could
be paged out);
Things like writable memory (data/bss) and heap, are instead allocated
in pagefile backed memory.
Generally, the mappings for the EXEs and DLLs are shared between all
instances of that binary; with data/bss being per-process (accessed via
the GP/GBR register, *1).
Well, except ELF PIE binaries, which need to load a new instance each
time (so waste RAM, more so with the large amounts of clutter GCC leaves
in the ELF binaries; where things like symbol tables, and worse, DWARF
metadata, can be well in access of any actual code in the binary...).
*1: In my ABI, GP/GBR always holds a pointer to a table which can be
used by each image to reload its own data area. EXE's always have an
index of 0 (since there is only ever one EXE per process instance) and
each DLL is assigned an index number into the table at load time. By
going through a ritual, functions can get back to their own table. This
process is handled callee side, with functions deciding whether or not
to do so based on criteria (may be potentially called from outside the
current PE image, and which may access global variables and/or are
non-leaf functions, etc).
By default, my compiler tends to shuffle functions and variables around
based on random numbers (different for each run of the compiler), though
the effectiveness is reduced by also needing to try to pull related
functions closer together, and commonly used variables closer to the
start of the data section (commonly used globals may go into ".data"
rather than ".bss" even if technically uninitialized; mostly to make it
more efficient to access them with smaller displacements).
But, the general goal here is to try to make it harder for any potential
buffer-overflow shell-code to do anything useful (assuming it gets past
the stack canaries, etc, which also use RNG values). There is a risk
here that if a binary goes for long enough without being recompiled,
that it could become more vulnerable (in this case, even in otherwise
vulnerable code, there would be some security merit to periodic
recompilation to shuffle around functions and generate new canary values).
Though, had experimented with another mechanism to reduce the
probability of shell-code, namely tagging function-pointers and
link-register values to limit tampering (all the link registers and
function pointers could be tagged with a magic number that is unique for
each run).
This sorta works, but is weakened if needing to deal with generic RISC-V
code (use of AUIPC+ADDI is incompatible with this approach; and kinda
defeated if any shell-code could simply use an untagged pointer; though
a partial workaround is to trap if "JALR X0, 0(X1)" is used with an
incorrectly tagged pointer, as this almost invariably means a
return-address had been stomped; but would still be weak against
stomping other values).
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).
Granted, none of these is an infallible defense, but if one piles on
enough stuff, it becomes statistically improbable that any shell-code
could make it past the defenses (any would-be attacker would likely need
to know the RNG states at the moment a given process was created in
order to craft an effective attack).
Well, unless the attack is basically just to crash the process, this
doesn't require knowing any of the RNG state.
Well, one thing that isn't done in my case is to jitter the kernel load
address, which could probably also make sense (always loading the kernel
at the same address being itself a potential attack surface; say, if
exploiting a kernel-mode buffer overflow or a breakdown in the
memory-protection schemes, etc).
...
[toc] | [prev] | [next] | [standalone]
Page 4 of 10 — ← Prev page 1 2 3 [4] 5 6 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web