Re: Nilgewater about void main()
Seebs
> Read the standard more carefully. It most definitely
> doesn't mandate such a thing.
Having been involved in the discussions that led to the current
wording, I am convinced that it does.
To state that the standard "mandates" something does not imply that
an implementation does not have the freedom to accept something else;
it only asserts that that is the only thing the implementation *must*
accept.
The only declarations of main() that a hosted implementation *must*
accept are two forms, both of which return int. If you write something
else, you are relying on the implementation choosing to support a
feature not required by the standard.
> I'm surprised that you're getting this wrong. This
> ground has been covered ad nauseam over the years.
> I have a Frequently Given Answer on the subject that
> lays out how the punctuation breaks up the list and
> what sections deal with alternative types for the
> return value of main().
That's nice. It doesn't matter, though. The standard, while
allowing implementations freedom to accept other forms, mandates
a return type of int for programs written in standard C. The
assertion being made has never been that no compiler anywhere
could accept other types; it is that no program which relies on
such a feature is strictly conforming code, or reliably portable
to additional implementations.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
John Bode
wrote:
> > > > There is no hint of void main (or any other return
> > > > type other than int).
>
> > > Actually, there is. You've stopped reading one third of
> > > the way through a sentence. Read all of the way to the
> > > end of that sentence. Then read for a few more sections
> > > beyond that point, as well.
>
> > Have read the whole thing. [...]
>
> > The standard does allow an implementation freedom to
> > define additional forms of main() that it will accept,
> > true. But that doesn't mean that it doesn't mandate a
> > return type of int. [...]
>
> Read the standard more carefully. It most definitely
> refuted carefully, too. M. Keighley was asserting
> that there's "no hint of [...] any other return
> type other than int". Clearly, there's not only a
> hint, there's explicit wording devoted to that
> very thing.
>
The thing about "or in some other implementation-defined manner" is
that the implementation must explicitly document what interfaces it
supports, whether that includes "int main(void)" and "int main(int
argc, char *argv[])" or not. If the implementation does not do that,
then the standard *does* mandate a return type of int (as indicated by
the use of the word "shall") for conforming implementations.
For example, here's the MSDN page on main() in MSVC++:
> Visual C++ Language Reference
> main: Program Startup
>
> A special function called main is the starting point of execution for
> all C and C++ programs. If you are writing code that adheres to the
> Unicode programming model, you can use the wide-character version of
> main, wmain.
>
> The main function is not predefined by the compiler; rather, it must be
> supplied in the program text.
>
> The declaration syntax for main is:
>
> int main( );
>
> or, optionally:
>
> int main( int argc[ , char *argv[ ] [, char *envp[ ] ] ] );
>
> Microsoft Specific
> -----------------------------------------------------------------
>
> The declaration syntax for wmain is as follows:
>
> int wmain( );
>
> or, optionally:
>
> int wmain( int argc[ , wchar_t *argv[ ] [, wchar_t *envp[ ] ] ] );
>
> You can also use _tmain, which is defined in TCHAR.h. _tmain will resolve
> to main unless _UNICODE is defined, in which case _tmain will resolve to
> wmain.
>
> END Microsoft Specific
> -------------------------------------------------------------
Keith Thompson
Agreed. (I might argue that "strictly conforming" is a bit of a red
herring; programs can be reliably portable without being strictly
conforming. But that's a minor points.)
There's another argument that even the "other implementation-defined
manner"s must have a return type of int. The way the final long
sentence in 5.1.2.2.1p1 is written could easily lead to that
conclusion:
It shall be defined with a return type of int and
with no parameters or
with two parameters or
in some other implementation-defined manner.
But the usual reading is:
It shall be defined
with a return type of int and
with no parameters or
with two parameters
or
in some other implementation-defined manner.
5.1.2.2.3p1, which discusses what happens if the return type is not
compatible with int, strongly implies that the latter is the intent.
I wouldn't mind seeing the wording clarified in C201X (it hasn't been
as of N1245).
I would mind even less seeing the "or in some other
implementation-defined manner" wording dropped altogether or replaced
by a footnote. I believe it's already covered sufficiently by the
general permission to provide extensions, and the fact that defining
main improperly is not a constraint violation.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
[...]
> For example, here's the MSDN page on main() in MSVC++:
>
>> Visual C++ Language Reference
>> main: Program Startup
>>
>> A special function called main is the starting point of execution for
>> all C and C++ programs. If you are writing code that adheres to the
>> Unicode programming model, you can use the wide-character version of
>> main, wmain.
>>
>> The main function is not predefined by the compiler; rather, it must be
>> supplied in the program text.
>>
>> The declaration syntax for main is:
>>
>> int main( );
>>
>> or, optionally:
>>
>> int main( int argc[ , char *argv[ ] [, char *envp[ ] ] ] );
>>
>> Microsoft Specific
>> -----------------------------------------------------------------
>>
>> The declaration syntax for wmain is as follows:
>>
>> int wmain( );
>>
>> or, optionally:
>>
>> int wmain( int argc[ , wchar_t *argv[ ] [, wchar_t *envp[ ] ] ] );
>>
>> You can also use _tmain, which is defined in TCHAR.h. _tmain will resolve
>> to main unless _UNICODE is defined, in which case _tmain will resolve to
>> wmain.
>>
>> END Microsoft Specific
Interesting. It appears that the extra envp parameter for main
is justifiable undef C99 5.1.2.2.1p1, but the wmain alternative is
not -- though it is justifiable under C99 4p6, which grants general
permission for extensions.
(My understanding is that VC++ doesn't claim conformance to
C99, only to C90, which doesn't have the "or in some other
implementation-defined manner" wording, but the theoretical point
still stands.)
What is the rationale for permitting alternate definitions for main()
in one place, but (implicitly) permitting entry point names other
than "main" in another?
Seebs
> What is the rationale for permitting alternate definitions for main()
> in one place, but (implicitly) permitting entry point names other
> than "main" in another?
I'd guess that entry points other than main are mostly relevant to
freestanding implementations (and yes, many GUI environments count as
such from a standardese perspective). By contrast, alternative definitions
for main() are relevant because of things like the once-popular envp --
cases where it's preferable to stick with "main()", but there's some reason
to change the way it works. I could certainly see a system formally defining
support for "void main(...)" as indicating, for instance, that if a program
exits at all, no matter how (including calls to exit()), it is reported to
the calling environment as a critical failure. That would make perfect
sense to me.
I think it's just there as sort of a warning that, if your system really
has a good reason to use a different model, it's permissible to support
others, but you have to define them. And you still have to support the
standard one, although it's probably fine to always have argc = 0, argv
= { NULL }.
spinoza1111
Actually, the code is standard, for the "freestanding" environment.
Furthermore, C is C in practice, not "standard C":
* "Standard C" programs will not compile if they contain undefined
variables etc.
* "Standard C" programs will not run if they contain off by one bugs
such as your famous strlen
* Adding int main() doesn't magically make a program compile, run, or
even standard
* The "standard" is worthless because in fact, "standard" programs
are not portable.
This last is because to be "ported", a C program has to be reviewed,
preferably in a group or pair setting, line by line in a way that a
Java or C Sharp program doesn't.
My guess is that Schildt thinks you're a joke, Peter.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Jun Woong
[...]
> I would mind even less seeing the "or in some other
> implementation-defined manner" wording dropped altogether or replaced
> by a footnote. I believe it's already covered sufficiently by the
> general permission to provide extensions, and the fact that defining
> main improperly is not a constraint violation.
Yes, but the difference is that, the wording in C99 requires an
implementation to document the forms of main() it supports. As I
recall, that's the only purpose of the wording added.
--
Jun, Woong (woong.jun at gmail.com)
Nick Keighley
wrote:
> > > > There is no hint of void main (or any other return
> > > > type other than int).
>
> > > Actually, there is. You've stopped reading one third of
> > > the way through a sentence. Read all of the way to the
> > > end of that sentence. Then read for a few more sections
> > > beyond that point, as well.
>
> > Have read the whole thing. [...]
>
> > The standard does allow an implementation freedom to
> > define additional forms of main() that it will accept,
> > return type of int. [...]
>
> Read the standard more carefully. It most definitely
> refuted carefully, too. M. Keighley was asserting
> that there's "no hint of [...] any other return
> type other than int". Clearly, there's not only a
> hint, there's explicit wording devoted to that
> very thing.
>
> ground has been covered ad nauseam over the years.
> I have a Frequently Given Answer on the subject that
> lays out how the punctuation breaks up the list and
> what sections deal with alternative types for the
> in 2002, exactly what wording changes would be
> needed to make the standard actually say what
> people so often assert it to say. You want the
> standard to "mandate a return type of int"? You
> know exactly what to vote in at the next
> WG14 meeting. (-:
the 1989 standard?
J de Boyne Pollard
> > doesn't mandate such a thing.
>
> Having been involved in the discussions that led to
> the current wording, I am convinced that it does.
Then you are committing the canonical error, committed by many,
of substituting what you think or want the standard to say
for what the standard actually says. It's the error committed
by some FAQs and by some well-intentioned but misinformed
people. Go and read what the standard *actually says*.
> > I'm surprised that you're getting this wrong. This
> > ground has been covered ad nauseam over the years.
> > I have a Frequently Given Answer on the subject that
> > lays out how the punctuation breaks up the list and
> > what sections deal with alternative types for the
> > return value of main().
>
> That's nice. It doesn't matter, though. The standard,
> while allowing implementations freedom to accept other
> forms, mandates a return type of int for programs
> written in standard C.
Wrong. Go and read what the document actually says. If
you want your statements to be true, you really do have
to stand up in a WG14 meeting and vote a wording change
in, because the current wording does not state what you
are repeatedly, and erroneously, stating, and indeed has
explicit wording dealing with the very opposite of what
you claim it to mandate. Ignore the FAQs. Ignore your
garbled memories of discussions in meetings. Ignore
the folk wisdom passed along in newsgroups. Read the
text of the standard as it is actually written, and has
been for the past decade and more. It's not what you
think it to be. The mandate that you claim to exist
does not exist in the actual text of the document. If
you want the document to be as you think it to be,
you really do have to change it.
After such a change, it would become compatible with
the C++ standard in this area. Unlike the C standard,
ISO/IEC 14882:1998 *really does* mandate int as the
return type of main(), with an explicit "shall"
constraint upon well-formed programs. Its wording is
different to the C standard's, *including* such a
constraint and *excluding* any such thing as the C
standard's discussions of return types for main()
that are not int. To be the same, the C standard
would have to change, because that's not how the
C standard is now.
Jun Woong
> After such a change, it would become compatible with
> the C++ standard in this area. Unlike the C standard,
> ISO/IEC 14882:1998 *really does* mandate int as the
> return type of main(), with an explicit "shall"
> constraint upon well-formed programs. Its wording is
> different to the C standard's, *including* such a
> constraint and *excluding* any such thing as the C
> standard's discussions of return types for main()
> that are not int. To be the same, the C standard
> would have to change, because that's not how the
> C standard is now.
After comparing C99's wording to C++98's, so your point is:
C99 does not mandate the return type of main() because it does not
explicitly say all conforming implementations have to support those
two forms of main() and because it allows implementation-defined
forms
?
What you do think the problem is? That C99 contains no wording to
require conforming implementations support the two forms, or that it
allows i-d forms?
If the former, I ask a question: do C99 and C++98 explicitly say that
all conforming implementations support, say, the int type? They have
to because strictly conforming programs can use it, don't they?
If the latter, as I said, the intent of the wording (added in C99) is
that an implementation has to document *additional* forms of main()
it supports (if any); which never allows a conforming hosted
implementation not to support the two froms. (And, okay, I agree to
revise the wording to make its intent clearer in this case.)
Or am I missing your point?
Seebs
> Then you are committing the canonical error, committed by many,
> of substituting what you think or want the standard to say
> for what the standard actually says. It's the error committed
> by some FAQs and by some well-intentioned but misinformed
> people. Go and read what the standard *actually says*.
I have.
I understand it just fine.
I think our issue has nothing at all to do with the words in the
standard here, but with the question of what it means for the standard
to "mandate" something.
> Wrong. Go and read what the document actually says.
If you want to make a case, you actually have to present some
kind of argument, not just assert that you're right.
Argument. You know. Explanation of how the data you cite allegedly
support your position.
You have provided NONE. That's because there isn't one. It's also because,
before you could do that, you'd have to offer a clear explanation of what
you think it means to say that the standard "mandates" something.
Hint: The general permission to offer extensions means that you can always
accept new kinds of programs that contradict what the standard mandates.
That an implementation is permitted, implicitly or implicitly, to accept a
program, does not mean that the standard did not mandate something contrary
to that program's structure or contents.
When we say the standard "mandates" a return type of int, we mean that, if
you use any other return type for main(), the standard provides you with
no guarantees. It is quite possible that an individual implementation will
choose to offer you guarantees. It was just as possible in 1989. It doesn't
change what the standard requires.
If you want to write code which conforms to the C standard, for a hosted
implementation, your main() must return int. That compilers *could* accept
other forms doesn't change that. Similarly, you can't rely on the value
of a right-shifted signed negative number. That an implementation COULD
define that to give you useful results doesn't mean that you can rely on it
and claim to be conforming with the standard.
lawrenc...@siemens.com
>
> But the usual reading is:
>
> It shall be defined
> with a return type of int and
> with no parameters or
> with two parameters
> or
> in some other implementation-defined manner.
>
> 5.1.2.2.3p1, which discusses what happens if the return type is not
> compatible with int, strongly implies that the latter is the intent.
As does the semicolon before the final clause.
--
Larry Jones
Do you think God lets you plea bargain? -- Calvin
Dag-Erling Smørgrav
> My guess is that Schildt thinks you're a joke, Peter.
That's OK, Ed, because we know that *you* certainly are.
DES
--
Dag-Erling Smørgrav - d...@des.no
Seebs
> spinoza1111 <spino...@yahoo.com> writes:
>> My guess is that Schildt thinks you're a joke, Peter.
> That's OK, Ed, because we know that *you* certainly are.
While I'm touched that Nilges has come to bring his special brand of
amusement to this forum too, might I encourage people to do a bit
of quick background research on "Edward Nilges" before responding
to him? :)
-s
--
spinoza1111
> On 2010-04-13, J de Boyne Pollard <J.deBoynePoll...@Tesco.NET> wrote:
>
> > Then you are committing the canonical error, committed by many,
> > of substituting what you think or want the standard to say
> > for what the standard actually says. It's the error committed
> > by some FAQs and by some well-intentioned but misinformed
> > people. Go and read what the standard *actually says*.
>
> I have.
>
> I understand it just fine.
>
> I think our issue has nothing at all to do with the words in the
> standard here, but with the question of what it means for the standard
> to "mandate" something.
>
> > Wrong. Go and read what the document actually says.
>
> If you want to make a case, you actually have to present some
> kind of argument, not just assert that you're right.
>
> Argument. You know. Explanation of how the data you cite allegedly
> support your position.
>
> You have provided NONE. That's because there isn't one. It's also because,
> before you could do that, you'd have to offer a clear explanation of what
> you think it means to say that the standard "mandates" something.
>
> Hint: The general permission to offer extensions means that you can always
> accept new kinds of programs that contradict what the standard mandates.
5.1.2 WG14/N1124
"Two execution environments are defined: FREESTANDING and HOSTED. In
both cases, 'program startup' occurs when a designated C program is
called by the execution environment. All objects with static storage
duration shall be "initialized" (set to their initial values) before
program startup. The manner and timing of such initialization are
otherwise unspecified. 'Program termination' returns control to the
execution environment."
"In a freestanding environment (in which C program execution may take
place without any benefit of an operating system) the name and type of
the function called at program startup are implementation-defined. Any
library facilities available to a freestanding program, other than the
minimal set required by clause 4, are implementation-defined."
"The effect of program termination in a freestanding environment is
implementation-defined."
"A hosted environment need not be provided, but shall conform to the
following specifications if present."
[Followed by specifications for int main() in the hosted environment]
The standard doesn't "mandate" int main(). It says what a hosted as
opposed to freestanding execution environment will do with int main().
Other implementations, known as "freestanding" (including any
implementation that doesn't flag void main()) are also standard
implementations, and code that compiles with errors on them is at a
second level "standard". The distinction between hosted and
freestanding is not a moral distinction nor is it a distinction
between "conformant" and "nonconformant".
In fact, it's obvious that the "hosted" implementation was put into
the standard by way of Linux pressure to overlink, in violation of
separation of concerns, C to Linux.
Most contemporary uses of C are "freestanding" in that most C programs
are called from graphical user interfaces not coded in C.
Pressure on organizations to support Linux is represented as some sort
of crusade for "freedom" in the mythos. But the fact is that Linux, as
open source, represents a very valuable resource for profit-making
organizations and to this end, hordes of fools were marshaled and
deluded as Seebach is.
> That an implementation is permitted, implicitly or implicitly, to accept a
> program, does not mean that the standard did not mandate something contrary
> to that program's structure or contents.
>
> When we say the standard "mandates" a return type of int, we mean that, if
> you use any other return type for main(), the standard provides you with
> no guarantees.
This is false. See above. It simply means that the implementation is
not hosted.
> It is quite possible that an individual implementation will
> choose to offer you guarantees. It was just as possible in 1989. It doesn't
> change what the standard requires.
>
> If you want to write code which conforms to the C standard, for a hosted
> implementation, your main() must return int. That compilers *could* accept
No, for only one type of "hosted" implementation: the host as defined
by the standard.
> other forms doesn't change that. Similarly, you can't rely on the value
> of a right-shifted signed negative number. That an implementation COULD
> define that to give you useful results doesn't mean that you can rely on it
> and claim to be conforming with the standard.
This is absurd. The Standard is open in the sense that it allows
implementations to have facts about them and programmers to rely on
those facts.
You're saying, in fact, that C must be used like Java to be
"standard". But after ten years doing apparently diddly on the
standards group save pad your resume, you don't understand that the
Standard is a standard for implementations and not C code.
It's not a very good standard for implementation. But for code, it's
nonsense.
A dependency in code on ones being shifted in is what C is for:
systems programming at a level where implementation details,
especially gross implementation details, are usable and known.
I agree that given your queue.c horror, your failure to correctly
implement strlen, and your %s nonsense, you shouldn't be using C and
should retrain in Java, which more resembles the scripting languages
where your expertise seems to lie. By condemning a C programmer
working at a certain depth for knowing his trade (knowing, for
example, that twos complement is in use on his target architecture)
you merely add to what we know: that you're uneducated in computer
science, and fail to compensate for that by being a knowledgeable
programmer.
When this serious pattern of resume padding, stalking and ignorance is
exposed, you embark on campaigns of personal destruction, including
making offensive neologisms out of people's names. You force others to
reply at your childish level. But, don't compete with me:
There's a coder named Dweebach
Who cried alas and alack
My code fails to work
And I know I'm a jerk.
That low level coder named Dweebach.
There's a low level coder named Peter
Who couldn't program a parking meter
Though god knows he tried
But his code, it died
Blue screen of death appeared on his parking meter.
There's a hacker named Seebs
Who's ranked with the feebs
Says he knows C
But he don't, see?
That hopelessly clue challenged Seebs!
J de Boyne Pollard
> > of substituting what you think or want the standard to say
> > for what the standard actually says. It's the error committed
> > by some FAQs and by some well-intentioned but misinformed
> > people. Go and read what the standard *actually says*.
>
> I have. I understand it just fine.
No, you don't, given that you keep saying that the standard
mandates something that it not only doesn't mandate, but
explicitly makes provision for not being the case.
> > Wrong. Go and read what the document actually says.
>
> If you want to make a case, you actually have to present some
> kind of argument, not just assert that you're right.
It's presented at length on the WWW page I've already pointed
you to twice. Go and read it.
> You have provided NONE.
You're being silly. I've been providing a clear
explanation of what the standard actually says, and
how its actual text contradicts popular folklore,
with the exact text and section numbers, for
over ten years.
> When we say the standard "mandates" a return type of int,
> we mean that, if you use any other return type for main(),
> the standard provides you with no guarantees.
No you don't. You mean that it mandates a return type of
int, which is not the same as providing no guarantees.
We all (or at least most of us) know what a mandate by
the standard actually looks like. And if you want to
put one into the C standard, mandating a return type of
int for main(), I have, and have had since the early
2000s, the very wording change for you to vote on
at a WG14 meeting. It's hyperlinked to from the FGA
page.
But without that wording change, there is no such mandate.
You really do have to put your vote where your mouth is,
figuratively speaking, and change the standard to actually
contain within it the mandate that you keep erroneously
claiming it to maintain.
blm...@myrealbox.com
Note the "without any benefit of an operating system".
> the name and type of
> the function called at program startup are implementation-defined. Any
> library facilities available to a freestanding program, other than the
> minimal set required by clause 4, are implementation-defined."
>
> "The effect of program termination in a freestanding environment is
> implementation-defined."
>
> "A hosted environment need not be provided, but shall conform to the
> following specifications if present."
>
> [Followed by specifications for int main() in the hosted environment]
>
> The standard doesn't "mandate" int main(). It says what a hosted as
> opposed to freestanding execution environment will do with int main().
> Other implementations, known as "freestanding" (including any
> implementation that doesn't flag void main()) are also standard
> implementations, and code that compiles with errors on them is at a
> second level "standard". The distinction between hosted and
> freestanding is not a moral distinction nor is it a distinction
> between "conformant" and "nonconformant".
>
> In fact, it's obvious that the "hosted" implementation was put into
> the standard by way of Linux pressure to overlink, in violation of
> separation of concerns, C to Linux.
>
> Most contemporary uses of C are "freestanding" in that most C programs
> are called from graphical user interfaces not coded in C.
I'm *very* skeptical about this sense of "freestanding" being compatible
with the definition stated/implied by the quoted text above.
"Scripting languages"? as best I can tell, Seebs has claimed only
familiarity with UNIX-like command shells, which -- eh, I suppose
they *could* be considered scripting languages, but the ones I know
(Bourne shell and C shell) seem to me to be more similar in spirit
to C than Java, particularly with regard to the difficulties of
writing reliably-portable code.
[ snip ]
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Seebs
> Note the "without any benefit of an operating system".
However, while that's certainly a common form of freestanding environments,
two other fairly widely-used freestanding implementations come to mind:
* Microsoft Windows
* Classic MacOS
For both of these implementations, the default format of an "application"
was treated, from a C implementation standpoint, as "freestanding".
... However, this is irrelevant to Schildt's book, because a "freestanding"
implementation is not obliged to provide <stdio.h> or related functions.
As a result, it's quite clear that Schildt is writing about hosted
environments, not freestanding environments. Note that both Windows and
Classic MacOS compilers provided hosted environments as an alternative,
they just weren't the default form for applications.
> I'm *very* skeptical about this sense of "freestanding" being compatible
> with the definition stated/implied by the quoted text above.
I never thought I'd say this, but: Nilges is actually right, loosely
speaking, on that one. Graphical environments typically don't provide
printf(), stdin, or stdout, and applications written for them are often
viewed as "freestanding". As a famous example, some Windows
application environments omitted sprintf(), because it was only required
in a hosted implementation!
... That said, it has widely been assumed that such trickery violates
the *spirit* of the standard. I would not have much respect for an
environment which omitted substantial chunks of the hosted environment
stuff just because it was claiming to be freestanding, even though it
really was running on an operating system.
But again, this is all irrelevant; Schildt is clearly writing about
hosted environments, complete with stdio, stdin, stdout, stderr, and
so on.
> "Scripting languages"? as best I can tell, Seebs has claimed only
> familiarity with UNIX-like command shells, which -- eh, I suppose
> they *could* be considered scripting languages, but the ones I know
> (Bourne shell and C shell) seem to me to be more similar in spirit
> to C than Java, particularly with regard to the difficulties of
> writing reliably-portable code.
I can get by in Lua, Ruby, perl, PHP, most of the sh family (this does
not include csh/tcsh), and maybe one or two others I can't think of.
I consider it harder to write portable code in sh than in C.
... Not that I see any relevance to that. :P
blm...@myrealbox.com
Seebs <usenet...@seebs.net> wrote:
> On 2010-04-15, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
> > Note the "without any benefit of an operating system".
>
> However, while that's certainly a common form of freestanding environments,
> two other fairly widely-used freestanding implementations come to mind:
>
> * Microsoft Windows
> * Classic MacOS
>
> For both of these implementations, the default format of an "application"
> was treated, from a C implementation standpoint, as "freestanding".
Interesting! I think I misread this part of the text quoted from
the standard
"In a freestanding environment (in which C program execution may take
place without any benefit of an operating system)"
to mean that there definitely will *not* be an operating system, only
the C program. What part of "may" didn't I get ....
> ... However, this is irrelevant to Schildt's book, because a "freestanding"
> implementation is not obliged to provide <stdio.h> or related functions.
> As a result, it's quite clear that Schildt is writing about hosted
> environments, not freestanding environments. Note that both Windows and
> Classic MacOS compilers provided hosted environments as an alternative,
> they just weren't the default form for applications.
>
> > I'm *very* skeptical about this sense of "freestanding" being compatible
> > with the definition stated/implied by the quoted text above.
>
> I never thought I'd say this, but: Nilges is actually right, loosely
> speaking, on that one. Graphical environments typically don't provide
> printf(), stdin, or stdout, and applications written for them are often
> viewed as "freestanding". As a famous example, some Windows
> application environments omitted sprintf(), because it was only required
> in a hosted implementation!
Interesting! That's certainly not what I was thinking "freestanding"
meant, but -- sure, why not.
> ... That said, it has widely been assumed that such trickery violates
> the *spirit* of the standard. I would not have much respect for an
> environment which omitted substantial chunks of the hosted environment
> stuff just because it was claiming to be freestanding, even though it
> really was running on an operating system.
>
> But again, this is all irrelevant; Schildt is clearly writing about
> hosted environments, complete with stdio, stdin, stdout, stderr, and
> so on.
[ snip ]
spinoza1111
wrote:
You can cite chapter and verse. The problem is that owing to politics,
the "hosted" version is clearly the favorite version whereas the
"freestanding" standard is meant only as a sop to political opposition
which didn't want C to become a Linux-only language. A moral judgement
masquerades as science, and power politics defined C.
I suggest using a poetic response.
Let them have their little victories:
Let them write all of the histories.
They will dine on their own dog food
They will not be spared the whip or rood.
Linux will die in two thousand thirty eight
Right on schedule owing to their greed and hate:
It's a little matter of a date.
Cobol dates weren't a problem because then there were men
And women able to fix problems and say, amen.
These guys can't get string length right
And will be passed out dead drunk on New Year's night.
spinoza1111
> On 2010-04-15, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
>
> > Note the "without any benefit of an operating system".
>
> However, while that's certainly a common form of freestanding environments,
> two other fairly widely-used freestanding implementations come to mind:
>
> * Microsoft Windows
> * Classic MacOS
Yes...
>
> For both of these implementations, the default format of an "application"
> was treated, from a C implementation standpoint, as "freestanding".
So far so good...
>
> ... However, this is irrelevant to Schildt's book, because a "freestanding"
> implementation is not obliged to provide <stdio.h> or related functions.
No, but it can. Both Windows and MacOS provide these.
> As a result, it's quite clear that Schildt is writing about hosted
> environments, not freestanding environments. Note that both Windows and
False. It's clear that his code examples are meant to be used inside
the "freestanding host" of a C GUI to see what happens. It's
"freestanding" in terms of the Standard since it doesn't matter what
main() returns. It's "hosted' in the ordinary (non-C) sense of the
term.
> Classic MacOS compilers provided hosted environments as an alternative,
> they just weren't the default form for applications.
>
> > I'm *very* skeptical about this sense of "freestanding" being compatible
> > with the definition stated/implied by the quoted text above.
>
> I never thought I'd say this, but: Nilges is actually right, loosely
> speaking, on that one. Graphical environments typically don't provide
> printf(), stdin, or stdout, and applications written for them are often
> viewed as "freestanding". As a famous example, some Windows
> application environments omitted sprintf(), because it was only required
> in a hosted implementation!
Correct. This is because only a fool, today, would write GUIs in C.
>
> ... That said, it has widely been assumed that such trickery violates
> the *spirit* of the standard. I would not have much respect for an
> environment which omitted substantial chunks of the hosted environment
> stuff just because it was claiming to be freestanding, even though it
> really was running on an operating system.
>
> But again, this is all irrelevant; Schildt is clearly writing about
> hosted environments, complete with stdio, stdin, stdout, stderr, and
> so on.
No, he was writing for a disparate set of environments in a
Wittgensteinian family relationship united only by conformance to the
syntax and non-IO semantics of C. You have a foolish and narrow
conception of education as "nothing but the truth", one that fails to
prepare for ambiguity and error.
>
> > "Scripting languages"? as best I can tell, Seebs has claimed only
> > familiarity with UNIX-like command shells, which -- eh, I suppose
> > they *could* be considered scripting languages, but the ones I know
> > (Bourne shell and C shell) seem to me to be more similar in spirit
> > to C than Java, particularly with regard to the difficulties of
> > writing reliably-portable code.
>
> I can get by in Lua, Ruby, perl, PHP, most of the sh family (this does
> not include csh/tcsh), and maybe one or two others I can't think of.
>
> I consider it harder to write portable code in sh than in C.
But sh is of even less scientific interest than C, since in learning
either, you waste time and spiritual energy by having to learned just
how fucked up the past was.
I learned Latin. It has its benefits. But it is not useful. In
focusing on shibboleths, you're wasting our time. You need to learn
how to code, not "in" a programming language, but across a spectrum of
programming languages.
You need to code what you mean in excess of the requirements of fast
and dirty. This way, you won't present a search for % followed by
anything as a search for %s.
You need to check your code by desk-checking, and playing computer, as
we did in the "old days" when computer time was limited. This way, you
won't present off by one bugs in one line of code to people like me
who are your adversaries.
You need to use the Bohm-Jacopini structured constructs, enriched by
case without fallthrough and one trip do while.
You need to learn common courtesy in order to pair program or
participate productively in a structured walkthrough, and stop running
from the Other, whether Schildt or people in survey classes.
You need to learn separation of concerns. Finding a void main()
doesn't mean it's Miller Time, and time to go on break and diss your
fellow man, because in "freestanding" environments the code is still
standard, ceteris paribus. It might be code authored by Nash, Navia,
or Nilges from which you could learn. In mocking people over your
shibboleths, you are mixing up concerns.
Fuck or walk, Peter.
>
> ... Not that I see any relevance to that. :P
>
> -s
> --
spinoza1111
> On 2010-04-13, Dag-Erling Sm rgrav <d...@des.no> wrote:
>
> >> My guess is that Schildt thinks you're a joke, Peter.
> > That's OK, Ed, because we know that *you* certainly are.
>
> While I'm touched that Nilges has come to bring his special brand of
> amusement to this forum too, might I encourage people to do a bit
> of quick background research on "Edward Nilges" before responding
> to him? :)
On Apr 14, 3:00 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-13, Dag-Erling Sm rgrav <d...@des.no> wrote:
>
> >spinoza1111<spinoza1...@yahoo.com> writes:
> >> My guess is that Schildt thinks you're a joke, Peter.
> > That's OK, Ed, because we know that *you* certainly are.
>
> While I'm touched that Nilges has come to bring his special brand of
> amusement to this forum too, might I encourage people to do a bit
> of quick background research on "Edward Nilges" before responding
> to him? :)
I can provide that information:
Positives: book author, thirty years of experience and accomplishment,
asked to help a Nobel laureate with C, still has a hot body, accepted
with some enthusiasm into prestige moderated groups, was asked to
participate in an online forum with Cass Sunstein and Mike Godwin by
Princeton University Press based solely on his internet postings.
Negatives: got thrown out of these groups: comp.compilers (by
moderator John Levine) and on a TKO (technical knock-out) from a local
placeblog, www.lamma.com.HK.
>
> -s
> --
>
> -s
> --
spinoza1111
> In article <slrnhsedmh.4lj.usenet-nos...@guild.seebs.net>,
>
> Seebs <usenet-nos...@seebs.net> wrote:
> > On 2010-04-15, blmblm myrealbox.com <blm...@myrealbox.com> wrote:
> > > Note the "without any benefit of an operating system".
>
> > However, while that's certainly a common form of freestanding environments,
> > two other fairly widely-used freestanding implementations come to mind:
>
> > * Microsoft Windows
> > * Classic MacOS
>
> > For both of these implementations, the default format of an "application"
> > was treated, from a C implementation standpoint, as "freestanding".
>
> Interesting! I think I misread this part of the text quoted from
> the standard
>
> "In a freestanding environment (in which C program execution may take
> place without any benefit of an operating system)"
>
> to mean that there definitely will *not* be an operating system, only
> the C program. What part of "may" didn't I get ....
Although the Standard is biased towards Linux for commercial reasons
(the "free" status of Linux and the fact that it's virtual slave labor
making it irresistible to IBM) it is basically trying to say, not how
to "code standard C", but "what constitutes a standard compiler".
It is not intended to be read by such ordinary practiioners as
Heathfield, nor is a language standard, as such, to be used to beat on
ordinary programmers or text authors. And even though Seebach was on
the Standard, it isn't meant for him to use in his little campaign.
The passage that I quoted (and may I add that it seems to have cleared
up a lot of confusion and outright lying) was intended to recognize a
type of C program that would return something useful to its
environment as a function value, because many legacy command-line
processors expect this.
But were I to use C in practice, I'd use it to create
"DLLs" (windowsese for "dynamic linked libraries") called for critical
routines that must be called by an EXE (executable from the command
line or by double-clicking an icon). These DLLs would not contain a
main() procedure.
They would be "freestanding" not in the sense of floating on air like
Magritte's famous painting of a rock, but in the epistemological sense
that what they float upon is undefined. It could be a bare naked
machine but it does not have to be.
I suggest that the confusion in this newsgroup is either created by
deliberate economy with the truth, or lack of reading and cognitive
skills, or both.
> > I never thought I'd say this, but: Nilges is actually right, loosely
You've said it before and you're going to say it a lot more before
we're done.
spinoza1111
Oh yes, totally banned by wikipedia for doing philosophy while writing
about philosophy in the Kant article, by some convenience store clerk.
Returned briefly as a sock puppet when a wikipedia administrator
recommended this. I think that's it.