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 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-01 19:02 +0000 |
| Message-ID | <10j6gcp$3mtri$3@dont-email.me> |
| In reply to | #396055 |
On Thu, 1 Jan 2026 07:32:34 -0000 (UTC), Michael Sanders wrote: > On Wed, 31 Dec 2025 09:37:08 -0000 (UTC), Lawrence D’Oliveiro wrote: > >> Are there any standards for how C argc/argv are supposed to behave >> on Windows? > > Good question, some more ways to open things (that I know of), see > 2nd example for 'sort of' argc/argv... > > [examples omitted] All those are at the sending end. But what would C code see at the receiving end?
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-01 19:20 +0000 |
| Message-ID | <10j6hd8$3nhd7$1@dont-email.me> |
| In reply to | #396057 |
On Thu, 1 Jan 2026 19:02:49 -0000 (UTC), Lawrence D’Oliveiro wrote: > All those are at the sending end. But what would C code see at the > receiving end? Opp, you're right. My bad (stuck function pointer h*ll at the moment...) -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-01 21:53 +0200 |
| Message-ID | <20260101215320.00004497@yahoo.com> |
| In reply to | #396057 |
On Thu, 1 Jan 2026 19:02:49 -0000 (UTC) Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Thu, 1 Jan 2026 07:32:34 -0000 (UTC), Michael Sanders wrote: > > > On Wed, 31 Dec 2025 09:37:08 -0000 (UTC), Lawrence D’Oliveiro wrote: > > > >> Are there any standards for how C argc/argv are supposed to behave > >> on Windows? > > > > Good question, some more ways to open things (that I know of), see > > 2nd example for 'sort of' argc/argv... > > > > [examples omitted] > > All those are at the sending end. But what would C code see at the > receiving end? The first three cases look very simple. 1. argc=1 argv[0]=notepad.exe argv[1]=NULL 2. argc=1 argv[0]=C:\Windows\System32\calc.exe argv[1]=NULL 3. argc=2 argv[0]=notepad.exe argv[1]=C:\temp\notes.txt argv[2]=NULL 4th case does not look like a legal C code. It probably was screwed either by poster's news reader or by my news reader.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-01 23:50 +0000 |
| Message-ID | <10j7178$3tgvf$1@dont-email.me> |
| In reply to | #396060 |
On Thu, 1 Jan 2026 21:53:20 +0200, Michael S wrote: > On Thu, 1 Jan 2026 19:02:49 -0000 (UTC) > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >> All those are at the sending end. But what would C code see at the >> receiving end? > > The first three cases look very simple. Is there some spec in Windows which describes how that works?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-02 14:32 +0200 |
| Message-ID | <20260102143207.00002ae3@yahoo.com> |
| In reply to | #396066 |
On Thu, 1 Jan 2026 23:50:00 -0000 (UTC) Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > On Thu, 1 Jan 2026 21:53:20 +0200, Michael S wrote: > > > On Thu, 1 Jan 2026 19:02:49 -0000 (UTC) > > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > > > >> All those are at the sending end. But what would C code see at the > >> receiving end? > > > > The first three cases look very simple. > > Is there some spec in Windows which describes how that works? There is a spec that describes how that works in Microsoft's implementation. That implementation is available free of charge to other Windows compilers. If vendor of Windows 'C' compiler decided to implement different algorithm then nobody can stop him. Through the years you were told so, by different people, and shown the spec may be 100 times. But being the trolll you are, you continue to ask. Still, for the benefit of more sincere readers and also for myself, in order to have both pieces in one place: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments More interesting and meaningful question is how to do the reverse. I.e. how to convert an argv[] array into flat form in a way that guarantees that CommandLineToArgvW() parses it back into original form? Is it even possible in general case or there exist limitations (ignoring, for sake of brevity, 2*15-1 size limit)? Microsoft certainly has reverse conversion implemented, e.g. here: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv But I am not aware of command line serialization part available as a library call in isolation from process creation part. I binged around and googled around, but all I was able to find was the name of the function that performs the work: __acrt_pack_wide_command_line_and_environment I was not able to find the source code of the function. [O.T.] I am sure that 15, 10 or even 5 years ago Google would give me link to the source in a second. Or, may be, 5 years ago Google already wouldn't, but Bing still would. But today both search engines are hopelessly crippled with AI and do not appear to actually search the web. Instead, the try to guess the answer I likely want to hear. [/O.T.]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-02 16:18 +0200 |
| Message-ID | <20260102161839.0000775b@yahoo.com> |
| In reply to | #396072 |
On Fri, 2 Jan 2026 14:32:07 +0200 Michael S <already5chosen@yahoo.com> wrote: > > > More interesting and meaningful question is how to do the reverse. > I.e. how to convert an argv[] array into flat form in a way that > guarantees that CommandLineToArgvW() parses it back into original > form? Is it even possible in general case or there exist limitations > (ignoring, for sake of brevity, 2*15-1 size limit)? > > Microsoft certainly has reverse conversion implemented, e.g. here: > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv > Experimenting with _spawnv() shows that Microsoft made no effort in the direction of invertible serialization/de-serialization of argv[] lists. That is, as long as there are no double quotes, everything works as expected. But when there are double quotes in the original argv[] then more often than not they can't be passed exactly. An exact result of de-serialization in presence of unusually placed " characters depends on the version of the library. Very old versions, like those before UCRT or relatively new versions of UCRT, like one in VS2022, do not produce an exact inversion, but otherwise their results are reasonable. The version of the library supplied with UCRT variant of msys2 tools is much less reasonable. I'd rather characterize it as buggy. Frankly, I don't understand how it is possible. It leads me to believe that parsing routines in C RTL do not use system-provided parser and instead do parsing by themselves.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-02 20:52 +0000 |
| Message-ID | <10j9b7a$mp8i$5@dont-email.me> |
| In reply to | #396073 |
On Fri, 2 Jan 2026 16:18:39 +0200, Michael S wrote: > Experimenting with _spawnv() shows that Microsoft made no effort in the > direction of invertible serialization/de-serialization of argv[] lists. > That is, as long as there are no double quotes, everything works as > expected. But when there are double quotes in the original argv[] then > more often than not they can't be passed exactly. And every now and then, this kind of fudging can progress beyond regular inflammation sadness into the full-fledged tumour of a Windows security hole <https://web.archive.org/web/20240711101329/https://list.waikato.ac.nz/archives/list/wlug@list.waikato.ac.nz/message/NVHWSZP7QF7QKYJO2UCHGZC4ADWSNNS7/>.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-02 20:46 +0000 |
| Message-ID | <10j9arn$mp8i$4@dont-email.me> |
| In reply to | #396072 |
On Fri, 2 Jan 2026 14:32:07 +0200, Michael S wrote:
> Through the years you were told so, by different people, and shown
> the spec may be 100 times. But being the trolll you are, you
> continue to ask.
>
> Still, for the benefit of more sincere readers and also for myself,
> in order to have both pieces in one place:
> https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw
> https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments
That second one begins with these words in large letters:
“MICROSOFT SPECIFIC”
(Remember I was asking for a spec applicable to Windows generally.)
Who’s trolling now?
Who’s trolling now?
(To the tune of “Who’s sorry now?” etc)
[toc] | [prev] | [next] | [standalone]
| From | Mike Terry <news.dead.person.stones@darjeeling.plus.com> |
|---|---|
| Date | 2026-01-03 04:08 +0000 |
| Message-ID | <10ja4o8$vuda$1@dont-email.me> |
| In reply to | #396072 |
On 02/01/2026 12:32, Michael S wrote: > On Thu, 1 Jan 2026 23:50:00 -0000 (UTC) > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >> On Thu, 1 Jan 2026 21:53:20 +0200, Michael S wrote: >> >>> On Thu, 1 Jan 2026 19:02:49 -0000 (UTC) >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: >>> >>>> All those are at the sending end. But what would C code see at the >>>> receiving end? >>> >>> The first three cases look very simple. >> >> Is there some spec in Windows which describes how that works? > > There is a spec that describes how that works in Microsoft's > implementation. That implementation is available free of charge to > other Windows compilers. > If vendor of Windows 'C' compiler decided to implement different > algorithm then nobody can stop him. > > Through the years you were told so, by different people, and shown > the spec may be 100 times. But being the trolll you are, you continue > to ask. > > Still, for the benefit of more sincere readers and also for myself, in > order to have both pieces in one place: > https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments > In the long distant past I investigated how MSVC converts a command-line to its argc/argv input. There was an internal routine in the CRT startup code that did pretty much what we would expect, and I reversed engineered that for my code (or did I just copy the code? surely the former!). The MSVC code did not call CommandLineToArgvW in those days, but reading the description of that api it all sounds very familiar - the state flags for controlling "quoted/unquoted" text, even vs odd numbers of backslashes and all that. I didn't find it difficult to create command-line strings to call C programs, given what I wanted those programs to see as argv[n] with n>0. I think it was just a case of quoting all arguments, then applying quoting rules as docuemented for CommandLineToArgvW to handle nested quotes/backslashes. But I can see a sticky problem - the MSVC parsing for argv[0] was completely separate from thr main loop handling other arguments. The logic was considerably simplified, assuming that argv[0] was the path for the module being invoked. Since that is expected to be a valid file system path, the logic did not handle nested quotes etc.. I think the logic was just: - if 1st char is a DQUOTE, copy chars for argv[0] up to next DQUOTE or null terminator. (enclosing DQUOTE chars are not included) - else copy chars for argv[0] up to next whitespace or null terminator. (all chars are included, I think including DQUOTE should it occur) Given this, it would not be possible to create certain argv[0] strings containing quotes etc., and I understand that the likes of execve() allow that possibility. So I don't know what should happen for this case. E.g. I don't see there is a command-line that gives argv[0] the string "\" ". This was never a problem for me in practice. There would always be at least an argv[0] with this logic, so MSVC ensures argc>0 and argv[0] != NULL. (Of course, MSVC is not "Windows". Various posters in this thread seem to be asking "what does /Windows/ do regarding argc/argv?" as though the OS is responsible for setting them.) > > More interesting and meaningful question is how to do the reverse. > I.e. how to convert an argv[] array into flat form in a way that > guarantees that CommandLineToArgvW() parses it back into original form? > Is it even possible in general case or there exist limitations > (ignoring, for sake of brevity, 2*15-1 size limit)? Yes, programmers need this if they need to create a process to invoke some utility program which will see particular argv parameters. Users are used to typing in command-lines as a string, e.g. at a console, so I suppose they don't normally need to think about the argv[] parsing; they can just build the required command-line and use that. (But it's a problem in the general case.) The argc/argv problem seemed easy enough in practice if we only need to handle the "real" arguments argv[n] with n>0. (Involving CMD.EXE introduced much worse complications, as you might imagine. But generally I always thought that MS wasn't really interested in /documenting/ how programmers should do things like this, in the same way they never bothered explaining exactly how CMD processing worked. Probably because it was forever changing!... Put another way, for many years they were really more focussed on admins clicking buttons in some GUI!) > > Microsoft certainly has reverse conversion implemented, e.g. here: > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/spawnv-wspawnv > > But I am not aware of command line serialization part available as a > library call in isolation from process creation part. > > I binged around and googled around, but all I was able to find was the > name of the function that performs the work: > __acrt_pack_wide_command_line_and_environment > > I was not able to find the source code of the function. > > [O.T.] > I am sure that 15, 10 or even 5 years ago Google would give me link to > the source in a second. Or, may be, 5 years ago Google already > wouldn't, but Bing still would. > But today both search engines are hopelessly crippled with AI and do not > appear to actually search the web. Instead, the try to guess the > answer I likely want to hear. > [/O.T.] I hear you on that! Also [O.T.] I used to have access to most of Windows source code as part of some Windows source code sharing program, so could have found answers to this sort of question with minimal effort. (My employer met the criteria based on number of Windows servers/desktops deployed. There were various hoops you had to jump through with contracts being regularly (re)signed by company board level directors and the likes. Wonder if they still do that... Anyway I'm long retired now.) Mike.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-01-03 04:39 +0000 |
| Message-ID | <10ja6ia$10c1k$1@dont-email.me> |
| In reply to | #396097 |
On Sat, 3 Jan 2026 04:08:40 +0000, Mike Terry wrote: > The argc/argv problem seemed easy enough in practice if we only need > to handle the "real" arguments argv[n] with n>0. (Involving CMD.EXE > introduced much worse complications, as you might imagine. But > generally I always thought that MS wasn't really interested in > /documenting/ how programmers should do things like this, in the > same way they never bothered explaining exactly how CMD processing > worked. Probably because it was forever changing!... Put another > way, for many years they were really more focussed on admins > clicking buttons in some GUI!) After years -- decades -- of conditioning its users to be allergic to the command line, now suddenly the rise of Linux has made command lines cool again. Leaving Microsoft in an awkward position ...
[toc] | [prev] | [next] | [standalone]
| From | Michael Sanders <porkchop@invalid.foo> |
|---|---|
| Date | 2026-01-03 14:24 +0000 |
| Message-ID | <10jb8qb$19mkp$1@dont-email.me> |
| In reply to | #396098 |
On Sat, 3 Jan 2026 04:39:39 -0000 (UTC), Lawrence D’Oliveiro wrote: > After years -- decades -- of conditioning its users to be allergic to > the command line, now suddenly the rise of Linux has made command > lines cool again. Leaving Microsoft in an awkward position ... And telemetry... compulsory updates... ads all over the place... (even paid editions). I'd rather have a quite conversation with my OS[1] instead of an argument. Microsoft has gotten /very/ predacious the last few years at least from my point of view. [1] CLI is good for that -- :wq Mike Sanders
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-01-03 20:38 +0200 |
| Message-ID | <20260103203842.00007d18@yahoo.com> |
| In reply to | #396097 |
On Sat, 3 Jan 2026 04:08:40 +0000 Mike Terry <news.dead.person.stones@darjeeling.plus.com> wrote: > On 02/01/2026 12:32, Michael S wrote: > > On Thu, 1 Jan 2026 23:50:00 -0000 (UTC) > > Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > > > >> On Thu, 1 Jan 2026 21:53:20 +0200, Michael S wrote: > >> > >>> On Thu, 1 Jan 2026 19:02:49 -0000 (UTC) > >>> Lawrence D’Oliveiro <ldo@nz.invalid> wrote: > >>> > >>>> All those are at the sending end. But what would C code see at > >>>> the receiving end? > >>> > >>> The first three cases look very simple. > >> > >> Is there some spec in Windows which describes how that works? > > > > There is a spec that describes how that works in Microsoft's > > implementation. That implementation is available free of charge to > > other Windows compilers. > > If vendor of Windows 'C' compiler decided to implement different > > algorithm then nobody can stop him. > > > > Through the years you were told so, by different people, and shown > > the spec may be 100 times. But being the trolll you are, you > > continue to ask. > > > > Still, for the benefit of more sincere readers and also for myself, > > in order to have both pieces in one place: > > https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw > > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments > > > > In the long distant past I investigated how MSVC converts a > command-line to its argc/argv input. There was an internal routine in > the CRT startup code that did pretty much what we would expect, and I > reversed engineered that for my code (or did I just copy the code? > surely the former!). The MSVC code did not call CommandLineToArgvW > in those days, but reading the description of that api it all sounds > very familiar - the state flags for controlling "quoted/unquoted" > text, even vs odd numbers of backslashes and all that. > > I didn't find it difficult to create command-line strings to call C > programs, given what I wanted those programs to see as argv[n] with > n>0. I think it was just a case of quoting all arguments, then > n>applying quoting rules as docuemented for CommandLineToArgvW to > n>handle nested quotes/backslashes. > > But I can see a sticky problem - the MSVC parsing for argv[0] was > completely separate from thr main loop handling other arguments. The > logic was considerably simplified, assuming that argv[0] was the path > for the module being invoked. Since that is expected to be a valid > file system path, the logic did not handle nested quotes etc.. I > think the logic was just: > > - if 1st char is a DQUOTE, copy chars for argv[0] up to next DQUOTE > or null terminator. (enclosing DQUOTE chars are not included) > - else copy chars for argv[0] up to next whitespace or null > terminator. (all chars are included, I think including DQUOTE should > it occur) > > Given this, it would not be possible to create certain argv[0] > strings containing quotes etc., and I understand that the likes of > execve() allow that possibility. So I don't know what should happen > for this case. E.g. I don't see there is a command-line that gives > argv[0] the string "\" ". This was never a problem for me in > practice. > > There would always be at least an argv[0] with this logic, so MSVC > ensures argc>0 and argv[0] != NULL. (Of course, MSVC is not > "Windows". Various posters in this thread seem to be asking "what > does /Windows/ do regarding argc/argv?" as though the OS is > responsible for setting them.) > > > > > More interesting and meaningful question is how to do the reverse. > > I.e. how to convert an argv[] array into flat form in a way that > > guarantees that CommandLineToArgvW() parses it back into original > > form? Is it even possible in general case or there exist limitations > > (ignoring, for sake of brevity, 2*15-1 size limit)? > > Yes, programmers need this if they need to create a process to invoke > some utility program which will see particular argv parameters. > Users are used to typing in command-lines as a string, e.g. at a > console, so I suppose they don't normally need to think about the > argv[] parsing; they can just build the required command-line and use > that. (But it's a problem in the general case.) > I hoped that Microsoft's implementation of _spawnv() at least makes an effort at reverse transformation. But test shows that it does not. _spawnl() appears to do something very dumb - just concatenate all argv[] strings inserting one space character between parts. So, it has troubles not just with double quotes but even with spaces within arguments. > The argc/argv problem seemed easy enough in practice if we only need > to handle the "real" arguments argv[n] with n>0. (Involving CMD.EXE > introduced much worse complications, as you might imagine. But > generally I always thought that MS wasn't really interested in > /documenting/ how programmers should do things like this, in the same > way they never bothered explaining exactly how CMD processing worked. > Probably because it was forever changing!... Put another way, for > many years they were really more focussed on admins clicking buttons > in some GUI!) > To be fair, powershell exists for many more years than WinNt family was existing before emergence of powershell. The problem with it, at least IMHO, is a second system syndrome. command.com and to significant extent cmd.exe as well, seen as programming language was too weak and too primitive. With Powershell they went too far in the opposite direction - its rather powerfull, as programming language, but nott as simple at simple tasks as one expects from OS shell. So, considering that fewer and fewer people with programmer's attitude are employed as admins, it's no wonder that most of them are incapable to write powershell scripts by themselves. At best, they can cat&past.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-30 19:37 -0800 |
| Message-ID | <87fr8rwccq.fsf@example.invalid> |
| In reply to | #396021 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> 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.
That's not clear. Linux (since 2022) guarantees argc>=1. I don't
know whether Windows makes a similar guarantee, but it's entirely
plausible that it could.
But not all systems guarantee argc>=1, so any portable code shouldn't
make assumptions beyond what's guaranteed by ISO C.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-12-31 17:24 +0000 |
| Message-ID | <h%c5R.941348$ACS3.803751@fx17.iad> |
| In reply to | #396024 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Lawrence D’Oliveiro <ldo@nz.invalid> writes: >> 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. > >That's not clear. Linux (since 2022) guarantees argc>=1. Does it? That seems to be up to the shell, since the exec() manual pages on the latest Fedora Core release don't indicate that argv[0] must be initialized or that argc be greater than zero.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2025-12-31 15:17 -0800 |
| Message-ID | <87tsx6utq5.fsf@example.invalid> |
| In reply to | #396029 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>That's not clear. Linux (since 2022) guarantees argc>=1.
>
> Does it? That seems to be up to the shell, since the exec()
> manual pages on the latest Fedora Core release don't indicate
> that argv[0] must be initialized or that argc be greater than zero.
As I understand it, all the exec() functions go through the execve()
system call. In 2022, the Linux kernel execve() implementation was
modified to guarantee that argc>0 and argv[0]!=NULL in the invoked
program. A shell presumably can't bypass that.
commit dcd46d897adb70d63e025f175a00a89797d31a43
Author: Kees Cook <kees@kernel.org>
Date: 2022-01-31 16:09:47 -0800
exec: Force single empty string when argv is empty
--
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 | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-31 12:30 -0500 |
| Message-ID | <10j3mit$2o18r$1@dont-email.me> |
| In reply to | #396024 |
On Tue, 12/30/2025 10:37 PM, Keith Thompson wrote:
> Lawrence D’Oliveiro <ldo@nz.invalid> writes:
>> 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.
>
> That's not clear. Linux (since 2022) guarantees argc>=1. I don't
> know whether Windows makes a similar guarantee, but it's entirely
> plausible that it could.
>
> But not all systems guarantee argc>=1, so any portable code shouldn't
> make assumptions beyond what's guaranteed by ISO C.
>
The Windows guarantee is with MSVC, according to this answer.
********** CoPilot Question **********
Does the Windows operating system guarantee that argc >= 1 for an EXE program ?
argv[0] usually contains the program absolute path.
********** CoPilot Answer ************
Here’s the clear, standards‑grounded, Windows‑specific answer you’re looking for — with citations from the search results.
# **Short Answer**
**Yes. On Windows, when using the Microsoft C runtime (MSVCRT), argc
is always guaranteed to be ≥ 1**, and ** argv[0] always exists**.
However, **Windows itself does *not* guarantee what argv[0] contains** -
only that the C runtime *treats* it as the program name.
---
# **What Windows Guarantees vs. What the C Runtime Guarantees**
### **Microsoft C Runtime Guarantee**
Microsoft’s documentation explicitly states:
- *“Since the program name is considered an argument, the value of argc is at least one.”*
So if your EXE is built with MSVC and uses the standard main or wmain , you can rely on:
- argc >= 1
- argv[0] is a valid null‑terminated string
- argv[argc] == NULL
### **MSVC Startup Code Behavior**
MSVC startup code parses the command line and
**always inserts the program name as argv[0] ** (quoted if needed).
---
# **What Windows *Does Not* Guarantee**
Windows itself does **not** enforce that the first token of the command line
is the executable name. This is a convention, not a rule:
- * By convention the module name ... is the first argument ... Note that this is
only a convention and is not enforced in any way. *
This means:
- A caller can technically pass *anything* as the first token.
- A process created via CreateProcess can have an arbitrary lpCommandLine .
- argv[0] may not be the absolute path.
- It may not even be a valid path at all.
This is why portable code should not assume argv[0] is the executable path.
---
# **Cross‑Platform Note**
The C standard does **not** guarantee that argv[0] contains the program name — only that it exists.
This is echoed in the search results:
- * In short: No... this is more of a common convention than a strict rule. *
---
# **Final Summary**
| Question | Answer |
|------------------------------------------------------|------------------------------------------|
| **Does Windows guarantee argc >= 1 ?** | **Yes — if using MSVC’s C runtime.** |
| **Is argv[0] guaranteed to exist?** | **Yes — with MSVC.** |
| **Is argv[0] guaranteed to be the absolute path?** | **No.** |
| **Does Windows enforce any of this?** | **No — it’s the C runtime, not the OS.** |
If you need the *actual* executable path, use:
- GetModuleFileName(NULL, ...) (Windows API)
---
https://learn.microsoft.com/en-us/cpp/c-language/argument-description?view=msvc-170&utm_source=copilot.com
https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&utm_source=copilot.com
https://github-wiki-see.page/m/johnstevenson/winbox-args/wiki/How-Windows-parses-the-command-line?utm_source=copilot.com
https://www.codegenes.net/blog/is-argv-0-name-of-executable-an-accepted-standard-or-just-a-common-convention/?utm_source=copilot.com
When argv[0] Isn’t the Executable Name
4.1 Invocation via exec Functions
4.2 Symbolic Links
4.3 Shell Scripts and Aliases
4.4 Debuggers, Emulators, and Special Environments
********** End CoPilot Answer ************
Paul
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2025-12-31 18:42 +0000 |
| Message-ID | <10j3qr4$2p2od$1@dont-email.me> |
| In reply to | #396030 |
On 31/12/2025 17:30, Paul wrote: > On Tue, 12/30/2025 10:37 PM, Keith Thompson wrote: >> Lawrence D’Oliveiro <ldo@nz.invalid> writes: >>> 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. >> >> That's not clear. Linux (since 2022) guarantees argc>=1. I don't >> know whether Windows makes a similar guarantee, but it's entirely >> plausible that it could. >> >> But not all systems guarantee argc>=1, so any portable code shouldn't >> make assumptions beyond what's guaranteed by ISO C. >> > > The Windows guarantee is with MSVC, according to this answer. > > ********** CoPilot Question ********** > > Does the Windows operating system guarantee that argc >= 1 for an EXE program ? > > argv[0] usually contains the program absolute path. > > ********** CoPilot Answer ************ > > Here’s the clear, standards‑grounded, Windows‑specific answer you’re looking for — with citations from the search results. > > # **Short Answer** > **Yes. On Windows, when using the Microsoft C runtime (MSVCRT), argc > is always guaranteed to be ≥ 1**, and ** argv[0] always exists**. > However, **Windows itself does *not* guarantee what argv[0] contains** - > only that the C runtime *treats* it as the program name. > > --- > > # **What Windows Guarantees vs. What the C Runtime Guarantees** > > ### **Microsoft C Runtime Guarantee** > Microsoft’s documentation explicitly states: > > - *“Since the program name is considered an argument, the value of argc is at least one.”* > > So if your EXE is built with MSVC and uses the standard main or wmain , you can rely on: > > - argc >= 1 > - argv[0] is a valid null‑terminated string > - argv[argc] == NULL > > ### **MSVC Startup Code Behavior** > MSVC startup code parses the command line and > **always inserts the program name as argv[0] ** (quoted if needed). > > --- > > # **What Windows *Does Not* Guarantee** > Windows itself does **not** enforce that the first token of the command line > is the executable name. This is a convention, not a rule: > > - * By convention the module name ... is the first argument ... Note that this is > only a convention and is not enforced in any way. * > > This means: > > - A caller can technically pass *anything* as the first token. > - A process created via CreateProcess can have an arbitrary lpCommandLine . > - argv[0] may not be the absolute path. > - It may not even be a valid path at all. > > This is why portable code should not assume argv[0] is the executable path. > > --- > > # **Cross‑Platform Note** > The C standard does **not** guarantee that argv[0] contains the program name — only that it exists. > This is echoed in the search results: > > - * In short: No... this is more of a common convention than a strict rule. * > > --- > > # **Final Summary** > | Question | Answer | > |------------------------------------------------------|------------------------------------------| > | **Does Windows guarantee argc >= 1 ?** | **Yes — if using MSVC’s C runtime.** | > | **Is argv[0] guaranteed to exist?** | **Yes — with MSVC.** | > | **Is argv[0] guaranteed to be the absolute path?** | **No.** | > | **Does Windows enforce any of this?** | **No — it’s the C runtime, not the OS.** | > > If you need the *actual* executable path, use: > > - GetModuleFileName(NULL, ...) (Windows API) > > --- > > https://learn.microsoft.com/en-us/cpp/c-language/argument-description?view=msvc-170&utm_source=copilot.com > > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&utm_source=copilot.com > > https://github-wiki-see.page/m/johnstevenson/winbox-args/wiki/How-Windows-parses-the-command-line?utm_source=copilot.com > > https://www.codegenes.net/blog/is-argv-0-name-of-executable-an-accepted-standard-or-just-a-common-convention/?utm_source=copilot.com > > When argv[0] Isn’t the Executable Name > > 4.1 Invocation via exec Functions > 4.2 Symbolic Links > 4.3 Shell Scripts and Aliases > 4.4 Debuggers, Emulators, and Special Environments > > ********** End CoPilot Answer ************ So is that a Yes or No? My C compiler calls __getmainargs() in msvcrt.dll to get argc/argv. __getmainargs() is also imported by programs compiled with Tiny C, and also with gcc 14.x from winlibs.com. (I assume it is actually called for the same purpose.) The specs for __getmainargs() say that the returned argc value is always >= 1. (I doubt whether msvcrt.dll, which is present because so many programs rely on it, is what is used by MSVC-compiled appls, but you'd have to look inside such an app to check. EXEs inside \windows\system tend to import DLLs with names like "api-ms-win...".) 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().)
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2025-12-31 15:07 -0500 |
| Message-ID | <10j3vp9$2rgfl$1@dont-email.me> |
| In reply to | #396031 |
On Wed, 12/31/2025 1:42 PM, bart wrote: > So is that a Yes or No? > > My C compiler calls __getmainargs() in msvcrt.dll to get argc/argv. > > __getmainargs() is also imported by programs compiled with Tiny C, and also with gcc 14.x from winlibs.com. (I assume it is actually called for the same purpose.) > > The specs for __getmainargs() say that the returned argc value is always >= 1. > > (I doubt whether msvcrt.dll, which is present because so many programs rely on it, is what is used by MSVC-compiled appls, but you'd have to look inside such an app to check. EXEs inside \windows\system tend to import DLLs with names like "api-ms-win...".) > > 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().) The answer says "with MSVC". And your usage of msvcrt.dll likely applies to that statement. If you wrote your own version of a runtime msvcrt.dll then the answer could be no or maybe. I think if you're sufficiently clever, you can break that. But for the most part, lots of regular/lazy programming efforts will be guaranteeing a good result. I've used the argv[0] to determine the role of a program (encoder or decoder mode), and I'm just a very bad hobby programmer. Windows is pretty careless with metadata. In twenty years of watching Windows, I watched a program lose its name, and also one which had no parent. I thought when a program lost a parent that System() would own it. But when I checked, not even System was the parent. The parent was nothing. And Windows seemingly does not kill items malformed in that way. (The root cause may have been a RAM error, but I cannot be sure.) If you look in Task Manager in W10/W11, you cannot see Memory Compressor. If you use tasklist /V in a Terminal, then you can see it. That is just so you can contrast that with the behavior of Task Manager. And if you use Sysinternals (bought by Microsoft) Process Explorer utility, if you check Properties on Memory Compressor (even as administrator), no metadata is visible and the status says something about a necessary device is not responding. As if someone launched that in a particular way so it would be orphaned on purpose. But this is Windows for you. That's how you do things there. Paul Paul
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2025-12-31 22:18 +0200 |
| Message-ID | <20251231221830.00007e87@yahoo.com> |
| In reply to | #396031 |
On Wed, 31 Dec 2025 18:42:45 +0000 bart <bc@freeuk.com> wrote: > On 31/12/2025 17:30, Paul wrote: > > On Tue, 12/30/2025 10:37 PM, Keith Thompson wrote: > >> Lawrence D’Oliveiro <ldo@nz.invalid> writes: > >>> 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. > >> > >> That's not clear. Linux (since 2022) guarantees argc>=1. I don't > >> know whether Windows makes a similar guarantee, but it's entirely > >> plausible that it could. > >> > >> But not all systems guarantee argc>=1, so any portable code > >> shouldn't make assumptions beyond what's guaranteed by ISO C. > >> > > > > The Windows guarantee is with MSVC, according to this answer. > > > > ********** CoPilot Question ********** > > > > Does the Windows operating system guarantee that argc >= 1 for an > > EXE program ? > > > > argv[0] usually contains the program absolute path. > > > > ********** CoPilot Answer ************ > > > > Here’s the clear, standards‑grounded, Windows‑specific answer > > you’re looking for — with citations from the search results. > > > > # **Short Answer** > > **Yes. On Windows, when using the Microsoft C runtime (MSVCRT), argc > > is always guaranteed to be ≥ 1**, and ** argv[0] always > > exists**. However, **Windows itself does *not* guarantee what > > argv[0] contains** - only that the C runtime *treats* it as the > > program name. > > > > --- > > > > # **What Windows Guarantees vs. What the C Runtime Guarantees** > > > > ### **Microsoft C Runtime Guarantee** > > Microsoft’s documentation explicitly states: > > > > - *“Since the program name is considered an argument, the value of > > argc is at least one.”* > > > > So if your EXE is built with MSVC and uses the standard main or > > wmain , you can rely on: > > > > - argc >= 1 > > - argv[0] is a valid null‑terminated string > > - argv[argc] == NULL > > > > ### **MSVC Startup Code Behavior** > > MSVC startup code parses the command line and > > **always inserts the program name as argv[0] ** (quoted if > > needed). > > > > --- > > > > # **What Windows *Does Not* Guarantee** > > Windows itself does **not** enforce that the first token of the > > command line is the executable name. This is a convention, not a > > rule: > > > > - * By convention the module name ... is the first argument ... > > Note that this is only a convention and is not enforced in any way. > > * > > > > This means: > > > > - A caller can technically pass *anything* as the first token. > > - A process created via CreateProcess can have an arbitrary > > lpCommandLine . > > - argv[0] may not be the absolute path. > > - It may not even be a valid path at all. > > > > This is why portable code should not assume argv[0] is the > > executable path. > > > > --- > > > > # **Cross‑Platform Note** > > The C standard does **not** guarantee that argv[0] contains the > > program name — only that it exists. This is echoed in the search > > results: > > > > - * In short: No... this is more of a common convention than a > > strict rule. * > > > > --- > > > > # **Final Summary** > > | Question | Answer > > | > > |------------------------------------------------------|------------------------------------------| > > | **Does Windows guarantee argc >= 1 ?** | **Yes — if > > using MSVC’s C runtime.** | | **Is argv[0] guaranteed to > > exist?** | **Yes — with MSVC.** > > | | **Is argv[0] guaranteed to be the absolute path?** | **No.** > > | | **Does Windows enforce any of > > this?** | **No — it’s the C runtime, not the OS.** | > > > > If you need the *actual* executable path, use: > > > > - GetModuleFileName(NULL, ...) (Windows API) > > > > --- > > > > https://learn.microsoft.com/en-us/cpp/c-language/argument-description?view=msvc-170&utm_source=copilot.com > > > > https://learn.microsoft.com/en-us/cpp/c-language/parsing-c-command-line-arguments?view=msvc-170&utm_source=copilot.com > > > > https://github-wiki-see.page/m/johnstevenson/winbox-args/wiki/How-Windows-parses-the-command-line?utm_source=copilot.com > > > > https://www.codegenes.net/blog/is-argv-0-name-of-executable-an-accepted-standard-or-just-a-common-convention/?utm_source=copilot.com > > > > When argv[0] Isn’t the Executable Name > > > > 4.1 Invocation via exec Functions > > 4.2 Symbolic Links > > 4.3 Shell Scripts and Aliases > > 4.4 Debuggers, Emulators, and Special Environments > > > > ********** End CoPilot Answer ************ > > So is that a Yes or No? > > My C compiler calls __getmainargs() in msvcrt.dll to get argc/argv. > > __getmainargs() is also imported by programs compiled with Tiny C, > and also with gcc 14.x from winlibs.com. (I assume it is actually > called for the same purpose.) > > The specs for __getmainargs() say that the returned argc value is > always > >= 1. > > (I doubt whether msvcrt.dll, which is present because so many > programs rely on it, is what is used by MSVC-compiled appls, but > you'd have to look inside such an app to check. EXEs inside > \windows\system tend to import DLLs with names like "api-ms-win...".) > > 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().) I experimented a little with CreateProcess() in caller (parent) and GetCommandLine() in callee (child). It seems that [under Windows] it is impossible to pass empty command line to child process. It makes no difference whether lpCommandLine argument of CreateProcess() call is NULL or "". In both cases the OS fills command line of the child with copy of lpApplicationName parameter. What *is* possible is passing of command line parameter that contains one or several white spaces. How compiler/start up code interprets such command line depends on specific compiler/start up code. If, like in your case, start up code is borrowed from Microsoft, then such command line is interpreted as (argc = 1; argv[0] = ""; argv[1] = NULL). I would guess that any start up code that is based on CommandLineToArgvW() syscall will deliver the same result. Of course, there are other possible choices as well. As mentioned up thread, as far as C Standard is concerned, argc=0 is also legal. But not using Microsoft's utilities sounds like plenty of extra work for non-obvious gain.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-12-31 20:55 +0000 |
| Message-ID | <10j42kv$2s72e$6@dont-email.me> |
| In reply to | #396031 |
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.
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web