On Fri, 11 Mar 2005 08:02:10 -0800 (PST), perthie <perthie@yahoo.com> wrote:
>
> > > main() {prinf("doh!\n")}
> >
> > Nitpick: Technically that's not correct ANSI C.
> >
>
> which standard are you referring to? technically, its correct in c89
> and i believe also in c99 (though ive never read it so i dont know).
> explainations follow.
The missing semicolon is bad (overlooking the misspelling of printf).
> > * The return type (int) should be specified.
>
> the return type if unspecified is assumed to be int. its good
> programming practice to specify the return type, but its not required
> or pedantically incorrect according to ANSI/ISO.
I said should, not must. It is bad form to include it.
> > * printf is not declared.
>
> correct. however it should be noted some compilers will include stdio.h
> automagically, namly gcc.
GCC doesn't include it automatically. It simply defaults to declaring it as
int printf(). The implicit declaration.
> > * printf really shouldn't be used for this, puts should be. Some
> > (stupid)
> > implementations of varargs don't handle vararg functions with only
> > on argument.
>
> this is an implementation issue, not a standards issue. the standard
> allows for examples such as these. if you're using a non-compliant
> compiler, then you're going to have problems no matter how pedantically
> correct you write the code.
Still, puts is probably a few millionths of a second faster. ;)
> > * the semicolon after printf is missing.
>
> yup.
>
> > * There is no return statement. main must return an integer value.
> >
>
> also not true according to the standard, however your compiler should
> issue a warning (unless of course you treat warnings as errors).
And the return value of the program will be undefined;
on my box it is 5 -- which should indicate an error.
> > Though, at least you didn't write "void main".
> > That's so completely incorrect, and I can't say how many times I've
> > seen people type that on slashdot...
> >
>
> and the reason its so popular is because most people dont care what the
> standard says, and in many cases, rightfully so. programs are supposed
> to solve problems. likewise, if a program solves a problem, then it is
> correct for all practical purposes. additionally, few programs are 100%
> ansi compliant these days due the the need for implementation specific
> extensions and libraries.
Actually, it is getting better. The vast majority of C code is correct because
running GCC without -ansi -Wall -pedantic leads to many undiscovered bugs.
So it takes more time to write bad code than good.
void main will produce an error in any sane compiler, and the return
value of the program will be undefined (just like when you don't have
a return statement, or use the exit() function). Undefined behavior is
very bad, because on my machine it might return 5, and on some other
machine it might return 0. Not good at all.
here's a void main C program:
% gcc bar.c
bar.c: In function `main':
bar.c:1: warning: return type of `main' is not `int'
It's not about being 100% compliant, it's about not being
complier-detectably wrong. :)
I don't really care about being 100% compliant, I just care about
detecting errors that produce undefined behavior and/or produce
incorrect programs.
> code such as the above is only a problem in environments where the code
> must be *guarenteed* to work or must be maintainable 10 years after its
> written. i sincerly hope the above program needs no maintenance in
> 2015. :)
I write for the future. Because when I solve a problem, I like to
solve it forever. I'm lazy. Baring things are beyond my control (new
standards, no support for legacy libraries) any code I write now will
still run a decade from now.
> > A correct implementation would be:
> > #include <stdio.h>
> > int main() {
> > puts("doh!");
> > return 0;
> > }
> >
>
> or
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main(void) {
> puts("doh!");
> return EXIT_SUCCESS;
> }
That's good if you want to port it to places like VMS where programs
return 0 on error and 1 for success. :)
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:33:09 EDT