Re: Is this Standard C++: int main(int argC, char* argV[])?

From: tom_usenet (tom_usenet_at_hotmail.com)
Date: 06/10/04 

Date: Thu, 10 Jun 2004 18:29:44 +0100

On Thu, 10 Jun 2004 13:09:29 -0400, "Steven T. Hatton"
<susudata@setidava.kushan.aa> wrote:

>Robert Bauck Hamar wrote:
>
>
>> Of course you have.
>> $ cat example.cc
>> #include <iostream>
>>
>> int main(int, char **, char *e[])
>> {
>> for (; *e; ++e)
>> std::cout << *e << std::endl;
>> }
>> $ g++ -ansi -Wall example.cc
>> $
>
>Interesting bit of hackery.
>
>> As you can see. This compiles without a warning on my compiler, and this
>> little program will print out my environment variables. A conforming
>> compiler is not required to compile this, but it is explicitly allowed
>> to.
>
>"Explicitly"? That seems a bit strong. How do you argue that it is explicit
>about this? The undefined catch-all?

No, the standard says that the type of main is implementation defined,
except that it must return int. It then goes on to say that int main()
and int main(int argc, char* argv[]) *must* be provided by all
implementations. So the above is just an implementation defined main
signature.

As for the naming of variables, I really don't think that the intent
of the standard is to ban naming the first and second parameter of
main whatever you want, but simply to give the required signatures of
main that should be available. The wording of the standard talks about
"allowing the following definitions of main". My understanding is that
it refers to the signatures, not the literal characters shown. So I
think that

int main(int const bubbles, char** fun)
{
}

is fine (note that top-level const in parameter types is not part of
the function signature).

Tom 

-- 
C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

Relevant Pages

  • Re: pointers?
    ... int foo ... If the compiler takes the effort to actually recognize that this is ... addresses do not work like in a flat address space. ... "contiguous region" in the standard document. ...
    (comp.lang.forth)
  • Re: Unknown function
    ... int main ... message) "the compiler actually dos not "know" the signature of malloc()", I understand it in the way that malloc is not known to the compiler at that specific point of program. ... What the standard mandates that the compiler must do and what the compiler can do in addition to what the standard mandates. ...
    (comp.lang.c)
  • Using restricted pointers with newly allocated arrays/structures
    ... return (int) x; ... The use of "restrict" here is intended to inform the compiler that x ... However, according to 6.7.3.1p4 of the standard, the code seems to ... based on restricted pointer x, is used to access the object x(and ...
    (comp.std.c)
  • Re: Memory allocation for an initialized character pointer;
    ... But this would be the kind of extension that a compiler wouldn't be ... explicitly mentioned in the standard, a compiler can now accept it in ... Since no strictly conforming program can use ... normally the int value returned from main, ...
    (comp.lang.c)
  • Re: whats wrong with atof() and casting?
    ... The return type of the function was int, ... Since atofDOES NOT return an int, this is wrong and undefined behavior. ... Note that a compiler is not required to do anything at all when you ... There is no requirement in the C standard that they do. ...
    (comp.lang.c)