"void main" is a lifestyle choice 
Author Message
 "void main" is a lifestyle choice

If "int main" is now deemed politically correct to ANSI compilers, can
somebody please explain to me, now that I'm forced to return an integer,
how I can fulfil that obligation?

I've never seen any C programs apart from trivial ones, that do not call
other functions from main. Including ones that take care of terminating
the program. The common way to terminate while returning an integer to
the system is to use the ANSI exit() function.

So if ANSI sanctions the use of exit(), how is it possible for me to
simultaneously comply with the main function's requirement to execute a
proper return statement?

I've never been forced to return a value in my functions by anybody. I
write them that way if a returned value is merited, and the calling
function can make use of one. It's between consenting functions. In the
case of main, also a function I write myself by-the-way, I can see no
reason to return a value. It's my programming life.

If returning a value by main is mandated, then I expect to see a law
(prototype) for it. The exit function should then be removed for
violating the ANSI approved program flow. Hyprocrites.

I do not relish the added complexity of having to carry all sorts of
context and flags down to the deepest nesting of my functions in the
event that I may need to exit suddenly. I now have to return all the way
back to main to be able to "return" legally.

Thank you, big brother committee, for implicitly dictating how I
structure my program's exit points. Get out of the nation's cubicles!

I challenge every programmer to try and write a complicated application
that has only one permissible exit point - in main. We have to return an
integer according to the new prototype-order, now don't we?

We can not change the C style we're born with. So before we all jump on
the ANSI bandwagon, let's not forget the freedoms we're willing to give
up. This is not just a K&R issue. The new criteria affects everyone.



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

   If "int main" is now deemed politically correct to ANSI compilers, can
   somebody please explain to me, now that I'm forced to return an integer,
   how I can fulfil that obligation?

`return 0;'?

   I've never seen any C programs apart from trivial ones, that do not call
   other functions from main. Including ones that take care of terminating
   the program. The common way to terminate while returning an integer to
   the system is to use the ANSI exit() function.

That's fine.

   So if ANSI sanctions the use of exit(), how is it possible for me to
   simultaneously comply with the main function's requirement to execute a
   proper return statement?

If your program terminates from another function, that's fine.  But
main() *must* be declared as returning an int.

   I do not relish the added complexity of having to carry all sorts of
   context and flags down to the deepest nesting of my functions in the
   event that I may need to exit suddenly. I now have to return all the way
   back to main to be able to "return" legally.

Go away troll.
--
"In My Egotistical Opinion, most people's C programs should be indented six
 feet downward and covered with dirt." -- Blair P. Houghton
Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice
On Sun, 28 Feb 1999 20:39:45 GMT, Sven

Quote:

>If "int main" is now deemed politically correct to ANSI compilers, can
>somebody please explain to me, now that I'm forced to return an integer,
>how I can fulfil that obligation?

By adding a simple

  return 0;

at the end of main. Is it really so painful? I don't know where you
get this "now" idea from, as though this has been sprung on you all of
a sudden. It's old news in C, and older still in the wider world.

-- Mat.



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

Quote:

> By adding a simple

>   return 0;

> at the end of main. Is it really so painful?

You don't see any problem with including a statement that you know will
never be executed, just to satisfy syntax convention?

"return 0" will do nothing but mislead others looking at the code -
especially when throughout your other functions you're returning exit(3)
or exit(10) or whatever.

Stop defending a worthless ANSI requirement that has no semantical
merit.

Sven



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

Quote:

>If "int main" is now deemed politically correct to ANSI compilers, can
>somebody please explain to me, now that I'm forced to return an integer,
>how I can fulfil that obligation?

You aren't required to return an integer. You are required to declare main as
having a type which indicates an int return value. There is a difference
between declaring a return value and actually executing the return.

If you main function does return, then you should return a value to indicate
the termination status, otherwise the termination status is undefined.  If your
main doesn't return, then there is no need to worry.

Quote:
>I've never seen any C programs apart from trivial ones, that do not call
>other functions from main. Including ones that take care of terminating
>the program. The common way to terminate while returning an integer to
>the system is to use the ANSI exit() function.

False. This is not a common way of terminating a program at all. Where I work,
you would get a NERF football thrown at you hard if you put exit() anywhere in
the code. And believe me, that stings. A subordinate module has no right to
take control into its own hands and terminate the entire software system.

I have seen substantially complex programs that shut themselves down and exit
from main(). The exit() function should be reserved for trivial programs.

By the way, void main() is not a lifestyle choice. That's what my grandparents'
generation used to believe, which led to great discrimination against void main
users.  We now know that void main use in {*filter*} life is either hereditary or is
brought about in the unborn by bio-chemical factors during the gestation
period, not unlike some forms of mental retardation. Nobody understands the
precise causes, but it's very difficult for a void mainer to go straight. Sure,
some may delude themselves into writing int, but deep down inside, they remain
e{*filter*}d by the idea of putting down void.  Void main users deserve our sympathy
and understanding; but for practical reasons they should still be kept away
from software development tasks.

Quote:
>So if ANSI sanctions the use of exit(), how is it possible for me to
>simultaneously comply with the main function's requirement to execute a
>proper return statement?

>I've never been forced to return a value in my functions by anybody. I

That's because those were YOUR functions, whose type signatures were invented
by you. The main function is not yours. It is the interface between your
program and the outside world. Someone else already invented this interface
and it became a part of the international C language standard. The standard
gives you a choice of two possible type signatures. (Individual implementations
may permit additional type signatures which are not standard.)

Quote:
>write them that way if a returned value is merited, and the calling
>function can make use of one. It's between consenting functions. In the
>case of main, also a function I write myself by-the-way, I can see no
>reason to return a value. It's my programming life.

The main function is one you write, but it's not one you invent.  Sometimes a
software developer has to follow externally imposed interface specification
even when writing things that appear new.

For example, if you were writing a device driver for an operating system, you
would have to obey a well-defined interface, even though you are writing the
functions yourself.  Whether or not you are given a header file that declares
the form of the interface is irrelevant. You still have to follow a spec.

A C program is sort of like a driver which plugs into an existing environment.
To correctly implement the driver, you must provide a single function called
main having a certain type signature.

If you don't follow that interface, then your program won't necessarily be
binary compatible with the environment into which it is loaded.

I mean, doh!

Quote:
>If returning a value by main is mandated, then I expect to see a law
>(prototype) for it. The exit function should then be removed for
>violating the ANSI approved program flow. Hyprocrites.

Utter nonsense. You have misunderstood the requirements.

The exit function exists for historical reasons and to make certain types of
programs convenient to write. In sufficiently simple programs, it's adequate to
call exit() and let the atexit() handlers perform any required cleanup.

In any case, the exit() function existed way before the language was
standardized by ANSI. There are other brain-damaged function which had to be
standardized because they were in widespread use, for example gets().

The exit() function once used to correspond to a UNIX system call.  On modern
UNIX systems, this role is usurped by _exit(). The exit() function has
user-level library cleanup tasks to perform, such as flushing stdio streams and
calling atexit() handlers.

Quote:
>I do not relish the added complexity of having to carry all sorts of
>context and flags down to the deepest nesting of my functions in the
>event that I may need to exit suddenly. I now have to return all the way
>back to main to be able to "return" legally.

When you start doing real software development, you will not be able to shy
away from doing the grunt work. Exception handling is a messy task, but it has
to be done, because it's not adequate to abort a complex piece of software at
arbitrary places in the code. This may leave the state of external resources in
a bad state! It also makes it difficult to reuse code. Who would want to reuse
a module that kills your program when something goes wrong? There are all kinds
of situations in which this isn't appropriate. But the main one is that
software should be robust and not quit in a cowardly manner at the slightest
problem with external resources.

Because exception handling often requires much effort, exception handling
facilities exist in some modern languages---they let you throw an exception in
the deepest level without having to process the information at every level.

In C, most exception handling chores can be carried out by returning a status
from each function that can fail. Every caller of the function checks the
return value and acts accordingly, performing any necessary cleanup before
propagating the failure to a higher level or otherwise recovering from the
situation.

Quote:
>Thank you, big brother committee, for implicitly dictating how I
>structure my program's exit points. Get out of the nation's cubicles!

>I challenge every programmer to try and write a complicated application
>that has only one permissible exit point - in main. We have to return an
>integer according to the new prototype-order, now don't we?

A few moths ago I wrote a protocol router/converter which satisfied the above
requirement. I'm working on a freeware macro preprocessor which also satisfies
the requirement, and a large and complex project at work which also exits
properly from main, when run as a console application. (when run as an NT
service, it has to obey a much more rigid interface for shutting down; if it
just naively quit by calling exit(), it would not properly interact with the
service control manager environment).


Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice


   > By adding a simple
   >
   >   return 0;
   >
   > at the end of main. Is it really so painful?

   You don't see any problem with including a statement that you know will
   never be executed, just to satisfy syntax convention?

You don't need to add a return if it will never be executed.  No one
is making you.  If it bothers you, don't put it in.
--
(supporter of the campaign for grumpiness where grumpiness is due in c.l.c)

Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

Quote:



>    > By adding a simple

>    >   return 0;

>    > at the end of main. Is it really so painful?

>    You don't see any problem with including a statement that you know will
>    never be executed, just to satisfy syntax convention?

> You don't need to add a return if it will never be executed.  No one
> is making you.  If it bothers you, don't put it in.

You're saying that despite all warnings my compiler gives me regarding
missing "return" statement for functions that have a return type, that I
can get away with it in "main"? Nothing like consistency.

And I was trying to make the point that any return statement I do put in
is most likely not even executed due to the fact that exit() is used
elsewhere.

Remember that lint or compilers set to their highest warning levels
don't understand program flow. They just see the function's header and
expect a proper return statement somewhere.

I'm questioning ANSI's requirement to add meaningless statements in my
code (such as "return 0"). If they left it as "void", then the meaning
of the function would not have been ambiguous - it does not HAVE to
return anything.

Sven



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice
return someInt;

you can also use the function call, "return;" if your function is of
type void, if you prefer to not "just fall of the end".

Better yet, you can use the statement, "return
an_int_that_by_gosh_i_really_did_not_want_to_return;"

Gary O.

Quote:

>If "int main" is now deemed politically correct to ANSI compilers, can
>somebody please explain to me, now that I'm forced to return an integer,
>how I can fulfil that obligation?

Gary O.



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

   > You don't need to add a return if it will never be executed.  No one
   > is making you.  If it bothers you, don't put it in.

   You're saying that despite all warnings my compiler gives me regarding
   missing "return" statement for functions that have a return type, that I
   can get away with it in "main"? Nothing like consistency.

You can get away with it anywhere.  Turn off the warnings.

   And I was trying to make the point that any return statement I do put in
   is most likely not even executed due to the fact that exit() is used
   elsewhere.

   Remember that lint or compilers set to their highest warning levels
   don't understand program flow. They just see the function's header and
   expect a proper return statement somewhere.

Obviously you're using crappy compilers.  Mine does understand program
flow to a limited extent, and will not output such warnings if you set
it up right.

   I'm questioning ANSI's requirement to add meaningless statements in my
   code (such as "return 0"). If they left it as "void", then the meaning
   of the function would not have been ambiguous - it does not HAVE to
   return anything.

Once again, ANSI doesn't require you to add a return statement.
Neither does your compiler.  If your compiler gives spurious warnings,
then you have several choices:

        1. Get a better compiler.
        2. Turn down the warning level.
        3. Ignore the warnings.
        4. Add a return statement anyway.

I can hardly believe that you are unwilling to do any of the above.
--
(supporter of the campaign for grumpiness where grumpiness is due in c.l.c)

Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice
On Sun, 28 Feb 1999 21:19:20 GMT, Sven

Quote:


>> By adding a simple

>>   return 0;

>> at the end of main. Is it really so painful?

>You don't see any problem with including a statement that you know will
>never be executed, just to satisfy syntax convention?

If the intention is that the return statement never be executed, I'd
use

  assert( FALSE );
  return EXIT_FAILURE;

to make clear that this is an abnormal termination.

Quote:
>"return 0" will do nothing but mislead others looking at the code -
>especially when throughout your other functions you're returning exit(3)
>or exit(10) or whatever.

If your programs typically terminate in such a disorganised manner,
you may well have more pressing style issues to worry about. If the
code you write ever makes it into a library for use by other programs,
you'll have to change it to use a more structured error handling
mechanism.

-- Mat.



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

   > Obviously you're using crappy compilers.  Mine does understand program
   > flow to a limited extent, and will not output such warnings if you set
   > it up right.

   None can understand program flow. A compiler can not determine ahead of
   time whether a function called in main will ever return control to main.
   The return statement at the bottom may or may not be unreachable based
   on external data.

I was referring to the specific GNU C compiler extension.  Does yours
have something similar?  Note that the following won't break
compilation under non-GNU compilers.

/* GNU C allows the programmer to declare that certain functions take
   printf-like arguments, never return, etc.  Conditionalize these
   declarations on whether gcc is in use. */
#if __GNUC__ > 1
#define __attribute__(X) __attribute__ (X)
#else
#define __attribute__(X)
#endif

/* Declare that main never returns. */
int main (void) __attribute__ ((noreturn));
--
"Large amounts of money tend to quench any scruples I might be having."
  -- Stephan Wilms
Please: do not email me copies of your posts to comp.lang.c
        do not ask me C questions via email; post them instead



Thu, 16 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice
: >

: >

: >    > By adding a simple
: >    >
: >    >   return 0;
: >    >
: >    > at the end of main. Is it really so painful?
: >
: >    You don't see any problem with including a statement that you know will
: >    never be executed, just to satisfy syntax convention?
: >
: > You don't need to add a return if it will never be executed.  No one
: > is making you.  If it bothers you, don't put it in.

: You're saying that despite all warnings my compiler gives me regarding
: missing "return" statement for functions that have a return type, that I
: can get away with it in "main"? Nothing like consistency.

: And I was trying to make the point that any return statement I do put in
: is most likely not even executed due to the fact that exit() is used
: elsewhere.

Few programs never make it to the end of their main() routine; those
that do this are generally embedded systems for which other rules for
calling main() apply.  If your code is calling exit(EXIT_FAILURE) then
there's a fair bet that something is watching the program's exit status;
so it seems reasonable, to me at least, that you return good status from
some point.  Could this point be the end of main()?

Will



Fri, 17 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

Quote:




>>>> By adding a simple
>>>>        return 0;
>>>> at the end of main. Is it really so painful?

>>> You don't see any problem with including a statement that you know will
>>> never be executed, just to satisfy syntax convention?

>> You don't need to add a return if it will never be executed.  No one
>> is making you.  If it bothers you, don't put it in.

> You're saying that despite all warnings my compiler gives me regarding
> missing "return" statement for functions that have a return type, that I
> can get away with it in "main"?

Ben went a bit too far.  Yes, to keep your compiler or lint
from complaining, you will probably need a "return 0" statement.
Yes, this is a statement that may never be executed, inserted
just to keep everyone happy.  Yes, inserting it will bloat your
executable by a few bytes.  All of that is okay in this case --
really.  If nothing else, it'll most certainly cost you less time
than arguing about it here.

Other options -- depending on your compiler or lint -- are to
tell your compiler or lint that your program's main function
(that is, the one called from main that does all the work and has
a call to exit buried somewhere down within it) never returns,
or to insert some kind of a "notreached" directive right after
the call to that function in main().  Either of these options
(if available) may serve to suppress the "control reaches end of
int-valued function without return" message, *without* polluting
your code with a statement which will never be executed.

Quote:
> Remember that lint or compilers set to their highest warning levels
> don't understand program flow.

Actually, many of them *do*.

Quote:
> I'm questioning ANSI's requirement to add meaningless statements in my
> code (such as "return 0"). If they left it as "void", then the meaning
> of the function would not have been ambiguous - it does not HAVE to
> return anything.

"They" couldn't have left it as void, because it never was void.
The defined return type of main has always been int.  main does
have to be a function returning int, because that's what the
calling code (remember, there is some code, namely in the
program's run-time start-up, that is going to call main) expects
it to be.

This is not to say that main actually has to return an int,
merely that it has to be declared as if it would.  Some day
(if there aren't already) there will be compilers that use
different calling conventions for functions that do and don't
return values.  When the calling conventions are different, it's
not beyond the bounds of possibility that using the int-valued
calling conventions (which the run-time start-up code *is* going
to use) to call a function which the programmer has impetuously
declared as void will cause a crash.

                                        Steve Summit



Fri, 17 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice

Quote:

> return someInt;

> you can also use the function call, "return;" if your function is of
> type void, if you prefer to not "just fall of the end".

Yes I know. By-the-way, "return" is not a function call. It's a C
keyword.

Quote:
> Better yet, you can use the statement, "return
> an_int_that_by_gosh_i_really_did_not_want_to_return;"

Nothing like obfuscating your code with meaningless constants that are
not meant to be looked at by the calling program. Aren't we encouraged
to write code for legibility anymore?

Anyway, I'm talking about "main". My point was that by insisting on the
function's type int, I can no longer just "fall off the end". I must now
return something. And any return statement I do put in is most likely
not even executed due to the fact that exit() is used elsewhere.

I'm questioning ANSI's requirement to add meaningless statements in my
code. If they left it as "void", then the meaning of the function would
not have been ambiguous - it does not HAVE to return anything.

Sven



Fri, 17 Aug 2001 03:00:00 GMT  
 "void main" is a lifestyle choice
On Sun, 28 Feb 1999 20:39:45 GMT, Sven

        [snip]

Quote:
> I've never been forced to return a value in my functions by anybody. I
> write them that way if a returned value is merited, and the calling
> function can make use of one. It's between consenting functions.

                                             ^^^^^^^^^^
<Jack>

Since you didn't write the code which calls main(), and you can't
change it, you certainly can't make it consent to call a function
returning void when it was written to call a function returning int.

The normal execution of a C program in a conforming hosted environment
is:

exit(main(argc, argc));

By calling exit() directly you are bypassing the need to return from
main.  There can be some differences between the two solutions if
functions have been registered with atexit().

</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.



Fri, 17 Aug 2001 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. what's the difference between void main(void) and int main(void)

2. How to "Remember" user choices

3. What's The Difference Between "typedef void *" and "void *"??

4. I am going to study "C"

5. main(void) vs void main ()

6. void main(void) or int main() ??

7. problem with "void"

8. what is "static void usage()"?

9. printf("%p\n",(void *) ptr);

10. Newbie: declaring the "main" function

11. Override "X" in main frame

12. What's "main application window"?

 

 
Powered by phpBB® Forum Software