elementary construction +1
Merrill & Michele
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
Joona I Palaste
> 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.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Nothing lasts forever - so why not destroy it now?"
- Quake
Michael Mair
> 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
Merrill & Michele
> pointer range but you are guaranteed a valid range within your
> object (that is, apple[0] through apple[orange-1])
>
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]; (i < argc-1) ? " " : "");
printf("\n");
return 0;
}
Wir waren neulich bei Euch. Eure Gastfreundschaft ist legendaer. MPJ
pete
> #include <stdio.h>
> main(int argc, char *argv[])
> {
> int i;
>
> for (i=1; i < argc; i++)
> print f("%s%s", *++argv[i]; (i < argc-1) ? " " : "");
printf("%s%s", argv[i], 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?
--
pete
Peter Shaggy Haywood
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"?
Michael Mair
>>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[i] 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]; (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
Merrill & Michele
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
pete
> 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.
--
pete
Dan Pop
>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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Currently looking for a job in the European Union
Michael Wojcik
In article <vvudnWOP9s4...@comcast.com>, "Merrill & Michele" <beckj...@comcast.net> writes:
> 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.
--
Michael Wojcik michael...@microfocus.com
Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".
Michael Wojcik
In article <415632...@mindspring.com>, pete <pfi...@mindspring.com> writes:
>
> 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 michael...@microfocus.com
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
pete
>
> In <415632...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >Under what conditions does the intial value of argc equal zero?
>
> 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.
--
pete
CBFalconer
> Dan Pop wrote:
>>
... snip ...
>
>> 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.
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.
--
A: Because it fouls the order in which people normally read text.
pete
>
> pete wrote:
> > Dan Pop wrote:
> >>
> ... snip ...
> >
> >> 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.
>
> 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?
--
pete
Dan Pop
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 Pop
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...
CBFalconer
Yes
Michael Wojcik
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 michael...@microfocus.com
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
Merrill & Michele
> 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.
> > "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.
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
pete
>
> In <415941...@mindspring.com> pete <pfi...@mindspring.com> writes:
>
> >CBFalconer wrote:
> >>
> >> pete wrote:
> >> > Dan Pop wrote:
> >> >>
> >> ... snip ...
> >> >
> >> >> 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.
> >>
> >> 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?
>
> 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...
Thank you.
--
pete
Chris Torek
In article <news:vvudnWOP9s4...@comcast.com>
Merrill & Michele <beckj...@comcast.net> wrote:
>... "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.
The name comes from the original White Book, printed in 1978. (I
bought it in 1981 for $15. Remember when computer books were under
$30? :-) ) As such, it predates DOS. Perhaps they should have
changed it for K&R2 anyway.
This line is the real reason I am posting, though:
>argv[argc] points to null.
In my opinion, it is much better to say (and think) "is null" than
"points to null". Given any appropriate type T, the value (T *)NULL
-- the null pointer of type "pointer to T" -- does not point *to*
any valid C object (or function, if T is a function type) at all.
Saying "points to null" will eventually lead you into a trap -- or
at least, I have seen this happen before with others.
There is a lot more verbiage on this topic in the comp.lang.c FAQ (q.v.).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Dan Pop
>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."
Pay special attention to the first two words: "By convention". If
someone is breaking this convention, the rest of the sentence does not
apply.
Ben Pfaff
>Merrill & Michele <beckj...@comcast.net> wrote:
>>argv[argc] points to null.
>
> In my opinion, it is much better to say (and think) "is null" than
> "points to null". [...]
This is especially true because there are legitimate, but
distinct, circumstances in which a pointer really does point to
null. For example, below, p is null, but pp points to null:
void *p = NULL;
void **pp = &p;
--
Ben Pfaff
email: b...@cs.stanford.edu
web: http://benpfaff.org
Michael Wojcik
In article <rtmdnQEsopP...@comcast.com>, "Merrill & Michele" <beckj...@comcast.net> writes:
>
> 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?
Sure, but note that on Unix - where C was first used - that
convention is subject to the whim of the programmer who executes the
program in the first place. (In fact, this is a common mistake made
by new Unix programmers - they invoke a program with no arguments at
all because they assume the environment will provide argv[0] for
them.)
Obviously, Dennis Ritchie knew perfectly well how the execv system
call worked in Unix when he co-wrote K&R, so he knew that programs
couldn't depend on argv[0] being set. But the C / Unix mindset of
the 1970s was largely a "best effort" one: let's get some work done,
and if we have to assume some error conditions are sufficiently rare
that we'll let the program crash if they happen, so be it.
(Ritchie's comment on the SIGPIPE signal is a good example: SIGPIPE
was invented so that pipelines would work correctly even if programs
didn't check for error returns when writing to standard output.)
So indeed it's just that: a convention, and the truly robust program
should assume that some rude invoker might violate it. The quick-
and-dirty program, tossed together for a single use, probably needn't
bother. (Though most programmers have seen at least a few of those
quick-and-dirty, temporary programs get distributed and come back to
plague them later...)
--
Michael Wojcik michael...@microfocus.com
"Well, we're not getting a girl," said Marilla, as if poisoning wells were
a purely feminine accomplishment and not to be dreaded in the case of a boy.
-- L. M. Montgomery, _Anne of Green Gables_
Merrill & Michele
> > 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?
"Michael Wojcik" wrote >
> Sure, but note that on Unix - where C was first used - that
> convention is subject to the whim of the programmer who executes the
> program in the first place. (In fact, this is a common mistake made
> by new Unix programmers - they invoke a program with no arguments at
> all because they assume the environment will provide argv[0] for
> them.)
>
> Obviously, Dennis Ritchie knew perfectly well how the execv system
> call worked in Unix when he co-wrote K&R, so he knew that programs
> couldn't depend on argv[0] being set. But the C / Unix mindset of
> the 1970s was largely a "best effort" one: let's get some work done,
> and if we have to assume some error conditions are sufficiently rare
> that we'll let the program crash if they happen, so be it.
> (Ritchie's comment on the SIGPIPE signal is a good example: SIGPIPE
> was invented so that pipelines would work correctly even if programs
> didn't check for error returns when writing to standard output.)
>
> So indeed it's just that: a convention, and the truly robust program
> should assume that some rude invoker might violate it. The quick-
> and-dirty program, tossed together for a single use, probably needn't
> bother. (Though most programmers have seen at least a few of those
> quick-and-dirty, temporary programs get distributed and come back to
> plague them later...)
>
> --
> Michael Wojcik
I find this interesting and topical, even though it's on the end of a thread
that next to no one is looking at. Is, however, Unix considered to be an
implementation or is it above reproach as such, because it gave immaculate
birth? MPJ
Merrill & Michele
> >>> 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."
> >
> >> Sure, but note that on Unix - where C was first used - that
> >> convention is subject to the whim of the programmer who executes the
> >> program in the first place.
> MPJ wrote:
> > I find this interesting and topical, even though it's on the end of a
thread
> > that next to no one is looking at. Is, however, Unix considered to be
an
> > implementation or is it above reproach as such, because it gave
immaculate
> > birth? MPJ
>
> Arthur J. O'Dwyer" wrote:
> Unix is an "environment," not an "implementation." (At least, it's not
> an "implementation" of ISO C.) There do exist plenty of C implementations
> that run in the Unix environment, though: e.g., gcc. Unix is just as
> reasonable a platform for C implementations as MS-DOS or OS 9.
>
> I agree with Michael's conclusion: the K&R passage you quoted was aimed
> at making sure newbies understood the basic purpose and use of 'argv', not
> at explaining all the technical details. In Standard-speak, K&R is
> "informative," not "normative," and you shouldn't take everything it says
> as 100% true of standard C. 95% true, maybe, and useful regardless. :)
>
> -Arthur
Thank you for your reply. (I think I failed to thank Mr. Wojcik for his.)
Q1) How does this go over: Resolved, Unix is a platform, a black box
containing compiled code, on top of which the C language operates.
Q2) How does this go over: In clc, implementations are OT. gcc is an
implementation. Therefore, gcc is, qua implementation, OT.
It's far OT for me to comment on the word "normative." I'll simply #define
normative binding . MPJ
Benjamin Ketcham
>
> Unix is just as
> reasonable a platform for C implementations as MS-DOS
In the same sense that a Ferrari is just as reasonable a platform
for driving fast as a bulldozer.
Mark McIntyre
And your C point was?
This is not comp.unix.advocacy.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---