A note on the void main() canard

[Kenny McCormack]

Of course a doctor would never say "you suck" to another doctor who
was, for instance, questioning the applicability of a treatment to
ethnic groups on whom it hadn't been tested, even if the objection was
patently unsound. Not would an lawyer say that to another lawyer who
was complaining, falsely, of inconsistent interpretations of some tax
regulations.

Not all professions are the same.

TSD is certianly showing himself to be a loon today.

--
(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 [sic] revelations of the childhood
traumas of the participants...

 

[Stargazer]

Either you want to write code that is compliant or you don't.  Nobody

The problem is that, for almost every rule, there's a processor
architecture out there that makes it desperately inconvenient to
implement in a C compiler.

Not true. Almost all architectures are *convenient* to implement a C
compiler for. Old architectures were taken into account by K&R's
language design, newer atchitectures forsee necessity to get a
conforming C compiler by their design. As a prominent example, GCC
does a good job of abstracting a really big number of different
architectures.

For instance logical ops won't work as
expected if the machine doesn't use two's complement notation.

Logical ops may not work not as expected on something that is not a
binary computer. Something that will have hard time to prove itself
today. Nothing to do with 2's complement.

Some architectures don't like being asked to left-shift a register by more
than one less than the number of bits it contains. There's padding and
trap representations,. alignment issues, non-flat memory spaces,
achitectures where bytes are not octets. The response of the standard
drafters is to to call in "undefined behaviour", or "implementation-
defined behaviour", giving the implementation the freedom to comopile
code efficiently and easily.

No, response of the standard is to define a set of "least common
denominator" rules, which all (hopefully) binary computer
architectures *can* implement. Some useful cases for undefined-
behavior code include hardware specifics for CPU internal structures
handing by OS, device drivers and BSP code. In those cases C is used
for convenience of HLL rather than portability, and there's nothing
for standard drafters to do with that in order to aid, more than
define what is safe to use (for, say, a portable OS) and what is
completely programmer's premise and architecture knowledge ("undefined
behavior").

 

[spinoza1111]

Consider an OS that can launch an executable, only
communicates through a stack, and expects each executable
it launches to push a value onto the stack.

If the OS launches a badly behaved executable that does
not push a value onto the stack things can break.

Gee thanks for explaining to me, what I've explained already to you
Monkey in the deep green jungle see, monkey in de jungle do
I seem to be dealing with Fred Flintstone or Barney Rubble
Fire burn and caldron bubble
Betty and Wilma singing yabba dabba doo.

[Note the OS can make things a lot more robust, by
pushing a sentinel value, e.g. 169, onto the stack,
always use to top value as the return value
and pop twice on return iff the top value is not
the sentinel value.  Now things only break
if the executable pushes more than one value
or returns the sentinel value, and maybe not even then.]

Doesn't really close the leak, does it. Kind of like my field repair
to my shower until I can get the super to fix it, because you're
exposed to some clown stacking the sentinel. I already explained a
better way that STILL won't work: save the size of the stack before
calling the executable...in a local variable...oops...as Schildt would
know (what with that MSCS and shit) and Seebach wouldn't, that would
be on the...stack...dang.

Ooooohhhh how about putting it on the C drive...get a life...what eeef
you doan't got no steeenking deesk drive.

Ooooh I got it...the Windows Registry...yeah right...

In the general scientific sense, you're fucked. Basically, C
programmers out of vanity feel that they're like the Blues Brothers,
onna mission from God, and need to communicate with shell procedures
important stuff, like hey, I finished. The decision to define the
interface rigidly for "hosted" environments was the best one. But it
does NOT entail that void main() is "nonstandard C".

What should a C implementation faced with void main()
do.

    -it could refuse to produce an executable.

Good idea. General Strike!

    -it could produce a badly behaved executable

    -it could produce a well behaved executable,
     (maybe by wrapping main by bados_main, which
     always returns a value, the value provided by
     main() if it exists, otherwise 0. Note bados_main
     may have to use implementation magic to determine
     the return type of main)

Hmm, that was my idea, wasn't it. God I love this zoo.

I don't see the failure of the C standard to mandate the
third behaviour as a "deficiency".

Of course you don't.

 

[spinoza1111]

Of course a doctor would never say "you suck" to another doctor who
was, for instance, questioning the applicability of a treatment to
ethnic groups on whom it hadn't been tested, even if the objection was
patently unsound.

Generally speaking, no. However, my father questioned the Carter era
redefinition of "death" as certified by a physician to mean just brain
death, preferring that he, the physician, have more leeway when
there's no brain activity but other vital signs exist.

He accused the medical establishment of wanting to declare poor people
prematurely dead in order to harvest their organs yielded up to them
for free (like Linux to IBM).

He was treated badly by the Chicago medical establishment, perhaps not
by that language, but certainly unprofessionally. He was, however,
welcomed to speak in Australia on his ethical concerns.

American-born doctors were patronizing of him since he was not a
physician at a teaching hospital...although he'd been second in his
class at Harvard. Foreign-born docs liked him.

His critiques of the medical establishment were far more literate than
most other doctors could write.

 

[Tom St Denis]

[citation needed]

Either you want to write code that is compliant or you don't.  Nobody
Actually, nobody here seems to be able to do that, by design.

According to you, but I have long since questioned your ability to
develop software.

As for the rest of us professionals we write software that is used on
a variety of platforms with nary a portability problem.  Not our fault
you suck.

Tom

What variety of platforms does your SW run on and what UIs do you
employ?

We run on Linux distros like Ubuntu, Fedora Core, and random Debians
on x86_64, x86, ppc, arm. We also run in embedded RTOS systems, and
bare metal. In fact our code is routinely executed on platforms we
don't even have access to. Modulo some nitty hardware interface stuff
our pure SW projects tend to have zero defects in portability.

HW/SW layer defects come up since they're out of the scope of what you
can control with pure ISO C. Though even then things usually get
resolved within a day or two [endianess flags, etc]..

Tom

 

[Dennis \(Icarus\)]

Of course a doctor would never say "you suck" to another doctor who
was, for instance, questioning the applicability of a treatment to
ethnic groups on whom it hadn't been tested, even if the objection was
patently unsound. Not would an lawyer say that to another lawyer who

If the doctor persisted, even after being shown the objection was "patently
unsound" though......

was complaining, falsely, of inconsistent interpretations of some tax
regulations.

If the lawyer persisted in his erroneous belief, even after others had shown
why the interpretation was wrong, or it was yet another instance of a long
history of inconsistent interpretations, they may well say that.

Dennis