hexump.c

[Richard Damon]

One thing you should consider is that the beginner must begin with
simple programs, not highly secured programs designed to run a simple
hex dump utility in a 100% secure environment. There is NO point in
making hexdump.c more complex than it is already.

I feel that in a beginning programming course, it is important to teach
the students "safe" techniques, and to test for the needed error
conditions. Maybe the *first* program with input they aren't made (or
taught) the needed error checks, but then the next lesson should be
giving that program input that breaks it and how to protect from it.

Maybe then they can be taught that if they KNOW that they control the
input, then they can be a bit relaxed in checking.

Note that not all errors need to be tested. For instance, in the
canonical "Hello World" program, you could add a test for error in the
output, but what would the program do, if output is broken it isn't
going to be able to output an error message. If in the presence of the
error, the program can continue and not get into more trouble, then
ignoring the error can be reasonable. But if they learn to THINK about
error conditions early, they might not forget as often when it is really
needed.

 

[BartC]

I am not so sure of that. C is still with us. I'd like to think you
are right but I'd bet the other way even so.

C will be around. I meant the individual could have moved on to something
else. (Of course that still leaves any source code he may have written which
may or may not still need to work twenty years later, perhaps on very
different hardware.

But, quite often you *are* only interested in a short-term results, and it's
quite possible that older application would need rewriting anyway ten years
later, as software gets outdated even if it still works. Or you just emulate
the older system.)

If C is still around, the future of CPU architecture is unpredictable.
Designers of ultra-high performance graphics chips or of fast low-power
chips for embedding in your brain stem (or whatever really happens in
2044[1]) may have to make radically different choices.

[1] I first wrote a program in 1978, so someone starting now may well be
programming in 2044. Consider what's happened in those 33 years and try
to hazard a guess as to what will be happening in 2044.

(My first programs were in 1976, as a student. Some of them used punched
cards. Just five years later, I was programming something entirely
different. I wouldn't like to predict what might be happening in 2046.)

 

[James Kuyper]

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.

 

[jacob navia]

Le 14/09/11 18:54, Kenneth Brody a écrit :

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.

You said it is easier to learn "the right way" and system specific
extensions later, what implies that you consider using argv[0] as a
"system specific extension". Nice that you say that that isn't the case

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.

That is not true, MSDOS sets the value of argv[0] to the name of the
program since MSDOS 3.0, introduced in 1984! That is 27 YEARS ago.

Urban legends. Yes, I should (in a beginners program in 2011) take care
that one of the students uses an msdos version that is older than 27
years. Note that my question was

"... EXISTING system..."

and you come up with MSDOS 2.0, from 1983. GREAT!

 

[jacob navia]

Le 14/09/11 19:26, James Kuyper a écrit :

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

 

[jameskuyper]

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.

 

[Seebs]

I'm not necessarily saying that a tutorial intended for beginners needs
to check for every possibility; assuming that argv[0] != NULL might be
reasonable in that context. But in code that's intended to be robust, a
test is worth the effort, perhaps something like:

const char *const program_name = argv[0] ? argv[0] : "<program>";
fprintf(stderr, "Usage: %s <filename>\n", program_name);

Me, I'd probably just not use argv[0], and use "<program>" in the string,
on the grounds that the tutorial program will be easy enough for the user
to work with, and they'll know what they're invoking. Getting the program
name in there is a cosmetic detail.

-s

 

[Seebs]

And once again, jacob, you take a technical discussion and turn it into
a personal attack. For the Nth time, what is your problem?

He seems really quick to take offense, and I've never quite understood why.
Not to dispute that there have been clear examples of people harassing him,
but he seems convinced that all technical disagreements are attempts to
discredit him.

I just assume it's a pretty much textbook case of pathological narcissism,
and I plonked him for it some time ago. He's got some great ideas, but
they're all hidden behind a wall of becoming bound and determined to prove
people wrong no matter what if they disagree with him.

-s

 

[Keith Thompson]

Le 14/09/11 12:40, BartC a écrit :

This obsession with portability reaches here new heights...

Programs must be written (by beginners) such that they run still
unmodified in 20 years, so the children of the students can peek into
their father's homework and copy it unmodified.

That's not what I wrote. It barely even resembles what I wrote.

I even explicitly acknowledged that it might be appropriate to
ignore the issue of whether argv[0] can be null in a tutorial.

The point is not for a little program to be usable without change
20 years later. (But if you *can* easily write it so it's usable
years later, why not do it?)

The point is that the language has a standard, and it has a standard
for good reasons. You seem to be advocating ignoring the parts of
the standard that don't fit into your idea of how implementations
happen to work in 2011.

Should we throw away the parts of the standard that don't happen
to apply to the implementations that most people use today?
Would you like to publish a revised C standard that guarantees that
argv[0] != NULL? That CHAR_BIT==8? That INT_MAX >= 0x7FFFFFFF?
That INT_MAX == 0x7FFFFFFF? That all pointers have the same
size and representation? That a null pointer is all-bits-zero?
That the address space is linear and monolithic? That pointers to
distinct object can meaningfully be compared?

That the underlying architecture is x86?

Does the very idea of checking whether argv[0] == NULL offend you?

[snip ad-hominem nonsense]

Of course you can write non-portable code in C. That's one of the
languages greetest strengths, that you can get close the hardware
and write code that does what it needs to do. But I think it's
important to be aware of when you're writing portable code (by which
I mean code that depends only on what's guaranteed by the language
standard) and when you're writing non-portable code.

Now, jacob, feel free to quote me out of context, misinterpret what
I wrote, and personally insult me for no apparent reason.

 

[jacob navia]

Le 14/09/11 20:33, jameskuyper a écrit :

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!

 

[jacob navia]

Le 14/09/11 21:22, Jens Gustedt a écrit :

Am 09/14/2011 08:35 PM, schrieb Keith Thompson:

Your patience with him is just admirable

I personally just find his attitude somewhere between annoying and
disgusting.

And I have impression that his problem is not with you but of a more
general nature.

Jens

Yes, it is a longer story. Years of supporting insults from him and
heathfield.

He and his band of "regulars". All my posts are polluted by this people.

I have been patient too long. Now I just do not want that they
participate in the discussions I start. He, Seebs, Kuyper, all of them.

 

[Ian Collins]

Le 14/09/11 21:22, Jens Gustedt a écrit :

Yes, it is a longer story. Years of supporting insults from him and
heathfield.

I've been following this group for a number of years (probably too
many...) and in that time I don't think I've ever seen Keith insult you
or anyone else. Care to cite an example?

 

[jacob navia]

Le 14/09/11 21:16, Keith Thompson a écrit :

The point is that the language has a standard, and it has a standard
for good reasons.

HYPOCRITE

1. a person who pretends to have virtues, moral or religious beliefs,
principles, etc., that he or she does not actually possess, especially
a person whose actions belie stated beliefs.

2. A person who feigns some desirable or publicly approved attitude,
especially one whose private life, opinions, or statements belie his or
her public statements.

http://dictionary.reference.com/browse/hypocrite

Thompson and heathfield rejected the 1999 C standard in countless
posts from 1999 to last year or maybe even today.

When I posted here code that was conforming to the C99 standard
they would again and again point out that "it is not portable since no
implementations exists", even if many implementation appeared
during all this years. They always again and again said that the only
standard C they accepted was C 1989, the only "portable" C.

They never ( of course) posted any code.

Of course this doesn't bother them now, since most people that
participated in those discussions have left this group.

Now they start posing with phrases like the one above.

 

[jacob navia]

Le 14/09/11 21:32, Ian Collins a écrit :

I've been following this group for a number of years (probably too
many...) and in that time I don't think I've ever seen Keith insult you
or anyone else. Care to cite an example?

No, Heathfield and co never insulted directly.

They let other people do that work and then they would aprove those
posts, never saying a word against the people that insulted.

Thompson is too mean to directly insult anyone. He just will implicitely
approve insults.

The only time where he insulted me was when I proposed him to jointly
write a proposal to the standard committee about integer overflow.

That was too much for him.

 

[Keith Thompson]

Le 14/09/11 14:31, Nobody a écrit:

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

Yes. I just ran the following program:

#include <stdio.h>
int main(int argc, char **argv) {
for (int i = 0; i <= argc; i ++) {
printf("argv[%d] = ", i);
if (argv == NULL) {
printf("NULL\n");
}
else {
printf("\"%s\"\n", argv);
}
}
return 0;
}

and it gave me this output:

argv[0] = NULL

I just ran it again and got this output:

argv[0] = "argv[0] is a lie"
argv[1] = NULL

Why? Because I invoked it from a 6-line C program that uses execv().

Unless running a script (a file beginning with "#!"), Unix sets argv to
exactly what is passed to execve(). If you execute a program with:

char *arg0 = NULL;
execve("foo",&arg0, environ);

the resulting program will have "argc == 0&& argv[0] == NULL".

Setting argv[0] to the name of the program is only a convention, not
something which is enforced by the kernel.

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.

Most zip/unzip programs are only one program. They look at argv[0]
to see if they should be unzipping or zipping.

Perhaps so. info-zip, the default version on Ubuntu, has separate
executables for zip and unzip. But grep is a good example -- and
at least the GNU version of grep has an explicit check; if argv[0]
== NULL; it reports it as a bug and aborts. (At least there's code
to do that; I'm not certain that it's actually used.) I suspect
that most Unix/Linux programs that care abaout the value of argv[0]
do something similar.

There is no system that doesn't set argv[0] to the name of the program.

It depends on how you invoke the program. And I wouldn't bet a lot
on the assumption that "the name of the program" is a name that can be
used to invoke it.

I added a guard (if (argv[0]) in the program as presented in the
exercise.

Good for you. We pointed out the possibility that argv[0] isn't
necessarily non-null and you changed the program to allow for it.

So why are you still whining about it?

One thing you should consider is that the beginner must begin with
simple programs, not highly secured programs designed to run a simple
hex dump utility in a 100% secure environment. There is NO point in
making hexdump.c more complex than it is already.

Then why did you change it? I'm glad you did, but it seems
inconsistent with what you've been saying.

 

[Seebs]

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

 

[Keith Thompson]

No, Heathfield and co never insulted directly.

What does Richard Heathfield have to do with this?

They let other people do that work and then they would aprove those
posts, never saying a word against the people that insulted.

That is a lie. There is an occasional troll who goes by the name of
"teapot" or "why tea" or something like that (it varies) who specializes
in insulting you and your compiler. I have flamed him for doing that,
as did most of the regulars at the time.

Thompson is too mean to directly insult anyone. He just will implicitely
approve insults.

The only time where he insulted me was when I proposed him to jointly
write a proposal to the standard committee about integer overflow.

That was too much for him.

That's not how it happened.

I insulted you (yes, it was an insult, and yes, it
was deliberate) in direct response to the multiple
unwarranted insults that you had directed against me.
See message <[email protected]>, available at
<http://groups.google.com/group/comp.lang.c/msg/162de225171f97b8>.

That was just over two years ago, and you're still whining about it.
Typical.

 

[Alan Curry]

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.

Jacob seems to have the better assessment of reality here. Many good
programmers don't adequately defend against the argv[0]=0 exec, even in
privileged programs where defensiveness is especially important.

Of course if educational materials omit mention of the argv[0]=0
possibility on the grounds that real programmers don't bother
checking, it becomes a self-perpetuating problem. By the time you
graduate from reading tutorials to reading formal specifications, you've
already developed some habits, and it'd be better if they were good
ones.

 

[Nobody]

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.

 

[James Kuyper]

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?