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 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-31 22:57 +0000 |
| Message-ID | <10j49pi$2v0l9$1@dont-email.me> |
| In reply to | #396036 |
On 31/12/2025 20:55, Lawrence D’Oliveiro wrote:
> On Wed, 31 Dec 2025 18:42:45 +0000, bart wrote:
>
>> In any case, it is easy enough to do a check on argc's value in your
>> applications. (And on Windows, if it is 0 and you really need the
>> path, you can get it with GetModuleFileNameA().)
>
> Remember that, on *nix systems, the contents of argv are arbitrary and
> caller-specified. And none of them need bear any relation to the
> actual filename of the invoked executable.
>
> In fact, it is quite common for utilities to behave differently based
> on the name, as passed in argv[0], by which they are invoked.
Yes, I do that all the time (especially from my other languages that
also make use of msvcrt.dll).
But, there is a difference between argv[0] and GetModuleFileName().
The latter returns the full path of the executable (which also then
allows you to pick up associated files in the same folder).
argv[0] merely returns what was typed on the command line to invoke the
application.
So if someone types:
C:\abc> prog
it may run a prog.exe found in, say, c:\programs\myapp, and return the
full path as "c:\programs\myapp\prog.exe".
args[0] will give you only "prog"; good luck with that!
I found out a few years ago that this useful funcion doesn't exist on
Unix-like systems. You have to do it a more complicated way that may or
may not work.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 16:00 -0800 |
| Message-ID | <87ldiiurpu.fsf@example.invalid> |
| In reply to | #396037 |
bart <bc@freeuk.com> writes:
[...]
> argv[0] merely returns what was typed on the command line to invoke the application.
>
> So if someone types:
>
> C:\abc> prog
>
> it may run a prog.exe found in, say, c:\programs\myapp, and return the full path as
> "c:\programs\myapp\prog.exe".
>
> args[0] will give you only "prog"; good luck with that!
[...]
That's typically how it works, but it's not guaranteed.
If a program is invoked from a shell on a Unix-like system, the
shell will use something like fork() and one of the exec() functions,
and will typically (perhaps always?) arrange for the new process's
argv[0] to point to a copy of the program name given on the shell
command line. (Programs that behave differently depending on the
string pointed to by argv[0] are typically invoked via symbolic
links, so for example vi and view might be names for the same
executable.)
But there are a number of other ways to invoke programs. In the
example I posted, a C program calls execve() directly, and sets up
argc and argv in a way that a shell would never do.
For safety, any program should safely handle being invoked
with unusual arguments -- especially any program with extra
privileges. For simplicity, it could simply abort if argc==0
and/or argv[0]==NULL.
Similar considerations probably apply on Windows, though it seems that
Windows tries to guarantee argc>1 and argv[0]!=NULL.
--
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 | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-01 01:03 +0000 |
| Message-ID | <10j4h4k$322ht$1@dont-email.me> |
| In reply to | #396037 |
On Wed, 31 Dec 2025 22:57:55 +0000, bart wrote: > But, there is a difference between argv[0] and GetModuleFileName(). So the latter cannot be used as a simple substitute for the former, as you might have led us to believe.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-01-01 14:05 +0000 |
| Message-ID | <10j5uv8$3gtk6$1@dont-email.me> |
| In reply to | #396051 |
On 01/01/2026 01:03, Lawrence D’Oliveiro wrote: > On Wed, 31 Dec 2025 22:57:55 +0000, bart wrote: > >> But, there is a difference between argv[0] and GetModuleFileName(). > > So the latter cannot be used as a simple substitute for the former, as > you might have led us to believe. It depends on your needs. If you need to know exactly what was typed, then you use GetCommandLine and extract the first part of it. Or you just use __getmainargs. Or argv[0] if available. However, I was responding to this: LD'O: >In fact, it is quite common for utilities to behave differently based on the name, as passed in argv[0], by which they are invoked. And previously I'd said this: >(And on Windows, if it is 0 and you really need the path, you can get it with GetModuleFileNameA().) At that point I'd forgotten that GetModuleFileName gives you more information than argv[0], so you'd to extract it. But you'd have to do that anyway to clean up the input: somebody may have typed c:\abc\.\.\.\.\.\ProG So I wasn't misleading anybody.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-01 19:03 +0000 |
| Message-ID | <10j6gej$3mtri$4@dont-email.me> |
| In reply to | #396056 |
On Thu, 1 Jan 2026 14:05:29 +0000, bart wrote: > On 01/01/2026 01:03, Lawrence D’Oliveiro wrote: >> >> On Wed, 31 Dec 2025 22:57:55 +0000, bart wrote: >> >>> But, there is a difference between argv[0] and >>> GetModuleFileName(). >> >> So the latter cannot be used as a simple substitute for the former, >> as you might have led us to believe. > > It depends on your needs. You neglected to mention that when offering the substitute before though, didn’t you?
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-01-01 20:28 +0000 |
| Message-ID | <10j6le2$3pgt8$1@dont-email.me> |
| In reply to | #396058 |
On 01/01/2026 19:03, Lawrence D’Oliveiro wrote: > On Thu, 1 Jan 2026 14:05:29 +0000, bart wrote: > >> On 01/01/2026 01:03, Lawrence D’Oliveiro wrote: >>> >>> On Wed, 31 Dec 2025 22:57:55 +0000, bart wrote: >>> >>>> But, there is a difference between argv[0] and >>>> GetModuleFileName(). >>> >>> So the latter cannot be used as a simple substitute for the former, >>> as you might have led us to believe. >> >> It depends on your needs. > > You neglected to mention that when offering the substitute before > though, didn’t you? FFS, why are you always looking for some argument? Have the last word if you like. If it makes you happier, I will admit I was deliberately misleading and totally wrong. But about what, I don't know! FWIW, I first mentioned GetModuleFileName as a possibility when argv[0] was not available. So I now withdraw that suggestion. That means that if argv[0] isn't available, then you're fucked, since there are apparently no workarounds that would be 100% equivalent to what argv[0] would have provided.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 15:29 -0800 |
| Message-ID | <87pl7uut6c.fsf@example.invalid> |
| In reply to | #396030 |
Paul <nospam@needed.invalid> writes:
[...]
> # **Cross‑Platform Note**
> The C standard does **not** guarantee that argv[0] contains the
> program name — only that it exists.
[...]
That isn't quite correct, or is at least misleading. ISO C guarantees
that argv[0] exists, but not that it points to a string. On some
systems, it can contain be a null pointer.
--
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 | highcrew <high.crew3868@fastmail.com> |
|---|---|
| Date | 2026-01-01 00:31 +0100 |
| Message-ID | <10j4bok$2vboo$1@dont-email.me> |
| In reply to | #396044 |
Hi, On 1/1/26 12:29 AM, Keith Thompson wrote: > Paul <nospam@needed.invalid> writes: > That isn't quite correct, or is at least misleading. ISO C guarantees > that argv[0] exists, but not that it points to a string. On some > systems, it can contain be a null pointer. I heard of this before. Is it just theoretical, or do we have actual systems where argv[0]==NULL? I never saw it happen in any modern operating system. -- High Crew
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 16:05 -0800 |
| Message-ID | <87h5t6uri8.fsf@example.invalid> |
| In reply to | #396045 |
highcrew <high.crew3868@fastmail.com> writes:
> On 1/1/26 12:29 AM, Keith Thompson wrote:
>> Paul <nospam@needed.invalid> writes:
>> That isn't quite correct, or is at least misleading. ISO C guarantees
>> that argv[0] exists, but not that it points to a string. On some
>> systems, it can contain be a null pointer.
>
> I heard of this before.
>
> Is it just theoretical, or do we have actual systems where
> argv[0]==NULL? I never saw it happen in any modern operating system.
Some systems (try to) guarantee that argv[0] points to a string, which
may or may not be the name of the program. But there are ways, on some
systems, to invoke a program with argc==0 and argv[0]==NULL.
For details see here (I've recently made some updates).
https://github.com/Keith-S-Thompson/argv0
--
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 S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-31 15:29 +0200 |
| Message-ID | <20251231152909.00002bf9@yahoo.com> |
| In reply to | #396021 |
On Wed, 31 Dec 2025 03:10:52 -0000 (UTC) Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Wed, 31 Dec 2025 02:01:55 -0000 (UTC), Michael Sanders wrote: > > > *ISO C (C17 / C23)*: > > > > C17, 5.1.2.2.1 "Program startup" > > > > The value of argc shall be nonnegative. > > > > argv[argc] shall be a null pointer. > > > > If the value of argc is greater than zero, the array members argv[0] > > through argv[argc−1] inclusive shall contain pointers to strings > > which are given implementation-defined values. > > > > ... > > > > What say you? > > Clearly on Windows, there are no guarantees about argc contains, so > you shouldn’t be relying on it. How did you come to this conclusion? Keith's test appears to show the opposite - he was not able to convince the Windows system to call application with empty argv list. Of course, he tried only one way out of many, but knowing how native Windows system call works, it appears extremely likely that on Windows argc < 1 is impossible. https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-31 20:52 +0000 |
| Message-ID | <10j42fb$2s72e$5@dont-email.me> |
| In reply to | #396028 |
On Wed, 31 Dec 2025 15:29:09 +0200, Michael S wrote: > On Wed, 31 Dec 2025 03:10:52 -0000 (UTC) > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >> Clearly on Windows, there are no guarantees about argc contains, so >> you shouldn’t be relying on it. > > How did you come to this conclusion? The fact that the C spec says so. Is there any standard on Windows for how different C compilers are supposed to handle argc/argv?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 15:14 -0800 |
| Message-ID | <87y0miutv0.fsf@example.invalid> |
| In reply to | #396035 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Wed, 31 Dec 2025 15:29:09 +0200, Michael S wrote:
>> On Wed, 31 Dec 2025 03:10:52 -0000 (UTC)
>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
>>> Clearly on Windows, there are no guarantees about argc contains, so
>>> you shouldn’t be relying on it.
>>
>> How did you come to this conclusion?
>
> The fact that the C spec says so.
You may well be correct, but I don't know how you reached that
conclusion.
Older Linux kernels make it possible to invoke a program with argc==0
and argv[0]==NULL. Newer Linux kernels have a modified execve() that
guarantees argc==1 and argv[0]!=NULL. NetBSD still permits argc==0.
So some Unix-like systems (try to) guarantee argc>0, and some do not.
It's entirely possible that Windows goes beyond the ISO C
requirements and explicitly or implicitly guarantees argc>0.
It's also entirely possible that it doesn't. Do you have any
concrete information one way or the other
> Is there any standard on Windows for
> how different C compilers are supposed to handle argc/argv?
That's a good question, and I don't know the answer.
--
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 | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2026-01-05 20:00 -0800 |
| Message-ID | <g62plk5vbdskkc4oh6dsbask7t3ea7sva7@4ax.com> |
| In reply to | #396042 |
On Wed, 31 Dec 2025 15:14:27 -0800, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: >It's entirely possible that Windows goes beyond the ISO C >requirements and explicitly or implicitly guarantees argc>0. >It's also entirely possible that it doesn't. Do you have any >concrete information one way or the other https://learn.microsoft.com/en-us/cpp/cpp/main-function-command-line-args?view=msvc-170
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 15:03 -0800 |
| Message-ID | <87344qw8xl.fsf@example.invalid> |
| In reply to | #396028 |
Michael S <already5chosen@yahoo.com> writes:
> On Wed, 31 Dec 2025 03:10:52 -0000 (UTC)
> Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
[...]
>> Clearly on Windows, there are no guarantees about argc contains, so
>> you shouldn’t be relying on it.
>
> How did you come to this conclusion?
> Keith's test appears to show the opposite - he was not able to convince
> the Windows system to call application with empty argv list.
> Of course, he tried only one way out of many, but knowing how native
> Windows system call works, it appears extremely likely that on Windows
> argc < 1 is impossible.
To be clear, my test didn't show anything about Windows. I ran the test
under Cygwin, not under native Windows.
[...]
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-30 19:35 -0800 |
| Message-ID | <87jyy3wcgf.fsf@example.invalid> |
| In reply to | #396020 |
Michael Sanders <porkchop@invalid.foo> writes:
> On Tue, 30 Dec 2025 18:42:30 GMT, Scott Lurndal wrote:
>> What if 'argv[0]' is NULL (and argc == 0)?
>
> Well, seems we have to make a choice, ISO vs. POSIX:
>
> *ISO C (C17 / C23)*:
>
> C17, 5.1.2.2.1 "Program startup"
>
> The value of argc shall be nonnegative.
>
> argv[argc] shall be a null pointer.
[...]
> *POSIX.1-2017 (and later)*
>
> POSIX execve() specification:
>
> The argument argv is an array of character pointers
> to null-terminated strings.
>
> The application shall ensure that argv[0] points to a filename
> string that is associated with the process being started.
[...]
> What say you?
It happens that I recently spent some time looking into this.
As you say, POSIX requires argc >= 1, but ISO C only guarantees
argc >= 0.
If argc == 0, a program that assumes argv[0] is non-null
can run into serious problems if that assumption is invalid.
In particular, a program called "pkexec" would try to traverse
arguments starting with argv[1], which logically doesn't
exist if argc==0. Due to the way program arguments are laid
out in memory, argv[1] is also envp[0]. Frivolity ensued.
See <https://nvd.nist.gov/vuln/detail/cve-2021-4034>.
The Linux kernel updated execve to ensure that the invoked program
has argc>=1. It was patched in early 2022. NetBSD still has this
vulnerability.
Summary: Some systems guarantee that argc>=1 and argv[0] points to
a valid string, but software that's intended to be portable should
tolerate argc==0 and argv[0]==NULL.
For more information, see
<https://github.com/Keith-S-Thompson/argv0>.
--
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-31 04:51 +0000 |
| Message-ID | <10j2a3u$2alh7$1@dont-email.me> |
| In reply to | #396023 |
On Tue, 30 Dec 2025 19:35:12 -0800, Keith Thompson wrote:
> Summary: Some systems guarantee that argc>=1 and argv[0] points to
> a valid string, but software that's intended to be portable should
> tolerate argc==0 and argv[0]==NULL.
>
> For more information, see
> <https://github.com/Keith-S-Thompson/argv0>.
Thanks Keith so I'll roll with ISO:
int main(int argc, char *argv[]) {
// ISO: if app named 'moo' play bulls & cows else mastermind
const char *p = (argc > 0 && argv && argv[0]) ? argv[0] : "";
const char *m = strrchr(p, '/');
MOO = strcmp(m ? m + 1 : p, "moo") == 0;
int s = get_seed(argc, argv); // returns default seed if not supplied
fflush(stdout);
fprintf(stderr, "%d\n", play(s)); // print seed to stderr
return 0;
}
--
:wq
Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-31 15:15 +0200 |
| Message-ID | <20251231151502.00002c3e@yahoo.com> |
| In reply to | #396023 |
On Tue, 30 Dec 2025 19:35:12 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote: > Michael Sanders <porkchop@invalid.foo> writes: > > On Tue, 30 Dec 2025 18:42:30 GMT, Scott Lurndal wrote: > >> What if 'argv[0]' is NULL (and argc == 0)? > > > > Well, seems we have to make a choice, ISO vs. POSIX: > > > > *ISO C (C17 / C23)*: > > > > C17, 5.1.2.2.1 "Program startup" > > > > The value of argc shall be nonnegative. > > > > argv[argc] shall be a null pointer. > > [...] > > > *POSIX.1-2017 (and later)* > > > > POSIX execve() specification: > > > > The argument argv is an array of character pointers > > to null-terminated strings. > > > > The application shall ensure that argv[0] points to a filename > > string that is associated with the process being started. > > [...] > > > What say you? > > It happens that I recently spent some time looking into this. > > As you say, POSIX requires argc >= 1, but ISO C only guarantees > argc >= 0. > > If argc == 0, a program that assumes argv[0] is non-null > can run into serious problems if that assumption is invalid. > In particular, a program called "pkexec" would try to traverse > arguments starting with argv[1], which logically doesn't > exist if argc==0. Due to the way program arguments are laid > out in memory, argv[1] is also envp[0]. Frivolity ensued. > See <https://nvd.nist.gov/vuln/detail/cve-2021-4034>. > > The Linux kernel updated execve to ensure that the invoked program > has argc>=1. It was patched in early 2022. NetBSD still has this > vulnerability. > > Summary: Some systems guarantee that argc>=1 and argv[0] points to > a valid string, but software that's intended to be portable should > tolerate argc==0 and argv[0]==NULL. > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-31 20:51 +0000 |
| Message-ID | <10j42ct$2s72e$4@dont-email.me> |
| In reply to | #396027 |
On Wed, 31 Dec 2025 15:15:02 +0200, Michael S wrote: > ... using exec() in caller sounds like a bad idea. It just not how > these systems work and not how people write programs on them. I don’t think I’ve used exec() on its own without fork() much, but it is quite common to do fork() without exec(). That’s another thing that I suspect non-*nix systems don’t handle very well. > I'd implement caller with spawn(). I suppose that even on POSIX it > is more idiomatic. Do you mean posix_spawn(3)? <https://manpages.debian.org/posix_spawn(3)>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 15:00 -0800 |
| Message-ID | <877bu2w92v.fsf@example.invalid> |
| In reply to | #396027 |
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().
--
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 S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-01 01:45 +0200 |
| Message-ID | <20260101014548.000012eb@yahoo.com> |
| In reply to | #396038 |
On Wed, 31 Dec 2025 15:00:24 -0800 Keith Thompson <Keith.S.Thompson+u@gmail.com> 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.) > 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. > 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(). > Yes, some tricky combinations easily possible under POSIX are hard to achieve under Windows. The result could depend on exact implementation of parsing of command line in C start up code. May be, some combinations are even impossible, although right now I can not think out an example. But that was not my point. My point was that analog of exec() family does not exist in Windows (or VMS). Even if it appears to exist that just means that your environment somehow fooling you. The PID of child is not the same as parent's. So, if you want cross-platform test, it makes more sense to use spawn() family. It does not look like your test will be any more complicated with spawn() and as a free benefit you can print some info of interest in the parent process after after spawn() call. However I was wrong in my suggestion. I didn't realize that spawn functions under Windows and their POSIX equivalents have different names and different order of arguments. So, I take my suggestion back.
[toc] | [prev] | [next] | [standalone]
Page 8 of 10 — ← Prev page 1 … 6 7 [8] 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web