seebs/schildt

[spinoza1111]

IME, the term has very little to do with *what* the person says, and
everything to do with *how* he says it.  I've worked with programmers
that were well respected but considered abrasive, others that were
mixed that same abrasiveness with incompetence, and many who've
avoided abrasive behavior entirely.  I've been in a code review in
which one reviewer bluntly pointed out that OO had a concept of
"inheritance" (the org tends to very flat class models) without being
abrasive.  He seemed to be addressing defects in the code rather than
in the coder.  This is not an easy skill, nor a common one.

I agree that this person's conduct is not abrasive. However, in my
experience, it is sometimes called "abrasive" by people whose lack of
knowledge has been exposed. In your example, the designers of the
overly flat software are apt in corporate environments to say that the
critic is "academic" (because he's using knowledge) and "abrasive"
because he's criticized them). But to CALL a person "abrasive" in a
technical discussion out of the blue is to be "abrasive".

 

[spinoza1111]

It's far harder to write operating systems than it looks.
Ignoring device drivers, it would only take a few weeks to write
something on a bare PC capable of putting up windows, running programs
in them, closing them down. It's getting the details right that is the
killer.

Which is why Andrew Tanenbaum (from whom Torvalds stole Minix) was
right about Linux.

 

[Mark]

Which is why Andrew Tanenbaum (from whom Torvalds stole Minix) was
right about Linux.

The idea that Torvalds stole Minix was largely hyped up by a few people
during the early years of the SCO-Novell court case. Even early
versions shared little with Minix (mainly the filesystem code to get
that side up and running until a new filesystem was put in place - which
it was). This has largely been described as "scaffolding" and, like
structural scaffolding in the "physical world", it's not part of the
final product.

Even if you really believed Torvalds was in the habit of stealing code,
think about it for a minute: Minix and Linux are fundamentally different
designs, and the core difference (the whole microkernel vs. monolithic
kernel debate) is so significant, it simply isn't possible to take one,
"steal it" and turn it into the other. Sure, you could take concepts or
small parts of code and refactor them to work with the different
architecture, but most of the time you'd be creating even more work.

Don't believe me? Forget a short, intemperate debate in 1992 and read
this piece from the man himself (Professor Andrew S. Tanenbaum) from May
2004:

http://linux.sys-con.com/node/44969

Amongst other things, he says:

"He thought I would back up his crazy claim that Linus stole Linux
from me. Brown was wrong on two counts. First, I bear no 'grudge'
against Linus at all. He wrote Linux himself and deserves the
credit. Second, I am really not a mean person. Even if I were still
angry with him after all these years, I wouldn't choose some sleazy
author with a hidden agenda as my vehicle. My home page gets 2500
hits a week. If I had something to say, I could put it there."

"To the extent that Linus can be counted as my student, I'm proud of
him, too. Professors like it when their students go on to greater
glory."

"Linus seems to be doing excellent work and I wish him much success
in the future. "

So, even Andrew S. Tanenbaum clearly states that Torvalds didn't steal
from Minix.

Are you going to keep repeating this or concede that you are wrong?
An apology to Mr. Torvalds might be in order too, but I'll leave that
to your conscience.

 

[spinoza1111]

The idea that Torvalds stole Minix was largely hyped up by a few people
during the early years of the SCO-Novell court case.  Even early
versions shared little with Minix (mainly the filesystem code to get
that side up and running until a new filesystem was put in place - which
it was).  This has largely been described as "scaffolding" and, like
structural scaffolding in the "physical world", it's not part of the
final product.

Even if Torvalds wrote the code, he did no real creative design.
Tanenbaum and the developers of unix need to be credited with that.

Even if you really believed Torvalds was in the habit of stealing code,

I think that in general hackers and (with the exception of Stallman)
open source coders are in the habit of stealing intellectual
production (which doesn't only include "code" but also includes
ideas), and they've been in this habit ever since they stole Basic
from Gates and his team in the 1970s. I think they add insult to
injury by marshaling attacks on the victim as is seen here with
respect to Navia. They also work as slaves.

Their theft creates resources for big companies. Their slave mentality
destroys jobs. Their mob rule has destroyed the very idea of
reputation.

think about it for a minute: Minix and Linux are fundamentally different

Not in essentials. They are based on a command line interface and a
monolithic design with too many dependencies between levels that
should be separated.

designs, and the core difference (the whole microkernel vs. monolithic
kernel debate) is so significant, it simply isn't possible to take one,
"steal it" and turn it into the other.  Sure, you could take concepts or
small parts of code and refactor them to work with the different
architecture, but most of the time you'd be creating even more work.

Code is not ideas. The development of Linux was marked in fact by a
stunning lack of originality. It "is", from a standpoint of design,
unix. Cf. Jaron Lanier ("You Are Not a Gadget", 2010).

Don't believe me?  Forget a short, intemperate debate in 1992 and read
this piece from the man himself (Professor Andrew S. Tanenbaum) from May
2004:

   http://linux.sys-con.com/node/44969

Amongst other things, he says:

    "He thought I would back up his crazy claim that Linus stole Linux
    from me. Brown was wrong on two counts. First, I bear no 'grudge'
    against Linus at all. He wrote Linux himself and deserves the
    credit. Second, I am really not a mean person. Even if I were still
    angry with him after all these years, I wouldn't choose some sleazy
    author with a hidden agenda as my vehicle. My home page gets 2500
    hits a week. If I had something to say, I could put it there."

    "To the extent that Linus can be counted as my student, I'm proud of
    him, too. Professors like it when their students go on to greater
    glory."

    "Linus seems to be doing excellent work and I wish him much success
    in the future. "

So, even Andrew S. Tanenbaum clearly states that Torvalds didn't steal
from Minix.

What's interesting is that Professor Tanenbaum had to eat shit, and
there was no corresponding apology for the flame war from Torvalds,
the victor who went on to be a millionaire while Tanenbaum remains a
professor, unrecognized for minix and unrecognized for pointing out
the facts, which include the fact that Linux stopped OS development in
its tracks. As far as I know, Linux doesn't even solve the 2038 date
overflow problem (I hope I am wrong).

Are you going to keep repeating this or concede that you are wrong?
An apology to Mr. Torvalds might be in order too, but I'll leave that
to your conscience.

I don't think he cares. He's made his pile. That's all that counts in
this business.

 

[Mark]

Even if Torvalds wrote the code, he did no real creative design.
Tanenbaum and the developers of unix need to be credited with that.

I think that in general hackers and (with the exception of Stallman)
open source coders are in the habit of stealing intellectual
production (which doesn't only include "code" but also includes
ideas), and they've been in this habit ever since they stole Basic
from Gates and his team in the 1970s. I think they add insult to
injury by marshaling attacks on the victim as is seen here with
respect to Navia. They also work as slaves.

Their theft creates resources for big companies. Their slave mentality
destroys jobs. Their mob rule has destroyed the very idea of
reputation.

Some, not all. There is a lot of innovation in that community. That
there is also a lot of copying doesn't change that.

If you apply the same thing to all of industry, you could make precisely
the same observation.

As for Gates, he has borrowed most of his ideas too; BASIC was no more
original than most other code at the time, he simply (and perfectly
sensibly) decided to control it as property.

(I can't help pointing out, however, that "theft" has a specific legal
meaning which doesn't apply to software where you are not depriving the
person of their personal possessions).

Not in essentials. They are based on a command line interface and a
monolithic design with too many dependencies between levels that
should be separated.

If you think the command line is the essence of Unix, you have missed
almost the entire point. The command line is a common feature, but the
more important features in a modern unix-like system was to do with its
abstractions (whether VFS, security model, memory model, network layer,
whatever).

Whilst you could argue that your criticisms about dependencies apply to
Linux (though there are counter-arguments), how do you claim this for
Minix? Minix is designed to be a Microkernel, and the subsystems are
separated and communicate through the (traditional microkernel) message
passing. This is why I say you're wrong that Linux and Minix are
closely related.

Why do you believe you're right?

Code is not ideas. The development of Linux was marked in fact by a
stunning lack of originality. It "is", from a standpoint of design,
unix. Cf. Jaron Lanier ("You Are Not a Gadget", 2010).

Code can be the *expression* of ideas, particularly when well-executed.

Linux was deliberately designed to be useful in the real world. It was
designed against standards (things like the POSIX standards, the SuS,
SVRX and other similar documents) so that real software would be trivial
to port. This is what has guided a lot of its *interface* decisions.

On either side of the interfaces*, however, there has been plenty of
innovation, with all sorts of interesting work coming out of it.

Does that mean that closed-source is bad? I don't think so.

Does the stilted copycat projects that exist in open-source mean
open-source is devoid of invention? I don't think that either.

* And even some of the interfaces have developed. This has not been
without controversy.

What's interesting is that Professor Tanenbaum had to eat shit, and
there was no corresponding apology for the flame war from Torvalds,

Again, you are wrong. Torvalds apologised to him at the time and has
repeated that apology since. As far as I can see, there are no hard
feelings on either side.

the victor who went on to be a millionaire while Tanenbaum remains a
professor, unrecognized for minix and unrecognized for pointing out
the facts, which include the fact that Linux stopped OS development in
its tracks. As far as I know, Linux doesn't even solve the 2038 date
overflow problem (I hope I am wrong).

As Tanenbaum has stated clearly (in fact, in the same article I
referenced) he was (and is) more interested in his academic career than
having a successful career focused on Minix. I don't know how Torvalds
has done or if he *is* a millionaire, but I don't understand why you
wish to turn him into a bad guy.

There *is* no "fact" that Linux stopped OS development in its tracks.
That's just something you want to assert. OS development has certainly
slowed but (I'd *assert*) this is more to do with the fact that kernels
became "good enough" and the CS community has been more interested in
other challenges in middleware and elsewhere. Finding ways to
distribute code across cores and systems (locally or globally) are the
route to Ph.D.s now. Is that Linux's (or Torvald's) fault? No more
than it's Microsoft's, Sun's or Apple's fault.

You are also wrong that Tanenbaum is unrecognised for Minix. Sure, he's
not known outside of CS while Torvalds is (to a greater extent), but he
never *was* known outside of the CS community. How has Torvalds fame
cost him? If anything, it drew attention to Minix and has written him
another page in history. I must say, however, Minix is not his most
important work in my opinion.

Finally, the 2038 problem is as solved as it can be. The standard
time_t for 64 bit systems (which any serious system these days will be)
is 64 bits. That gives us more time than I'm going to worry about
(many, many millennia). There are some minor issues in 64 bit Unix like
library support for dates in the far-future:

- HPUX only recognise up to Dec 31 9999, 23:59:59 UTC
in their 64 bit systems for functions like "ctime"
- glibc on Fedora 12, x86_64 only seems to handle up to
Dec 31 2147483647, 23:59:59 UTC. I can live with this.

The biggest problems can't be solved by the OS designers, however, and
that's where people have written code with the assumptions in the code,
particularly where people aren't using time_t and/or are abusing the
type in the way they perform arithmetic. This would be the case no
matter which language or OS you were dealing with.

As with Y2K, it will depend on code review. People running shoddy code
have work to do, particularly if the code is heading to overruns earlier
(the classic example being banks calculating mortgage repayments over
25/30 year terms).

I don't think he cares. He's made his pile. That's all that counts in
this business.

If that were the case, it would make your pursuit of Seebs on behalf of
Schildt even harder to explain.

You have accused Torvalds of being a thief (amongst other things).
Whether or not you retract and apologise is entirely up to you.

As for Torvalds, you are almost certainly right he doesn't care. He's
big enough and smart enough to defend himself even if he does, so I
won't patronise him by pretending otherwise. I'm certain that's the
position someone like Herb Schildt would take too.

This doesn't make your wild assertions correct, though. Are you big
enough to concede the points I've made here?

It's entirely up to you.

 

[Seebs]

If you think the command line is the essence of Unix, you have missed
almost the entire point.

Well, yeah.

This doesn't make your wild assertions correct, though. Are you big
enough to concede the points I've made here?

A couple of observations:
1. Nilges rarely concedes points, regardless of evidence.
2. Even when he does, he's still just as likely to continue asserting
the things he previously conceded were wrong a few days later, once he's
had time to rationalize the concession away.
3. He's stated in the past that his goal is to destroy this newsgroup.
(Or at least, so I'm told, and it seems consistent with his behavior.)
It does not seem likely that anything productive can be accomplished
by trying to "engage" him.

I know it's maddening watching him post stuff that is fractally
wrong*, but really, there's nothing we can do about it; he's just gonna
do that.

Correcting him on points of fact has no discernable effect. He just
sticks with them.

-s
[*] http://www.fractallywrong.com/ has a definition.

 

[spinoza1111]

Well, yeah.

A software feature doesn't have to be part of the essence to be a bug
and to make the software unusable.

A couple of observations:
1.  Nilges rarely concedes points, regardless of evidence.
2.  Even when he does, he's still just as likely to continue asserting
the things he previously conceded were wrong a few days later, once he's
had time to rationalize the concession away.
3.  He's stated in the past that his goal is to destroy this newsgroup.

I don't no where you got that.

(Or at least, so I'm told, and it seems consistent with his behavior.)

So it is hearsay. Fits your pattern. Second hand rumor mongering and a
baldfaced lie.

It does not seem likely that anything productive can be accomplished
by trying to "engage" him.

On the contrary. I and others FINALLY got you to at least CHANGE
CTCN-3 which for several years was thought to apply to CTCR-4, the
CTCR that has been in print since 2000.

I know it's maddening watching him post stuff that is fractally
wrong*, but really, there's nothing we can do about it; he's just gonna
do that.

Correcting him on points of fact has no discernable effect.  He just
sticks with them.

I think you confuse "facts" with "opinions of my friends". We've in
fact learned that one of your major "facts" (a C program must have a
main() with an int, or alternatively and weaker, if it has a main this
main must be declared as returning int, for that program to be
"standard") is wrong and you have conceded this elsethread after I
quoted the standard.

-s
[*]http://www.fractallywrong.com/has a definition.

 

[Kenny McCormack]

Not really.  You're never faced with 2 doors that say "be correct" and
"get wealthy and successful."  I'm reasonably certain that I would
choose the latter.

[/QUOTE]

I'm not sure why this poster said "You're never faced with ..."
I think in order for the thread to make sense, he has to have meant
something like "Every so often in life, you are faced with ..."

And, in that vein, yeah, it is cool for us geeky CLC types to want to
maintain that, yeah, we'd choose the money/fame/power over "being
right", and we claim that precisely because we know it isn't true.

Basically, the reason we're a bunch of CLC losers is precisely because
at key points in our lives, we've chosen to be right and to be true to
ourselves, instead of becoming marketing tools. We should be honest
about that. And, I can prove this very simply: Given our innnate
knowledge/skill/smarts, if we wanted to, we could easily have been
famous/rich/powerful/etc. That we're not (and trust me, I've never
heard of any of the CLC gang outside of CLC) these things, speaks all.

I've always said (of myself) that if I had had any ambition at all, I'd
be a billionaire now.

You not infrequently have to face the choice between standing up for
what you believe to be right and personal advantage. Those who point
out that a war is unwinnable, for example, can make themselves very
unpopular, even if their advice, if taken, would save the State from
disaster.

Very good point, and well said.

And again, I'd say that most CLCers would not be afraid to "speak truth
to power" - at whatever personal peril that entailed.

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

 

[spinoza1111]

Well, yeah.


A couple of observations:
1.  Nilges rarely concedes points, regardless of evidence.

Your evidence as we have seen in the case of "freestanding" v "hosted"
garbage, because in that case and others you conceal material facts. I
had to post the wording of the standard to demonstrate that coding int
main() is not in fact a requirement of the standard. You were forced
to concede.

2.  Even when he does, he's still just as likely to continue asserting
the things he previously conceded were wrong a few days later, once he's
had time to rationalize the concession away.

Giving adequate reasons is not "rationalization".

3.  He's stated in the past that his goal is to destroy this newsgroup.
(Or at least, so I'm told, and it seems consistent with his behavior.)

Spreading a rumor by your own admission. The fact is that I think the
regs should leave based on their conduct. This is like saying the
truth as regards the government of Israel (it's a criminal gang
running a rogue state) and having this be changed to "kill the Jews"
by deliberate mistranslation by Israeli owned translation firms.

It does not seem likely that anything productive can be accomplished
by trying to "engage" him.

1. By your own admission you were forced to at least stop the
deliberate confusion you had created by neglecting to update "C: the
Complete Nonsense" after Schildt's fourth edition of "C: the Complete
Reference" appeared by popular demand: I quote you here: "A number of
people contributed to the current revision of this page. For
inspiration, I must of course credit Edward Nilges, whose tireless
crusade against the deficiencies of the previous version made it clear
that a more complete treatment was needed.". While your second Snarky
Tirade is also garbage, the misunderstanding YOU created about
editions was fixed, and this was productive.

2. If you'd "engaged" me on the buggy and one-line attempt you made
last February to write a strlen() function by email, you would have
been spared a great deal of embarassment, since I was the first to
notice the bug.

3. If you'd "engaged" me on your queue.c Coding Horror, I would have
been able to educate you on how to use structured programming in
coding a switch().

4. In fact, most of the threads I have been started have been on-topic
and have contained a great deal of useful C code conformant to the
charter of this newsgroup. The constant very offensive assaults on my
credibility aside, these have been useful to many people and you have
conceded this.

5. I posted the exact wording of the C standard as regards hosted and
freestanding environments. It demonstrates that to be standard C,
implementations do not have to provide a conformant main() or a
complete library to be standard (which implies that code written that
compiles with neither errors nor warnings but which has a
nonconformant main() is standard C). This in fact destroys much of
your case against Schildt and has cleared up something which has been
debated continuously here by people for several years owing to your
cover-up.

 

[spinoza1111]

I'm not sure why this poster said "You're never faced with ..."
I think in order for the thread to make sense, he has to have meant
something like "Every so often in life, you are faced with ..."

And, in that vein, yeah, it is cool for us geeky CLC types to want to
maintain that, yeah, we'd choose the money/fame/power over "being
right", and we claim that precisely because we know it isn't true.

Basically, the reason we're a bunch of CLC losers is precisely because
at key points in our lives, we've chosen to be right and to be true to
ourselves, instead of becoming marketing tools.  We should be honest
about that.  And, I can prove this very simply: Given our innnate
knowledge/skill/smarts, if we wanted to, we could easily have been
famous/rich/powerful/etc.  That we're not (and trust me, I've never
heard of any of the CLC gang outside of CLC) these things, speaks all.[/QUOTE]

Minor point: Seebach and Heathfield are known as authors outside of
CLC as I am. The most externally distinguished person here is Navia.

I've always said (of myself) that if I had had any ambition at all, I'd
be a billionaire now.

There are as I'm sure you are aware of becoming distinguished, other
ways than to be a shitbag "god of the cloud" like Torvalds or Jimmy
Wales. Dijkstra was relative to his contribution not very famous.
Tanenbaum is a better man than Torvalds.

"Let us now praise famous men, and our fathers that begat us...And
some there be, which have no memorial; who are perished, as though
they had never been; and are become as though they had never been
born; and their children after them. But these were merciful men,
whose righteousness hath not been forgotten."

Ecclesiasticus, Chapter 44

Very good point, and well said.

And again, I'd say that most CLCers would not be afraid to "speak truth
to power" - at whatever personal peril that entailed.

I must disagree.

--
(This discussion group is about C, ...)

Wrong.  It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

Perhaps in a fucked up society, the childhood trauma of bullying can
never be resolved if bullying is a vector of power. It's too useful.
And perhaps realizing and applying this can exclude the bullying of
the regs and this can be a better resource.

"Those however who always defiantly stirred up trouble against the
teacher and, as one called it, disturbed the lesson, the day – indeed,
the hour – they graduated from high school, they sat down with the
same teachers at the same table with the same beer, as a confederation
of men, who were born followers, rebels, whose impatient blows of the
fist on the table already drummed the worship of the masters. They
need only stay put, to catch up with those who were promoted to the
next class, and revenge themselves on them. Since they, officials and
candidates for death sentences, have stepped visibly out of my dreams
and have expropriated my past life and my language, I don’t need to
dream of them any longer. In Fascism, the nightmare of childhood has
realized itself."

 

[spinoza1111]

spinoza1111wrote:


That's not what he said. He said that the C Standard mandates
implementation support with defined semantics for a program with a
return type of int for the main() function, for hosted implementations.
That is true. Your inability to understand a truth does not invalidate
that truth.

(Sigh) (Eyeroll) (Crotch grab)

We understand. However, this "truth" only applies to hosted
implementations, not to freestanding implementations, and freestanding
implementations are just as standard. You've been covering this up.

 

[Mark]

(Sigh) (Eyeroll) (Crotch grab)

We understand. However, this "truth" only applies to hosted
implementations, not to freestanding implementations, and freestanding
implementations are just as standard. You've been covering this up.

From the version of the standard I have to hand (ISO/IEC 9899:1999(E)),
section 4 (Conformance) confirms that the two forms of conforming
implementation are "hosted" and "freestanding".

Later on, section 5.1.2.1 defines a freestanding environment as part of
its definition of a freestanding 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.

I can't see an interpretation of that which involves an OS such as
Windows, MacOS, Unix, Linux or similar which would fulfill that
definition. They are specifically designed to *prevent* execution of
programs outside of the OS.

The hosted environment definition (section 5.1.2.2) says:

A hosted environment need not be provided, but shall conform to the
following specifications if present.

And then goes on (section 5.1.2.2.1) to define program startup:

The function called at program startup is named main. The
implementation declares no prototype for this function. It shall be
defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv, though
any names may be used, as they are local to the function in which
they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent[9]) or in some other implementation-defined manner.

9) Thus, int can be replaced by a typedef name defined as int, or
the type of argv can be written as char ** argv, and so on.

which gives no room for confusion.

Thus, if I write a program to run outside an OS, I can define any
function I like (any name, any parameters and with any return type which
C allows) and remain conformant. If, on the other hand, I write a C
program to be compiled and run within an OS, it shall return an int or
it doesn't conform to the standard.

It really is that simple.

 

[spinoza1111]

From the version of the standard I have to hand (ISO/IEC 9899:1999(E)),
section 4 (Conformance) confirms that the two forms of conforming
implementation are "hosted" and "freestanding".

Later on, section 5.1.2.1 defines a freestanding environment as part of
its definition of a freestanding 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.

I can't see an interpretation of that which involves an OS such as
Windows, MacOS, Unix, Linux or similar which would fulfill that
definition.  They are specifically designed to *prevent* execution of
programs outside of the OS.

Reread the passage: "in which C program execution MAY take place
without any benefit of an operating system".

It doesn't say "must".

"Freestanding" doesn't mean that the OS isn't present. It means that
the OS is unknown and that there is for this reason no constraint on
main(). main() doesn't have to be present, or it may have a
"nonstandard" form (such as void main).

For example, a Windows DLL without a main() procedure is freestanding.

As I have said, the Standard is not intended to be read by
programmers, and the fact that it's been so misread by you shows this.
It was meant for compiler developers and people with formal education
in computer science who haven't been moronized by corporate life.

The hosted environment definition (section 5.1.2.2) says:

    A hosted environment need not be provided, but shall conform to the
    following specifications if present.

And then goes on (section 5.1.2.2.1) to define program startup:

    The function called at program startup is named main. The
    implementation declares no prototype for this function. It shall be
    defined with a return type of int and with no parameters:

        int main(void) { /* ... */ }

    or with two parameters (referred to here as argc and argv, though
    any names may be used, as they are local to the function in which
    they are declared):

        int main(int argc, char *argv[]) { /* ... */ }

    or equivalent[9]) or in some other implementation-defined manner.

    9) Thus, int can be replaced by a typedef name defined as int, or
       the type of argv can be written as char ** argv, and so on..

which gives no room for confusion.

Thus, if I write a program to run outside an OS, I can define any
function I like (any name, any parameters and with any return type which
C allows) and remain conformant.  If, on the other hand, I write a C
program to be compiled and run within an OS, it shall return an int or
it doesn't conform to the standard.

Not correct. The freestanding environment's OS is UNDEFINED. It can be
present or absent.

Therefore, if I write C to be compiled and run within an OS, and I do
not intend this program to be run from a command line, the C is
standard C if it doesn't have a main(), or even if it does. Many
compilers will issue a warning in the latter case, but the code is
still a standard freestanding program.

It really is that simple.

No, it isn't, and the confusion shows why programmers MUST take
computer science. Heathfield and Seebach seem unfamiliar with the sort
of "academic" language which uses modal logic in the sense that it's
less concerned with the "must be" of the "here and now", but with
possibility.

They seem incapable of understanding how a freestanding program is
agnostic about its OS and imagine the OS to be "not there" when it is
"unknown to be there".

This is connected to the superstition that C can be "just as portable
as Java". It is argued that C is "portable like Java" by pointing to
the possibility of a bug in the Java runtime. Other coders here brag
about how they "ported" C by making changes to code that depended on
endianness and IBM timer differences.

 

[Mark]

Reread the passage: "in which C program execution MAY take place
without any benefit of an operating system".

It doesn't say "must".

Agreed, but if the definition of "freestanding environment" is that,
you'd expect environments which are freestanding to allow (if not
enforce) that.

Which OSs are you thinking of which do allow C program execution
*without* any benefit of an operating system?

"Freestanding" doesn't mean that the OS isn't present. It means that
the OS is unknown and that there is for this reason no constraint on
main(). main() doesn't have to be present, or it may have a
"nonstandard" form (such as void main).

Read it again. It doesn't say that.

For example, a Windows DLL without a main() procedure is freestanding.

A windows DLL is not a C program executable and, therefore, doesn't have
to fulfill that until and unless it's executed. At that point, the
program linked in with it *combined* with DLLs would be expected to
fulfill these requirements.

As I have said, the Standard is not intended to be read by
programmers, and the fact that it's been so misread by you shows this.
It was meant for compiler developers and people with formal education
in computer science who haven't been moronized by corporate life.

What have I misread?

Not correct. The freestanding environment's OS is UNDEFINED. It can be
present or absent.

See above.

Therefore, if I write C to be compiled and run within an OS, and I do
not intend this program to be run from a command line, the C is
standard C if it doesn't have a main(), or even if it does. Many
compilers will issue a warning in the latter case, but the code is
still a standard freestanding program.

Where does it mention a command-line?

No, it isn't, and the confusion shows why programmers MUST take
computer science. Heathfield and Seebach seem unfamiliar with the sort
of "academic" language which uses modal logic in the sense that it's
less concerned with the "must be" of the "here and now", but with
possibility.

My B.Sc. is in Computer Science. I taught software engineering for
several years in a CS department at a major UK University. I am now
head of IT for an Engineering and Computing faculty at the same
University.

 

[Nick Keighley]

we have to do this as the freestanding implementations are all held in
Area 51 with the UFOs. Sorry just joking! there is no cover up!!

I always assumed that people who described windows C compilers as
"freestanding" were indulging in a teckie joke.

Just as spinoza isn't *really* playing with himself as he posts. One
can hope anyway.

Reread the passage: "in which C program execution MAY take place
without any benefit of an operating system".

It doesn't say "must".

"Freestanding" doesn't mean that the OS isn't present. It means that
the OS is unknown and that there is for this reason no constraint on
main().

this is an... ingenious reading of the passage

the plain intent is that freestanding is "without an OS". The names
tend to give it away.

main() doesn't have to be present, or it may have a
"nonstandard" form (such as void main).

For example, a Windows DLL without a main() procedure is freestanding.

only for a very lawyerly reading of the text. I shouldn't think it was
Microsoft's intent.

As I have said, the Standard is not intended to be read by
programmers,

you've said it and I don't agree. The C Standard is quite readable and
very useful for getting the "last word". I used to use the standard as
my first port of call for the library. I now use the web as I can cut
and paste directly into my code. I still use the standard to check
language stuff (though this is pretty rare now).

and the fact that it's been so misread by you shows this.
It was meant for compiler developers and people with formal education
in computer science who haven't been moronized by corporate life.

I score one out of two there

The hosted environment definition (section 5.1.2.2) says:

    A hosted environment need not be provided, but shall conform to the
    following specifications if present.

And then goes on (section 5.1.2.2.1) to define program startup:

    The function called at program startup is named main. The
    implementation declares no prototype for this function. It shall be
    defined with a return type of int and with no parameters:

        int main(void) { /* ... */ }

    or with two parameters (referred to here as argc and argv, though
    any names may be used, as they are local to the function in which
    they are declared):

        int main(int argc, char *argv[]) { /* ... */ }

    or equivalent[9]) or in some other implementation-defined manner.

    9) Thus, int can be replaced by a typedef name defined as int, or
       the type of argv can be written as char ** argv, and so on.

which gives no room for confusion.

Thus, if I write a program to run outside an OS, I can define any
function I like (any name, any parameters and with any return type which
C allows) and remain conformant.  If, on the other hand, I write a C
program to be compiled and run within an OS, it shall return an int or
it doesn't conform to the standard.

Not correct. The freestanding environment's OS is UNDEFINED. It can be
present or absent.

Therefore, if I write C to be compiled and run within an OS, and I do
not intend this program to be run from a command line, the C is
standard C if it doesn't have a main(), or even if it does. Many
compilers will issue a warning in the latter case, but the code is
still a standard freestanding program.

Microsoft then go on to provide 99.9% of what is necessary for a
hosted environment. I think their intent was palinly to provide a
hosted environment and you are just being a silly person.

No, it isn't, and the confusion shows why programmers MUST take
computer science.

I've met very many very competant programmers that do not have formal
qualifications in computer science. In some cases no knowledge of it
all. They have different strengths. (for instance Electronic Engineers
have a better appreciation of hardware). After you've been out of
formal education for a decade or so it becomes much less important
what your degree was in. Unless you think education and learning is a
camel thing. Soak up as much as you can at the oasis (university) then
live off your stored education as you trudge across the desert of
life. Some of us have cracked a textbook since leaving university.

Weinberg "Psychology of Computer Programming" argued that ability in
their native language was as good an indication as anything else. At
one time IBM hired English language graduates and trained them to
program on the job.

Heathfield and Seebach seem unfamiliar with the sort
of "academic" language which uses modal logic in the sense that it's
less concerned with the "must be" of the "here and now", but with
possibility.

They seem incapable of understanding how a freestanding program is
agnostic about its OS and imagine the OS to be "not there" when it is
"unknown to be there".

<snip>

 

[Mark]

The Standard doesn't say so explicitly, however - and, going by the
wording of the Standard, some OS-based implementations are indeed
freestanding.

I really do think that would depend on a particular definition of "OS".
One I'd be happy with, but which wouldn't be applicable to current
mainstream OSs...

 

[Seebs]

I always assumed that people who described windows C compilers as
"freestanding" were indulging in a teckie joke.

Not really. "Without the benefit of an OS" is an *example* of "freestanding",
but in fact, it is also used (by intent, so far as I know) to cover C
implementations running on an OS which isn't enough like the standard
ones to allow for stdio.

this is an... ingenious reading of the passage

the plain intent is that freestanding is "without an OS". The names
tend to give it away.

"Without the *benefit of* an operating system".

There may be an OS there, but it isn't helping much. We use freestanding
code today. We target embedded systems. Some of the multicore ones have
a stripped-down library that allows you to build a completely self-contained
executable image, without most OS services, to run on a single core. The
Cell Linux environment did the same thing; it had hooks for running code on
the secondary cores, and that code wasn't *really* hosted C code, it was
just a freestanding implementation that, for convenience, provided a lot
of familiar functionality.

only for a very lawyerly reading of the text. I shouldn't think it was
Microsoft's intent.

I wouldn't either, but I am told that there was a time, within living memory,
when "sprintf()" wasn't available for the default compilation of Windows
GUI apps, and the rationale was that they were freestanding, and didn't
have stdio at all.

Microsoft then go on to provide 99.9% of what is necessary for a
hosted environment. I think their intent was palinly to provide a
hosted environment and you are just being a silly person.

Their implementation was not driven by the C standard. It turns out that,
to have a functioning OS, you pretty much have to be theoretically able
to provide a hosted environment.

<snip>

Which is a hilarious example of how Nilges can snatch defeat from the jaws
of victory -- I'm one of the only people to back him on one tiny claim here,
and his response is to lie about it and claim I didn't.

-s

 

[Seebs]

I really do think that would depend on a particular definition of "OS".
One I'd be happy with, but which wouldn't be applicable to current
mainstream OSs...

Sure it would, because the claim isn't that something isn't running under
an OS, but that it's running without the benefit of the OS. Which, from a
C standpoint, it isn't. If the OS does not provide stdin/stdout/stderr,
then the program has been denied that benefit.

The intent of WinMain() was absolutely to sever the program from the
usual C environment and express that this was a Different Kind Of Program.

And that's what makes this entire argument pointless -- Schildt is
unambiguously writing about programs declared using main(), and even in
Windows-land, those were always hosted.

-s

 

[Richard Harnden]

Sure it would, because the claim isn't that something isn't running under
an OS, but that it's running without the benefit of the OS. Which, from a
C standpoint, it isn't. If the OS does not provide stdin/stdout/stderr,
then the program has been denied that benefit.

The intent of WinMain() was absolutely to sever the program from the
usual C environment and express that this was a Different Kind Of Program.

And that's what makes this entire argument pointless -- Schildt is
unambiguously writing about programs declared using main(), and even in
Windows-land, those were always hosted.

Schildt's book was about DOS, not Windows - I dunno if Windows even
existed when it was published.

Does C:TCR (any editon) mention hosted/freestanding?

 

[Seebs]

Schildt's book was about DOS, not Windows - I dunno if Windows even
existed when it was published.

By the time of the 4th edition, it did -- but it was still written about
the hosted implementation, not the freestanding one.

Does C:TCR (any editon) mention hosted/freestanding?

Not that I ever noticed.

-s