elementary construction +1

M

Merrill & Michele

I'm now looking at page 115 K&R. After having discussed counterexamples, I
shall herewith and henceforth make all my c programs look like

int main(int orange, char* apple[])
{return(0);}

Q1) How large is that int and that char*? (My instinct would be to look at
limits.h, but with the main call, I can't figure out to what extent I'm
%inside% C.)

Q2) The example on 115 completely confuses me. That which is printf'ed
looks like a batch file. How would the output change if the e in echo were
omitted? MPJ
 
J

Joona I Palaste

Merrill & Michele said:
I'm now looking at page 115 K&R. After having discussed counterexamples, I
shall herewith and henceforth make all my c programs look like
int main(int orange, char* apple[])
{return(0);}
Q1) How large is that int and that char*? (My instinct would be to look at
limits.h, but with the main call, I can't figure out to what extent I'm
%inside% C.)

It depends what you mean by "large". If you mean how many bytes they
take up, then the sizeof operator is your friend. Try sizeof orange or
sizeof apple.

Question Q2 snipped because I don't have K&R handy at the moment so I
don't know what example you're talking about.
 
M

Michael Mair

Hi there,

I'm now looking at page 115 K&R. After having discussed counterexamples, I
shall herewith and henceforth make all my c programs look like

int main(int orange, char* apple[])
{return(0);}

Q1) How large is that int and that char*? (My instinct would be to look at
limits.h, but with the main call, I can't figure out to what extent I'm
%inside% C.)

Byte: sizeof orange, sizeof *apple
(if you meant apple itself, which equivalently could be declared
as a char **, sizeof apple)

Bit: the above times CHAR_BIT, from <limits.h>

Range: INT_MIN <= orange <= INT_MAX; for pointers, there is no general
pointer range but you are guaranteed a valid range within your
object (that is, apple[0] through apple[orange-1])

Q2) The example on 115 completely confuses me. That which is printf'ed
looks like a batch file. How would the output change if the e in echo were
omitted? MPJ

You are maybe not aware of it but there are translations of K&R to other
languages. For these, the page numbers are not the same. Apart from
that, some of the people who could help you maybe do not even possess
a copy of that book.
It might be better to just copy the example...


Cheers
Michael
 
M

Merrill & Michele

Range: INT_MIN <= orange <= INT_MAX; for pointers, there is no general
pointer range but you are guaranteed a valid range within your
object (that is, apple[0] through apple[orange-1])
That helps. I know that I can use sizeof for my implementation and
determine what holds for my machine. I'm trying to think of a way never to
get stung by a machine whose INT_MIN and INT_MAX I haven't accounted for.
The only thing I can think of right now is to pass argv [] to a
similar-sized matrix with fields the size of INT_MAX.
You are maybe not aware of it but there are translations of K&R to other
languages. For these, the page numbers are not the same. Apart from
that, some of the people who could help you maybe do not even possess
a copy of that book.
It might be better to just copy the example...

Dass unsre Bible nicht Eurer Bibel entspricht ist mir nicht eingefallen. Es
folgt K&R, zweite Ausgabe §5.10 dritter Absatz:

#include <stdio.h>
main(int argc, char *argv[])
{
int i;

for (i=1; i < argc; i++)
print f("%s%s", *++argv; (i < argc-1) ? " " : "");
printf("\n");
return 0;
}

Wir waren neulich bei Euch. Eure Gastfreundschaft ist legendaer. MPJ
 
P

pete

Merrill & Michele wrote:
#include <stdio.h>
main(int argc, char *argv[])
{
int i;

for (i=1; i < argc; i++)
print f("%s%s", *++argv; (i < argc-1) ? " " : "");


printf("%s%s", argv, i < argc - 1 ? " " : "");
printf("\n");
return 0;
}


#include <stdio.h>
main(int argc, char *argv[])
{
while (*++argv != NULL) {
printf("%s ", *argv);
}
putchar('\n');
return 0;
}

Under what conditions does the intial value of argc equal zero?
 
P

Peter Shaggy Haywood

Groovy hepcat Merrill & Michele was jivin' on Fri, 24 Sep 2004
12:41:20 -0500 in comp.lang.c.
elementary construction +1's a cool scene! Dig it!
I'm now looking at page 115 K&R. After having discussed counterexamples, I
shall herewith and henceforth make all my c programs look like

int main(int orange, char* apple[])
{return(0);}

Um..., OK.
Q1) How large is that int and that char*? (My instinct would be to look at

What char*? I don't see any char*. I see a char**. Sure it's
disguised as a char*[], but it's a char** alright. But I see no char*.
limits.h, but with the main call, I can't figure out to what extent I'm
%inside% C.)

What? That doesn't make sense. I have no idea what you're trying to
say.
Q2) The example on 115 completely confuses me. That which is printf'ed

Which one? There are two examples on page 115 (of my copy of K&R
anyhow).
looks like a batch file. How would the output change if the e in echo were
omitted? MPJ

What? What looks like a batch file? What sort of batch file? You
mean a DOS batch language file? In what way does it look like that?
What the hell have you been smoking? What e in what echo?
Oh, I think I see what you mean. On page 114 an example input is
given: "echo hello, world". Actually, the "echo" part is not the input
at all. It's the name of the program. Typing "echo hello, world" at a
command prompt would cause the program echo to output "hello, world".
The two code examples on page 115 are different versions of this echo
program.

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?
 
M

Michael Mair

Cheerio,

Range: INT_MIN <= orange <= INT_MAX; for pointers, there is no general
pointer range but you are guaranteed a valid range within your
object (that is, apple[0] through apple[orange-1])

That helps. I know that I can use sizeof for my implementation and
determine what holds for my machine. I'm trying to think of a way never to
get stung by a machine whose INT_MIN and INT_MAX I haven't accounted for.
The only thing I can think of right now is to pass argv [] to a
similar-sized matrix with fields the size of INT_MAX.

Umh, I do not have the least clue what you are talking about.
argc is either the number of arguments to the program call (including
the program name) or zero. In the first case, I can hardly think
of a program call taking 2^15-1 arguments, aside from the fact that
you probably do not get the command line into the buffer on some
systems. And you really do not want to have a typo or left-out
argument...

Maybe the process of getting from the command line to argc and argv
is not clear to you. I will give a very simple example of how they
_could_ be obtained:
- The shell gets a line and reads to the first white space.
It might use strtok() to put in a '\0' there. Then it looks in
the search path whether it can find an executable of that name.
- If it does, it runs through the rest of the command line obtaining
the number of non-white-space areas (that is, arguments).
- It allocates space for enough char * variables to point to the
start of each argument, that is: argv.
- It runs through the command line and points argv[i++] to the beginning
of the next parameter. Usually you combine that with strtok() to get
in the '\0' after the argument.
- Now, we have the command line still in the same place in memory
but interspersed with several '\0', thus making it into many strings.
argv just contains a pointer to the (i+1)th argument.

You are maybe not aware of it but there are translations of K&R to other
languages. For these, the page numbers are not the same. Apart from
that, some of the people who could help you maybe do not even possess
a copy of that book.
It might be better to just copy the example...

Dass unsre Bible nicht Eurer Bibel entspricht ist mir nicht eingefallen. Es
folgt K&R, zweite Ausgabe §5.10 dritter Absatz:

#include <stdio.h>
main(int argc, char *argv[])
{
int i;

for (i=1; i < argc; i++)
printf("%s%s", *++argv; (i < argc-1) ? " " : "");
printf("\n");
return 0;
}


Hmmm, okay. That does not tell me anything about the echo you have
been asking for. If I understand the posting of Peter Shaggy Haywood
correctly, echo seems to be the name of the program, usually pointed
to by argv[0] if argc>=1. Making this cho would not help as the
program could not be found (of course you could rename it to cho but
that is beside the point.

Is the rest of the program clear to you?

Wir waren neulich bei Euch. Eure Gastfreundschaft ist legendaer.

Pleasant to hear; I was not aware that German hospitality is that
good...


HTH
Michael
 
M

Merrill & Michele

Thanks all for your replies. While my question revealed glaring ignorance,
which was so amply discussed, the thrust of the question dealt with exactly
what argv[] was pointing to. Now that I'm three days wiser, it seems that
argv[0] points to a string with the path and program name in it. "Echo", by
the way, is a terrible name to call the program on K&R 115 because the
person working up his C game has to unlearn a lot of DOS. argv[argc]
points to null. My thinking that I needed to determine the sizes of these
pointers was fundamentally wrong-headed. Who cares how large they are when
you have argc+1 to tell you how many there are.

As for the root of misunderstanding, I am going to cast aspersion on my
implementation. Finally, I'll run Pete's program soon here, as it is likely
quite helpful. Again, thanks all. MPJ
 
P

pete

Merrill said:
Now that I'm three days wiser, it seems that
argv[0] points to a string with the path and program name in it.

It does if argc is positive. What if argc is zero?
Who cares how large they are when
you have argc+1 to tell you how many there are.

(argc + 0) is how many pointers to strings you have.
(argc - 1) is how many parameters you have.
Finally, I'll run Pete's program soon here, as it is likely
quite helpful.

I think that program is missing some code to guard against the
(argc == 0) case.

N869
5.1.2.2.1 Program startup
[#2] If they are declared, the parameters to the main
function shall obey the following constraints:
-- 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 by the host environment
prior to program startup. The intent is to supply to
the program information determined prior to program
startup from elsewhere in the hosted environment. If
the host environment is not capable of supplying
strings with letters in both uppercase and lowercase,
the implementation shall ensure that the strings are
received in lowercase.
-- If the value of argc is greater than zero, the string
pointed to by argv[0] represents the program name;
argv[0][0] shall be the null character if the program
name is not available from the host environment. If
the value of argc is greater than one, the strings
pointed to by argv[1] through argv[argc-1] represent
the program parameters.
-- The parameters argc and argv and the strings pointed to
by the argv array shall be modifiable by the program,
and retain their last-stored values between program
startup and program termination.
 
D

Dan Pop

In said:
Under what conditions does the intial value of argc equal zero?

The program was started with no parameters and its name is not available.
Or the implementation simply does not *meaningfully* support the argc/argv
mechanism:

- 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,...

- If the value of argc is greater than zero, the string pointed
to by argv[0] represents the program name;...

An implementation where argc is *always* zero and argv[0] is a null
pointer trivially satisfies all these requirements.

Dan
 
M

Michael Wojcik

it seems that
argv[0] points to a string with the path and program name in it.

argv[0], if argc > 0, will either be an empty string or the "program
name", which can be whatever the implementation wants it to be. (OT:
on Unix, for example, argv[0] will be whatever string was passed as
the appropriate parameter to one of the exec system calls. That may
be the name of the executable image, and it may have a relative or
absolute path prefixed to it, but in many cases it is not and does
not.)

Many C programs can assume that argv[0] (if argc > 0 and argv[0] is
not an empty string) is suitable to use as the "program name" for
purposes such as labelling messages. For anything beyond that it's
a good idea to examine the contents of argv[0] and apply some
heuristics to see that it appears to be of the form you expect, and
that your code won't do anything wrong with its contents. For
example, don't assume there's any path information (eg by using the
results of the strrchr function to "skip over" the path, without
checking to see if it failed). Don't assume that the contents of
argv[0] are of a reasonable length. And so forth.
"Echo", by
the way, is a terrible name to call the program on K&R 115 because the
person working up his C game has to unlearn a lot of DOS.

You have that backward, if it applies at all. "echo" was a poor name
for an MS-DOS keyword, since it was already used in K&R, which predates
DOS.

A more reasonable statement would be that neither K&R nor MS-DOS have
any exclusive right to the name "echo", and people reading the former
need to avoid making assumptions conditioned by inapplicable domains,
such as what they know of the latter.
argv[argc]
points to null. My thinking that I needed to determine the sizes of these
pointers was fundamentally wrong-headed. Who cares how large they are when
you have argc+1 to tell you how many there are.

And you have argv[argc] to tell you when you've reached the end of
the list, so argc is just frosting on the cake.
 
M

Michael Wojcik

Under what conditions does the intial value of argc equal zero?

Is that a rhetorical question? Under whatever conditions please the
implementation, of course, since the standard only guarantees that
argc be non-negative in a hosted implementation, and not even that in
a freestanding one.

argv might be 0 always, or on Thursdays, or if the program is invoked
in a certain fashion. (The last is true on all POSIX systems, for
example.)

--
Michael Wojcik (e-mail address removed)

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
-- David Bonde
 
P

pete

Dan said:
The program was started with no parameters
and its name is not available.

I know how a program can be started with no parameters,
but besides what you wrote next here:
Or the implementation simply does not
*meaningfully* support the argc/argv mechanism:

I can't think of what else
could cause the program name to be unavailable.
 
C

CBFalconer

pete said:
.... snip ...


I can't think of what else
could cause the program name to be unavailable.

The shell, or whatever OS operation loads the program, simply
fails to make it available. By the time the program begins
execution it is simply a mass of loaded code in memory.
 
P

pete

CBFalconer said:
The shell, or whatever OS operation loads the program, simply
fails to make it available. By the time the program begins
execution it is simply a mass of loaded code in memory.

And you consider that behavior to be within the parameters
of an implementation that *does meaningfully*
support the argc/argv mechanism?
 
D

Dan Pop

In said:
I know how a program can be started with no parameters,
but besides what you wrote next here:


I can't think of what else
could cause the program name to be unavailable.

A lazy Unix programmer didn't bother to provide it when invoking his
favourite exec function to execute the program. Not all programs are
started by one well behaved shell or another. The same mechanism is
used to give arbitrary names to programs.

On certain translation environments there is no obvious program name as
neither the source code nor the executable code resides on an external
file (everything is in memory).

Dan
 
D

Dan Pop

In said:
And you consider that behavior to be within the parameters
of an implementation that *does meaningfully*
support the argc/argv mechanism?

Since it comes from *outside* the implementation, there is nothing the
implementation itself can do about it. All the implementation can do
is obtain this information from the execution environment and make it
available to the program. If the execution environment refuses to
provide the information...

Dan
 
M

Michael Wojcik

And you consider that behavior to be within the parameters
of an implementation that *does meaningfully*
support the argc/argv mechanism?

Yes. In fact, that's how it worked in the first C implementation
that supported argc/argv at all - the original Unix one. And that's
how it continues to work on Unix.

On Unix, whatever causes the program to be executed gets to decide
the entire contents of argv (which in turn decide the value of argc).
That's a central aspect of the execv system call, which in turn is a
core part of the OS. It's quite important to how essentially all
Unix C implementations behave, and a number of programs make use of
it.

So not only is it meaningful, it has a better pedigree than any other
behavior for argc/argv. This isn't one of those "never seen in a
real implementation" cases that occasional visitors to comp.lang.c
like to moan about. Assuming argc > 0 is not a good idea.

--
Michael Wojcik (e-mail address removed)

The history of Namco begins in 1955 when the Company's predecessor
began operating rocking-horse rides on the rooftop of a department
store in Yokohama. Since then, we have pioneered diverse forms of
amusement and entertainment that help people live their dreams. As
we approach the 21st century, an "Era of Spirituality", Namco will
help to spread dynamic entertainment throughout the world.
-- video game producer Namco's English-language Japanese web page
 
M

Merrill & Michele

argv[0], if argc > 0, will either be an empty string or the "program
name", which can be whatever the implementation wants it to be. (OT:
on Unix, for example, argv[0] will be whatever string was passed as
the appropriate parameter to one of the exec system calls. That may
be the name of the executable image, and it may have a relative or
absolute path prefixed to it, but in many cases it is not and does
not.)

Many C programs can assume that argv[0] (if argc > 0 and argv[0] is
not an empty string) is suitable to use as the "program name" for
purposes such as labelling messages. For anything beyond that it's
a good idea to examine the contents of argv[0] and apply some
heuristics to see that it appears to be of the form you expect, and
that your code won't do anything wrong with its contents. For
example, don't assume there's any path information (eg by using the
results of the strrchr function to "skip over" the path, without
checking to see if it failed). Don't assume that the contents of
argv[0] are of a reasonable length. And so forth.

Good tips.

You have that backward, if it applies at all. "echo" was a poor name
for an MS-DOS keyword, since it was already used in K&R, which predates
DOS.

A more reasonable statement would be that neither K&R nor MS-DOS have
any exclusive right to the name "echo", and people reading the former
need to avoid making assumptions conditioned by inapplicable domains,
such as what they know of the latter.

I almost hate to bring up a sentence in paragraph 2 §5.10: "By convention,
argv[0] is the name by which the program was invoked, so argc is at least
1." Doesn't that say something about the relevance of K&R to the argc==0
thread above? At the risk of giving offense, I don't think it too off-base
to look at K&R as the first five books of Moses: extraordinarily important
for, say, pedagogy and exegetics, but not the final word in the modern
world. MPJ
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top