Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10063 > unrolled thread

hexump.c

Back to article view | Back to comp.lang.c

Contents

  hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 22:53 +0200
    Re: hexump.c tea strainer <nospam@nospam.com> - 2011-09-09 21:06 +0000
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 23:57 +0200
      Re: hexump.c NicStevens <nic.stevens@gmail.com> - 2011-09-12 13:22 -0700
    Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-10 09:18 +1200
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-09 23:59 +0200
    Re: hexump.c Ike Naar <ike@iceland.freeshell.org> - 2011-09-09 22:29 +0000
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 00:39 +0200
        Re: hexump.c Ike Naar <ike@iceland.freeshell.org> - 2011-09-09 22:53 +0000
          Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 00:58 +0200
          Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-13 06:44 +0000
            Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-13 10:33 +0200
              Re: hexump.c Fritz Wuehler <fritz@spamexpire-201109.rodent.frell.theremailer.net> - 2011-09-13 18:02 +0200
              Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-13 16:36 -0400
                Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-13 22:44 +0200
                  Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 13:31 +0100
                    Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 15:27 +0200
                      Re: Teaching C (was Re: hexump.c) Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-14 11:49 -0400
                      Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 13:27 -0700
                        Re: Teaching C (was Re: hexump.c) pacman@kosh.dhis.org (Alan Curry) - 2011-09-14 20:59 +0000
                          Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 22:20 +0100
                          Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-14 17:20 -0400
                            Re: Teaching C (was Re: hexump.c) pacman@kosh.dhis.org (Alan Curry) - 2011-09-15 01:51 +0000
                              Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 19:29 -0700
                          Re: Teaching C (was Re: hexump.c) Keith Thompson <kst-u@mib.org> - 2011-09-14 19:21 -0700
                            Re: Teaching C Ben Pfaff <blp@cs.stanford.edu> - 2011-09-14 19:58 -0700
                              Re: Teaching C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-14 21:55 -0600
                              Re: Teaching C James Kuyper <jameskuyper@verizon.net> - 2011-09-15 06:54 -0400
                                Re: Teaching C Keith Thompson <kst-u@mib.org> - 2011-09-15 11:58 -0700
                                  Re: Teaching C Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 12:57 -0800
                              Re: Teaching C Nobody <nobody@nowhere.com> - 2011-09-15 14:25 +0100
                              Re: Teaching C Seebs <usenet-nospam@seebs.net> - 2011-09-16 22:00 +0000
                  Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-14 12:54 -0400
                    Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-14 13:26 -0400
                      Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 19:33 +0200
                        Re: Teaching C (was Re: hexump.c) jameskuyper <jameskuyper@verizon.net> - 2011-09-14 11:33 -0700
                          Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 21:17 +0200
                            Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-16 11:47 -0400
                          Re: Teaching C (was Re: hexump.c) Seebs <usenet-nospam@seebs.net> - 2011-09-14 20:43 +0000
                        Re: Teaching C (was Re: hexump.c) Nobody <nobody@nowhere.com> - 2011-09-14 22:35 +0100
                        Re: Teaching C (was Re: hexump.c) gordonb.8a7i1@burditt.org (Gordon Burditt) - 2011-09-14 17:31 -0500
                    Re: Teaching C (was Re: hexump.c) jacob navia <jacob@spamsink.net> - 2011-09-14 19:32 +0200
                      Re: Teaching C (was Re: hexump.c) Kenneth Brody <kenbrody@spamcop.net> - 2011-09-16 11:27 -0400
                        Re: Teaching C (was Re: hexump.c) Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-16 08:49 -0700
                          Re: Teaching C (was Re: hexump.c) James Kuyper <jameskuyper@verizon.net> - 2011-09-17 15:04 -0400
              Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-13 20:31 -0700
                Re: hexump.c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-14 03:22 -0700
                Re: hexump.c "BartC" <bc@freeuk.com> - 2011-09-14 11:40 +0100
                  Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 13:54 +0200
                    Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-14 13:50 +0100
                    Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 11:35 -0700
                      Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-14 19:12 +0000
                        Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-14 15:31 -0700
                          Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-15 00:59 +0200
                            Re: hexump.c Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-09-14 23:14 +0000
                            Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-15 08:52 -0700
                      Re: hexump.c Jens Gustedt <jens.gustedt@loria.fr> - 2011-09-14 21:22 +0200
                        Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 21:26 +0200
                          Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-15 07:32 +1200
                            Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-14 21:44 +0200
                              Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 13:49 -0700
                            Re: hexump.c Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-16 00:50 +0300
                              Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-15 18:34 -0700
                    Re: hexump.c Keith Thompson <kst-u@mib.org> - 2011-09-14 12:16 -0700
                      Hypocrites jacob navia <jacob@spamsink.net> - 2011-09-14 21:40 +0200
                        Re: Hypocrites Keith Thompson <kst-u@mib.org> - 2011-09-14 19:11 -0700
                  Re: hexump.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-14 15:05 +0100
                    Re: hexump.c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-09-14 07:56 -0700
                    Re: hexump.c "BartC" <bc@freeuk.com> - 2011-09-14 17:23 +0100
                Re: hexump.c Seebs <usenet-nospam@seebs.net> - 2011-09-14 19:12 +0000
                Re: hexump.c John Bode <jfbode1029@gmail.com> - 2011-09-14 15:24 -0700
        Re: hexump.c gordonb.ik17p@burditt.org (Gordon Burditt) - 2011-09-09 18:16 -0500
          Re: hexump.c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-09-12 22:24 +0000
    Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-09 20:33 -0400
      Re: hexump.c Ian Collins <ian-news@hotmail.com> - 2011-09-10 12:42 +1200
        Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-10 17:16 -0400
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 10:03 +0200
    Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-10 10:04 +0100
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 11:41 +0200
        Re: hexump.c pete <pfiland@mindspring.com> - 2011-09-10 05:51 -0400
          Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 12:38 +0200
            Re: hexump.c Nobody <nobody@nowhere.com> - 2011-09-10 17:53 +0100
    Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 12:46 +0200
      Re: hexump.c Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-10 13:03 +0100
        Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-10 15:34 +0200
      Re: hexump.c "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-10 17:37 -0400
        Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-11 00:10 +0200
          Re: hexump.c Patrick Scheible <kkt@zipcon.net> - 2011-09-10 21:03 -0700
    Re: hexump.c Barry Schwarz <schwarz45@yahoo.com> - 2011-09-11 00:37 -0700
      Re: hexump.c jacob navia <jacob@spamsink.net> - 2011-09-11 13:56 +0200

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#10253 — Re: Teaching C (was Re: hexump.c)

On Wed, 14 Sep 2011 20:59:03 +0000, Alan Curry wrote:

> I've just done this test on several programs. There were many segfaults.
> Several print an angry message about argv[0] being NULL and then abort!
> It seems to be a "you know exactly what you did and you should be
> ashamed of yourself" type of error.
> 
> Most disturbing are the many setuid programs that segfaulted, including
> passwd, mount, and su.

This isn't necessarily problematic. It's important that setuid programs
consider the security implications, but (intentionally) terminating on
SIGSEGV isn't inherently worse than terminating on SIGABRT (i.e.
explicitly calling abort()).

Where it does become a problem is if a program blindly dereferences
argv[0] when it has gotten itself into a position where it /needs/ to
perform clean-up (e.g. once it has created a lock file).

I've seen one setuid program where the startup sequence involved a long
sequence of sanity checks, and any failure would result in an immediate
_exit(). It wouldn't even risk trying to report errors until the sanity
checks were complete.

[toc] | [prev] | [next] | [standalone]

#10254 — Re: Teaching C (was Re: hexump.c)

On 09/14/2011 04:59 PM, Alan Curry wrote:
> In article <lnpqj2amz7.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>> jacob navia <jacob@spamsink.net> writes:
>>>
>>> Yes. So, you can crash probably most Unix programs that way.
>>> So what?
>>
>> No, I don't believe you can.  It will only crash Unix programs that
>> don't blindly assume that argv[0] != NULL.  If you find Unix programs
>> that crash when invoked with argv[0] == NULL, you should consider
>> reporting it as a bug.
> 
> I've just done this test on several programs. There were many segfaults.
> Several print an angry message about argv[0] being NULL and then abort!
> It seems to be a "you know exactly what you did and you should be
> ashamed of yourself" type of error.
> 
> Most disturbing are the many setuid programs that segfaulted, including
> passwd, mount, and su.
> 
> shells: pdksh, bash, and dash were OK. Others segfaulted.

How many programs did you test? How many segfaulted?

[toc] | [prev] | [next] | [standalone]

#10261 — Re: Teaching C (was Re: hexump.c)

In article <4E711A9D.2030501@verizon.net>,
James Kuyper  <jameskuyper@verizon.net> wrote:
>On 09/14/2011 04:59 PM, Alan Curry wrote:
>> 
>> I've just done this test on several programs. There were many segfaults.
>> Several print an angry message about argv[0] being NULL and then abort!
>> It seems to be a "you know exactly what you did and you should be
>> ashamed of yourself" type of error.
>> 
>> Most disturbing are the many setuid programs that segfaulted, including
>> passwd, mount, and su.
>> 
>> shells: pdksh, bash, and dash were OK. Others segfaulted.
>
>How many programs did you test? How many segfaulted?

I only picked a few examples of what I thought should be mature utilties with
a low bug count. Maybe about 20.

Here's a larger survey. Most of the versions are from the current Debian
release. The ratio got a little better as I added more, but crashing is still
a very popular option.

Behaves normally:
  7zr (9.04~dfsg.1-1)
  ar (binutils 2.20.1) [prints help as expected but program name is "(null)"]
  as (binutils 2.20.1)
  bash (4.1.5(1)-release) [$0 expands to "bash"]
  dash (0.5.5.1-7.4) [$0 expands to ""]
  false (coreutils 8.5)
  gpg (1.4.10)
  groff (1.20.1)
  pdksh (5.2.14-25) [$0 expands to "pdksh"]
  sed (4.2.1) [prints help as expected but program name is "(null)"]
  svn (1.6.12)
  true (coreutils 8.5)
  vim (7.2)
  w3m (0.5.2)
  xterm (261)

Segfaults and dies immediately:
  compress (ncompress 4.2.4.3)
  csh (20070713-2)
  cvs (1.12.13)
  ed (1.4)
  gcc (2.95.4, 4.4.5, and others)
  git (1.7.2.5)
  grep (2.5.1, locally modified)
  gzip (1.3.12)
  ksh (Version M 93s+ 2008-01-31)
  ld (binutils 2.20.1)
  less (436)
  man (1.5p)
  mawk (1.3.3)
  more (2.17.2)
  mount (2.17.2)
  nvi (1.81.6)
  passwd (shadow 4.1.4.2+svn3283-2, locally modified)
  pax (from an OpenBSD snapshot, I guess? 1:20090728-1)
  posh (0.8.5)
  su (shadow 4.1.4.2+svn3283-2, locally modified)
  tcsh (6.17.02)
  xboard (4.4.3)
  xz (5.0.0)
  zsh (4.3.10)

Segfaults, catches the signal, prints its own substitute for the standard
"Segmentation fault" message:
  bzip2 (1.0.5)
  gawk (3.1.7)
  unzip (6.00)

Complains specifically about argv[0] and aborts:
  cat, cp, ln, ls, mv (coreutils 8.5) [and presumably the rest of coreutils]
  diff (diffutils 3.0)
  tar (1.23)

Miscellaneous weird behavior:
  awk (2010-05-23)
    says "(null): no program given" (normal behavior with no arguments is to
    print a brief usage summary)
  nm (binutils 2.20.1)
    just exits 0, like /bin/true. (normal behavior with no arguments is to
    work on a.out)
  perl (5.10.1)
    somehow ends up confusing envp with argv, interprets envp[0] as the name
    of a script, fails to open it. If I create a perl script with that weird
    name, it executes normally, with @ARGV empty and $^X set to the actual
    full path to the perl executable.
  ping (iputils-sss20100418)
    reports that it is pinging hostname "(null)" which has IP address
    0.0.0.0, proceeds to ping it successfully (0.0.0.0 works like localhost)
  zip (3.0)
    if stdout is not a tty, compresses stdin to stdout which is normal
    behavior. If stdout is a tty, complains about attempt to compress to
    tty instead of printing help which would be normal behavior with no
    arguments.

-- 
Alan Curry

[toc] | [prev] | [next] | [standalone]

#10264 — Re: Teaching C (was Re: hexump.c)

pacman@kosh.dhis.org (Alan Curry) writes:
[...]
> Here's a larger survey. Most of the versions are from the current Debian
> release. The ratio got a little better as I added more, but crashing is still
> a very popular option.
>
> Behaves normally:
>   7zr (9.04~dfsg.1-1)
>   ar (binutils 2.20.1) [prints help as expected but program name is "(null)"]
>   as (binutils 2.20.1)
>   bash (4.1.5(1)-release) [$0 expands to "bash"]
>   dash (0.5.5.1-7.4) [$0 expands to ""]
>   false (coreutils 8.5)
>   gpg (1.4.10)
>   groff (1.20.1)
>   pdksh (5.2.14-25) [$0 expands to "pdksh"]
>   sed (4.2.1) [prints help as expected but program name is "(null)"]
>   svn (1.6.12)
>   true (coreutils 8.5)
>   vim (7.2)
>   w3m (0.5.2)
>   xterm (261)
[snip]

The ones that print the program name as "(null)" are probably passing a
null pointer to printf or fprintf.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10263 — Re: Teaching C (was Re: hexump.c)

pacman@kosh.dhis.org (Alan Curry) writes:
> In article <lnpqj2amz7.fsf@nuthaus.mib.org>,
> Keith Thompson  <kst-u@mib.org> wrote:
>>jacob navia <jacob@spamsink.net> writes:
>>>
>>> Yes. So, you can crash probably most Unix programs that way.
>>> So what?
>>
>>No, I don't believe you can.  It will only crash Unix programs that
>>don't blindly assume that argv[0] != NULL.  If you find Unix programs
>>that crash when invoked with argv[0] == NULL, you should consider
>>reporting it as a bug.
>
> I've just done this test on several programs. There were many segfaults.
> Several print an angry message about argv[0] being NULL and then abort!
> It seems to be a "you know exactly what you did and you should be
> ashamed of yourself" type of error.
>
> Most disturbing are the many setuid programs that segfaulted, including
> passwd, mount, and su.
>
> shells: pdksh, bash, and dash were OK. Others segfaulted.

That's interesting (and disappointing).  I had guessed that,
since execv() can easily invoke any program with argv[0]==NULL,
most production-quality Unix programs would check argv[0] before
dereferencing it.  Apparently I was mistaken.

I would argue that these programs *should* check argv[0], even if
they respond by aborting with an error message.

I wonder if there's any real security issue involved here.  I suspect
there isn't, but I can't be sure.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10266 — Re: Teaching C

Keith Thompson <kst-u@mib.org> writes:

> That's interesting (and disappointing).  I had guessed that,
> since execv() can easily invoke any program with argv[0]==NULL,
> most production-quality Unix programs would check argv[0] before
> dereferencing it.  Apparently I was mistaken.

Under Unix, it's also easy to invoke a program without any file
descriptors at all, so that stdin, stdout, and stderr are all
invalid.  The first fopen() successful call ends up functioning
as stdin, the next as stdout, and the next as stderr.

Few production-quality Unix programs defend against this, because
it's a *really* unconventional way to invoke a program.  No one
(as far as I know) really expects it to be useful to do this.

I think that invoking a program with a null argv[0] is similar,
though perhaps less extreme.  It's not a useful or conventional
thing to do, and so there's not much value in checking carefully
for it.

(It could be a security issue for a setuid program.  Fortunately
there are few of those and they are usually both simple and
carefully written.)
-- 
Ben Pfaff 
http://benpfaff.org

[toc] | [prev] | [next] | [standalone]

#10267 — Re: Teaching C

Ben Pfaff <blp@cs.stanford.edu> writes:
>
> Under Unix, it's also easy to invoke a program without any file
> descriptors at all, so that stdin, stdout, and stderr are all
> invalid.  The first fopen() successful call ends up functioning
> as stdin, the next as stdout, and the next as stderr.
>
> Few production-quality Unix programs defend against this, because
> it's a *really* unconventional way to invoke a program.  No one
> (as far as I know) really expects it to be useful to do this.
>
> I think that invoking a program with a null argv[0] is similar,
> though perhaps less extreme.  It's not a useful or conventional
> thing to do, and so there's not much value in checking carefully
> for it.
>
> (It could be a security issue for a setuid program.  Fortunately
> there are few of those and they are usually both simple and
> carefully written.)

You're right that we just assume correct behavior of argv and the file
descriptors.  But those are *exactly* the assumptions that turn out to
be exploitable -- I don't think I've ever checked the validity of any of
those (I actually thought execve inserted the program name as argv[0]
until checking the man page a moment ago), but clearly this is a problem
with my programs up until now.

You've got a lot more faith in setuid programs than I do....

[toc] | [prev] | [next] | [standalone]

#10275 — Re: Teaching C

On 09/14/2011 10:58 PM, Ben Pfaff wrote:
> Keith Thompson <kst-u@mib.org> writes:
> 
>> That's interesting (and disappointing).  I had guessed that,
>> since execv() can easily invoke any program with argv[0]==NULL,
>> most production-quality Unix programs would check argv[0] before
>> dereferencing it.  Apparently I was mistaken.
> 
> Under Unix, it's also easy to invoke a program without any file
> descriptors at all, so that stdin, stdout, and stderr are all
> invalid.  The first fopen() successful call ends up functioning
> as stdin, the next as stdout, and the next as stderr.

I wasn't aware of that option.

There's a key difference here, as far as C is concerned: argc==0 &&
argv[0]==NULL is explicitly permitted by the C standard. Having standard
streams that need to be explicitly opened is not (7.19.3p7).

> Few production-quality Unix programs defend against this, because
> it's a *really* unconventional way to invoke a program.  No one
> (as far as I know) really expects it to be useful to do this.

One standard-conforming way to deal with this would be to open() them in
the start-up code that runs before invoking main(). A more subtle
approach would be to have any use of one of the standard streams
automatically open() the appropriate file descriptor, if it has not
already been open()ed, invisibly to the user.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#10288 — Re: Teaching C

James Kuyper <jameskuyper@verizon.net> writes:
> On 09/14/2011 10:58 PM, Ben Pfaff wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>> 
>>> That's interesting (and disappointing).  I had guessed that,
>>> since execv() can easily invoke any program with argv[0]==NULL,
>>> most production-quality Unix programs would check argv[0] before
>>> dereferencing it.  Apparently I was mistaken.
>> 
>> Under Unix, it's also easy to invoke a program without any file
>> descriptors at all, so that stdin, stdout, and stderr are all
>> invalid.  The first fopen() successful call ends up functioning
>> as stdin, the next as stdout, and the next as stderr.
>
> I wasn't aware of that option.
>
> There's a key difference here, as far as C is concerned: argc==0 &&
> argv[0]==NULL is explicitly permitted by the C standard. Having standard
> streams that need to be explicitly opened is not (7.19.3p7).
[...]

Implementations typically can do all sorts of things that violate the
language standard.  A debugger can modify the values of objects as
the program is running, which clearly violates the requirement that
non-volatile objects retain their last-stored values.  Depending on
the system, it might even be able to modify the code.  Or you can
just shut down the system before the program finishes.

The ability to do this kind of thing isn't generally considered to
render an implementation non-conforming.

The difference, as you say, is that argv[0]==NULL is explicitly
permitted by the C standard, so programs intended to be robust should
check it.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16122 — Re: Teaching C

Keith Thompson <kst-u@mib.org> writes:

> James Kuyper <jameskuyper@verizon.net> writes:
>> On 09/14/2011 10:58 PM, Ben Pfaff wrote:
>>> Keith Thompson <kst-u@mib.org> writes:
>>> 
>>>> That's interesting (and disappointing).  I had guessed that,
>>>> since execv() can easily invoke any program with argv[0]==NULL,
>>>> most production-quality Unix programs would check argv[0] before
>>>> dereferencing it.  Apparently I was mistaken.
>>> 
>>> Under Unix, it's also easy to invoke a program without any file
>>> descriptors at all, so that stdin, stdout, and stderr are all
>>> invalid.  The first fopen() successful call ends up functioning
>>> as stdin, the next as stdout, and the next as stderr.
>>
>> I wasn't aware of that option.
>>
>> There's a key difference here, as far as C is concerned: argc==0 &&
>> argv[0]==NULL is explicitly permitted by the C standard. Having standard
>> streams that need to be explicitly opened is not (7.19.3p7).
> [...]
>
> Implementations typically can do all sorts of things that violate the
> language standard.  A debugger can modify the values of objects as
> the program is running, which clearly violates the requirement that
> non-volatile objects retain their last-stored values.  Depending on
> the system, it might even be able to modify the code.  Or you can
> just shut down the system before the program finishes.
>
> The ability to do this kind of thing isn't generally considered to
> render an implementation non-conforming.  [snip incidental]

That's because those things aren't part of the implementation:  not
debuggers, not operating systems, not physical hardware.  Those things
all fall under the heading of "a data-processing system capable of
supporting a conforming implementation", which is explicitly called
out in section 1 paragraph 2 as outside what the Standard specifies.

[toc] | [prev] | [next] | [standalone]

#10280 — Re: Teaching C

On Wed, 14 Sep 2011 19:58:32 -0700, Ben Pfaff wrote:

> Under Unix, it's also easy to invoke a program without any file
> descriptors at all, so that stdin, stdout, and stderr are all
> invalid.  The first fopen() successful call ends up functioning
> as stdin, the next as stdout, and the next as stderr.

Linux traps this for setuid/setgid programs; if any of the standard
descriptors are closed, it open()s /dev/null.

[toc] | [prev] | [next] | [standalone]

#10358 — Re: Teaching C

On 2011-09-15, Ben Pfaff <blp@cs.stanford.edu> wrote:
> Under Unix, it's also easy to invoke a program without any file
> descriptors at all, so that stdin, stdout, and stderr are all
> invalid.  The first fopen() successful call ends up functioning
> as stdin, the next as stdout, and the next as stderr.

I have been bitten by a close relative of this, which caused one of
several client connections to a server, quasi-randomly, to end up getting
diagnostic messages under some circumstances.  (Not mine, which were
correctly moving to the selected log file, but glibc's malloc error
detection code, which uses fd 2 no matter what you've done.)

> Few production-quality Unix programs defend against this, because
> it's a *really* unconventional way to invoke a program.  No one
> (as far as I know) really expects it to be useful to do this.

I'm not sure I've ever seen it actually done on purpose.  But I've seen
stuff defend against it at least in part.

> (It could be a security issue for a setuid program.  Fortunately
> there are few of those and they are usually both simple and
> carefully written.)

You are an optimist.  :)

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#10231 — Re: Teaching C (was Re: hexump.c)

On 9/13/2011 4:44 PM, jacob navia wrote:
> Le 13/09/11 22:36, Kenneth Brody a écrit :
>
>> I think all classes on C programming should be taught on the DS-9000,
>> unless you are specifically teaching "Brand X's C compiler". It's a lot
>> easier to learn "the right way" first and then learn system-specific
>> extensions, than it is to learn system-specific extensions and then
>> "unlearn" them when working on other platforms.
>>
>
> 1) argv[0] is a system specific extension ???? That would be news to me.

I never said it was.  Someone else said:

>> I think there was some system with the convention that argc = 0 meant
>> that argv[1] was a pointer to a system-specific magical structure that
>> had information about a GUI invocation or something to that effect.


> 2) Can you tell me of an EXISTING system that sets argv[0] to anything
> else than the name of the program?

Under MS-DOS, argv[0] used to always be "C", as the program's name was not 
passed to the program.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#10233 — Re: Teaching C (was Re: hexump.c)

On 09/14/2011 12:54 PM, Kenneth Brody wrote:
> On 9/13/2011 4:44 PM, jacob navia wrote:
>> Le 13/09/11 22:36, Kenneth Brody a écrit :
>>
>>> I think all classes on C programming should be taught on the DS-9000,
>>> unless you are specifically teaching "Brand X's C compiler". It's a lot
>>> easier to learn "the right way" first and then learn system-specific
>>> extensions, than it is to learn system-specific extensions and then
>>> "unlearn" them when working on other platforms.
>>>
>>
>> 1) argv[0] is a system specific extension ???? That would be news to me.
> 
> I never said it was. ...

argv[0] is not itself a system specific extension. However, whether or
not it points at a string containing the name of the program is system
specific.

[toc] | [prev] | [next] | [standalone]

#10235 — Re: Teaching C (was Re: hexump.c)

Le 14/09/11 19:26, James Kuyper a écrit :
> On 09/14/2011 12:54 PM, Kenneth Brody wrote:
>> On 9/13/2011 4:44 PM, jacob navia wrote:
>>> Le 13/09/11 22:36, Kenneth Brody a écrit :
>>>
>>>> I think all classes on C programming should be taught on the DS-9000,
>>>> unless you are specifically teaching "Brand X's C compiler". It's a lot
>>>> easier to learn "the right way" first and then learn system-specific
>>>> extensions, than it is to learn system-specific extensions and then
>>>> "unlearn" them when working on other platforms.
>>>>
>>>
>>> 1) argv[0] is a system specific extension ???? That would be news to me.
>>
>> I never said it was. ...
>
> argv[0] is not itself a system specific extension. However, whether or
> not it points at a string containing the name of the program is system
> specific.

Do you know of an existing system that doesn't set argv[0] to the name
of the program?

ANY EXAMPLE?

Thanks

[toc] | [prev] | [next] | [standalone]

#10237 — Re: Teaching C (was Re: hexump.c)

jacob navia wrote:
> Le 14/09/11 19:26, James Kuyper a �crit :
...
> > argv[0] is not itself a system specific extension. However, whether or
> > not it points at a string containing the name of the program is system
> > specific.
>
> Do you know of an existing system that doesn't set argv[0] to the name
> of the program?
>
> ANY EXAMPLE?

You've been given several already; how many more do you need?

One case that I can vouch for personally is that a program launched on
a unix-like system through a call to one of the exec* or posix_spawn*
family of functions (and I believe that almost all programs on such
systems are ultimately launched by such calls) obeys the convention of
providing the program names as argv[0] only at the whim of the caller
of those functions. The convention is not enforced by the operating
system. The convention is followed by all of the common shells and
file browsing GUIs, and by the system() function, but there's nothing
preventing uncommon programs from launching programs while providing
unconventional values for argv[0].

Other people have reported two cases that I can't vouch for:

Under MS-DOS, argv[0] was "C". That sounds familiar, but I haven't
programmed for MS-DOS in three decades, so I can't be sure.

On an unspecified system, argc=0 was used to indicate that argv[1]
pointed at "a system-specific magical structure that had information
about a GUI invocation". You response to being so informed was "WHO
CARES?". That response implicitly acknowledges it as an example, while
simultaneously dismissing it as an unimportant example.

Importance is an inherently subjective issue, and I'm sure that you're
telling the truth when you say that the cases where argv[0] does not
point to the name of the program are not important - to YOU. However,
that doesn't justify implying that they don't exist.

[toc] | [prev] | [next] | [standalone]

#10241 — Re: Teaching C (was Re: hexump.c)

Le 14/09/11 20:33, jameskuyper a écrit :
> jacob navia wrote:
>> Le 14/09/11 19:26, James Kuyper a �crit :
> ...
>>> argv[0] is not itself a system specific extension. However, whether or
>>> not it points at a string containing the name of the program is system
>>> specific.
>>
>> Do you know of an existing system that doesn't set argv[0] to the name
>> of the program?
>>
>> ANY EXAMPLE?
>
> You've been given several already; how many more do you need?
>

Yes. One was MSDOS 2.0 from 1983. The other is an invention of yours.
(Unless you are speaking about the unknown system of unknown date
cited by Seebs I think)

> One case that I can vouch for personally is that a program launched on
> a unix-like system through a call to one of the exec* or posix_spawn*
> family of functions (and I believe that almost all programs on such
> systems are ultimately launched by such calls) obeys the convention of
> providing the program names as argv[0] only at the whim of the caller
> of those functions. The convention is not enforced by the operating
> system. The convention is followed by all of the common shells and
> file browsing GUIs, and by the system() function, but there's nothing
> preventing uncommon programs from launching programs while providing
> unconventional values for argv[0].
>

Yes of course. So what?  You can probably make any utility crash.

Why should that be a problem with a utility that is designed to be
called from the command line?


> Other people have reported two cases that I can't vouch for:
>
> Under MS-DOS, argv[0] was "C". That sounds familiar, but I haven't
> programmed for MS-DOS in three decades, so I can't be sure.
>

It shows. That is true for MSDOS 2.0 (1983). Up from MSDOS 3.0 (1984)
argv[0] contains the name of the program.


Why should beginners care about MSDOS prior to MSDOS 3.0?

> On an unspecified system, argc=0 was used to indicate that argv[1]
> pointed at "a system-specific magical structure that had information
> about a GUI invocation". You response to being so informed was "WHO
> CARES?". That response implicitly acknowledges it as an example, while
> simultaneously dismissing it as an unimportant example.
>

An unspecified system with an unspecified date.

Who cares about those urban legends really?


> Importance is an inherently subjective issue, and I'm sure that you're
> telling the truth when you say that the cases where argv[0] does not
> point to the name of the program are not important - to YOU. However,
> that doesn't justify implying that they don't exist.

They do not exist. They existed in  1983, and maybe there is somewhere a 
coffee machine running MSDOS 1.0 where argv[0] points to the number
of cups of coffe in store.

Ahhhh the regulars....

UNABLE to back up their portability issues with afew FACTS!

[toc] | [prev] | [next] | [standalone]

#10332 — Re: Teaching C (was Re: hexump.c)

On 9/14/2011 3:17 PM, jacob navia wrote:
> Le 14/09/11 20:33, jameskuyper a écrit :
[...]
>> Under MS-DOS, argv[0] was "C". That sounds familiar, but I haven't
>> programmed for MS-DOS in three decades, so I can't be sure.
>
> It shows. That is true for MSDOS 2.0 (1983). Up from MSDOS 3.0 (1984)
> argv[0] contains the name of the program.

Nit:

The O/S made the name of the program available to the program.  Whether of 
not a particular C implementation chose to use this information and pass it 
to main() as argv[0] is a separate issue.

[...]
>> Importance is an inherently subjective issue, and I'm sure that you're
>> telling the truth when you say that the cases where argv[0] does not
>> point to the name of the program are not important - to YOU. However,
>> that doesn't justify implying that they don't exist.
>
> They do not exist. They existed in 1983, and maybe there is somewhere a
> coffee machine running MSDOS 1.0 where argv[0] points to the number
> of cups of coffe in store.
>
> Ahhhh the regulars....
>
> UNABLE to back up their portability issues with afew FACTS!

Hmm...  Here is the output from a current Linux box:

==========
[ken@vws0100 /tmp]$ cat parent.c
#include <stdio.h>
#include <unistd.h>

char *child_args[] = {
         "There are 37 cups of coffee.",
         "foo",
         "bar",
         NULL
         };

int main(argc,argv)
         int argc;
         char *argv[];
         {
         printf("Parent calling child...\n");
         execve("./child",child_args,NULL);
         }
[ken@vws0100 /tmp]$ cat child.c
#include <stdio.h>

int main(argc,argv)
         int argc;
         char *argv[];
         {
         int i;
         for ( i=0 ; i < argc ; i++ )
                 {
                 printf("argv[%d] = \"%s\"\n",i,argv[i]);
                 }
         exit(0);
         }
[ken@vws0100 /tmp]$ ./child foo bar
argv[0] = "./child"
argv[1] = "foo"
argv[2] = "bar"
[ken@vws0100 /tmp]$ ./parent
Parent calling child...
argv[0] = "There are 37 cups of coffee."
argv[1] = "foo"
argv[2] = "bar"
[ken@vws0100 /tmp]$
==========

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#10251 — Re: Teaching C (was Re: hexump.c)

On 2011-09-14, jameskuyper <jameskuyper@verizon.net> wrote:
> On an unspecified system, argc=0 was used to indicate that argv[1]
> pointed at "a system-specific magical structure that had information
> about a GUI invocation". You response to being so informed was "WHO
> CARES?". That response implicitly acknowledges it as an example, while
> simultaneously dismissing it as an unimportant example.

Someone else suggests it was an Amigaism.  Arguably a mostly-dead platform,
but they're still making them and updating the OS.

I probably have the details wrong, looking them up now.  Definitely, argc = 0
was used for non-command-line invocation.

Looks like I was wrong; the system's sort of non-conforming, and argv itself
is a pointer to the workbench startup message for GUI invocations.  That's:

    struct WBStartup
    {
        struct Message   sm_Message;    /* a standard message structure */
        struct MsgPort * sm_Process;    /* process descriptor for you */
        BPTR             sm_Segment;    /* a descriptor for your code */
        LONG             sm_NumArgs;    /* number of elements in ArgList */
        char *           sm_ToolWindow; /* reserved for future use */
        struct WBArg *   sm_ArgList;    /* the arguments themselves */
    };

However!  A Message structure starts with a Node, and a Node starts
with a pointer to the next Node, because they can be in linked lists.

So it's quite likely that *in fact*, the first 4 bytes would be all bits
zero, because the message in question isn't in a list.

So the system is probably in-effect conforming, in that argv[argc] == 0.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#10255 — Re: Teaching C (was Re: hexump.c)

On Wed, 14 Sep 2011 19:33:38 +0200, jacob navia wrote:

> Do you know of an existing system that doesn't set argv[0] to the name
> of the program?
> 
> ANY EXAMPLE?

Yes. Every Unix system in existence, as has already been pointed out.

The *system* doesn't set argv[0] to the name of the program. Individual
programs may do this, or they may not.

As a (slight) counter-example, "login" invokes the user's shell with
argv[0] set to the name of the program but with a "-" in front of it (e.g.
"-bash"). By convention, if (argv[0][0] == '-') then the shell is being
invoked as a "login shell", so it should read some combination of
~/.login, ~/.profile, /etc/profile and/or similar implementation-specific
files. Non-login shells don't do this (so that sub-shells inherit the
existing environment, rather than having it reset to its initial state).

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web