Skip to content

CWG2811 [basic.start.main] Clarify what it means to "use" main #422

Closed
cplusplus/draft
#6906

Description

@eisenwave

Reference (section label): [basic.start.main] p3

Short Issue Description

In [basic.start.main] paragraph 3, it is unclear what "use" of the function main means.

Long Issue description

The accepted proposal N3214 by @jensmaurer made the following change:

Replace all occurrences of the word "use" that are not intended as references to 3.2 with some other term, such as "occurrence" or "appearance" or "reference to".

However, this resolution was not correctly applied to [basic.start.main] p3:

 The function main shall not be used
-(3.2 basic.def.odr)
 within a program.

This change violates the proposed resolution but might be deliberate, not accidental, because the first revision of N3154 did replace "use" with "odr-use", and this was later reverted.

It remains unclear what constitutes "use" of main and implementers seemingly disagree. Only Clang considers decltype(main) to constitute use of main (https://godbolt.org/z/6MPWfPzYK) and issues a warning:

<source>:2:24: warning: ISO C++ does not allow 'main' to be used by a program [-Wmain]
    2 |     using T = decltype(main);
      | 

It is possible that the change between revisions is accidental, not deliberate. In any case, disallowing decltype(main) is an arbitrary restriction and solves no implementation challenges. Disallowing only odr-use of main seems adequate, and matches the original C++98 restrictions exactly.

Suggested Resolution

Change [basic.start.main] p3 as follows:

 The function main shall not be
-used
+odr-used
 within the program.

See Also

Activity

  1. eisenwave commented on Sep 12, 2023

    @eisenwave
    MemberAuthor

    On a side note, this may have a normative effect on [basic.start.dynamic] p5 because whether "use" of main constitutes odr-use impacts until when dynamic initialization can be deferred exactly.

    See also Stack Overflow/Why are exceptions thrown during deferred dynamic initialization not caught by main?

  2. frederick-vs-ja commented on Sep 13, 2023

    @frederick-vs-ja

    Or perhaps someone (like Clang folks?) may want to strengthen the prohibition:

    The function main shall not be used within the program. An expression shall not name ([basic.def.odr]) the function main in the global scope.

  3. xmh0511 commented on Sep 20, 2023

    @xmh0511

    Or perhaps someone (like Clang folks?) may want to strengthen the prohibition:

    The function main shall not be used within the program. An expression shall not name ([basic.def.odr]) the function main in the global scope.

    I think "in the global socpe" can arise ambiguities. What does it mean?

    1. Does it mean the expression that appears in other namespaces other than global scope will be ok?
      2.Or, It means the function main that inhabits the global scope

    Your intent presumably is the second one.

    An expression shall not name the function main whose declaration's target scope is the global scope.

    int main(){}
    namespace A{
       int main();
       void fun(){
          extern int main();  
          main;  // ok
       }
       void g(){
         using ::main;
         main; // error
       }
    }
  4. t3nsor commented on Sep 20, 2023

    @t3nsor

    Honestly we could just say "the function ::main shall not be odr-used". No need to overcomplicate things.

    Or "an id-expression that names the function ::main is ill-formed."

  5. eisenwave commented on Sep 21, 2023

    @eisenwave
    MemberAuthor

    @t3nsor the term usually used in the standard is "main function". There are 12 occurrences of it throughout various sections. Instead of "the function ::main", everywhere should just state "the ::main function".

    This could be done through an editorial change where all those are updated to "::main function". This is purely editorial because the intent is entirely clear.

  6. eisenwave commented on Sep 21, 2023

    @eisenwave
    MemberAuthor

    @xmh0511 I see no value in keeping the arbitrary restriction that you can't even name ::main at all (assuming that this restriction is the current intended behavior, which isn't clear). The people over at llvm-project haven't made a case for keeping their current strict implementation either.

    There could actually be value in detecting the type of main within a macro.

  7. jensmaurer commented on Oct 18, 2023

    @jensmaurer
    Member
  8. changed the title [-][basic.start.main] Clarify what it means to "use" `main`[/-] [+]CWG2811 [basic.start.main] Clarify what it means to "use" `main`[/+] on Oct 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions