In article <3r496q$n1c@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de
Boyne Pollard) writes:

    [Concerning a proposed improved wording concerning main...]
|> A pleasure.  Feel free to drop your national standards body a line and say
|> "You know this proposal to tidy up some quibbles in [basic.start.main] (ISO
|> WG21/NO687) ?  Well, I strongly suggest that you adopt it."

Just a reminder: a posting in comp.std.c++ does not constitute a
proposal for a change in the C++ standard.  Have you submitted this to
ANSI (or rather, in your case, to BSI).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

James Kanze US/ESC 60/3/141 #40763 (kanze@lts.sel.alcatel.de) wrote:
: In article <3r496q$n1c@silver.jba.co.uk> JdeBP@jba.co.uk (Jonathan de
: Boyne Pollard) writes:

:     [Concerning a proposed improved wording concerning main...]
: |> A pleasure.  Feel free to drop your national standards body a line and say
: |> "You know this proposal to tidy up some quibbles in [basic.start.main] (ISO
: |> WG21/NO687) ?  Well, I strongly suggest that you adopt it."

: Just a reminder: a posting in comp.std.c++ does not constitute a
: proposal for a change in the C++ standard.

No, but the above quote does constitute encouragement for those who
agree with what I outline here to submit the same proposal to their
national standards bodies (or, at the very least, to encourage them to be
in favour of my proposal).  Which was the intention.  The more people that
agree and tell their standards bodies that they agree, the greater the
chance of getting something done about [basic.start.main].

:                                             Have you submitted this to
: ANSI (or rather, in your case, to BSI).

I have only one contact at BSI, and he doesn't seem to be answering his
e-mail at the moment.  Otherwise, yes, I would submit it.

JdeBP@jba.co.uk (Jonathan de Boyne Pollard) proposes:
> 5  Calling the function
>           void exit(int) ;
>    declared in <cstdlib> (_lib.support.start.term_) terminates the program
>    without leaving the current block and hence without destroying any
>    objects with automatic storage duration (_class.dtor_). [...]
>
> 6  A return statement in function main has the effect of leaving the main
>    function (destroying any objects with automatic storage duration) and
>    then calling exit.

What about destroying objects that are static or global?

Sam Fenster (fenster@shadow.cs.columbia.edu) wrote:
: JdeBP@jba.co.uk (Jonathan de Boyne Pollard) proposes:
: > 5  Calling the function
: >           void exit(int) ;
: >    declared in <cstdlib> (_lib.support.start.term_) terminates the program
: >    without leaving the current block and hence without destroying any
: >    objects with automatic storage duration (_class.dtor_). [...]
: >
: > 6  A return statement in function main has the effect of leaving the main
: >    function (destroying any objects with automatic storage duration) and
: >    then calling exit.

: What about destroying objects that are static or global?

I'm only suggesting alterations to handle tidying up [basic.start.main],
which only addresses the issue of destruction of automatic duration objects
because it is part of the difference between a call to exit() and a return
statement in the distinguished function `main'.

The construction and destruction of objects with static duration is
explicitly set out in [basic.start.init] and [basic.start.term] which are
the immediately following two sections.  I'm not proposing ANY alterations
to those two.

Well, not yet anyway ... (-:

Tony Bass (aeb@lamb.saltfarm.bt.co.uk) wrote:
: From article <3r2bf9$mgq@silver.jba.co.uk>, by JdeBP@jba.co.uk (Jonathan de Boyne Pollard):
: [...]
: > here's a suggested rewording of [basic.start.main]
: [...]

: I am impressed by this definitive exposition of main.  I have just minor
: queries on (4),

I'd love to say thanks, but in reality all I did was take the existing
draft and work in some clarifications for the quibbles that I found.

If anyone feels like putting this forward as a concrete proposal to the
Committee through official channels, please feel free.  (-:

: > 4  Where main is defined as
: >            int main (int argc, char *argv[]) { /* ... */ }
: >    (i.e. the second of the definitions given above), the parameter argc
: >    shall be the number of arguments passed to the program from the
: >    environment in which the program is run, plus one.  The value of argc
: >    shall be nonnegative and nonzero.  argv[0] shall be a pointer to either
: >    "" or to the initial character of a null-terminated multibyte string
: >    (NTMBS) that represents the name used to invoke the program; where
: >    argc is greater than 1, argv[1] through argv[argc-1] shall be pointers
: >    to the initial characters of NTMBSs representing the arguments;

: Is NTMBS intended to imply at least one character?  The context slightly
: suggests this, but in a Unix environment it is possible and often useful
: to pass an empty string as argument, that is, "", a pointer to an ASCII
: NUL byte.

Actually, that's one of the bits from the draft that I left alone.  NTMBS
is defined in [lib.multibyte.strings] you will find.  I agree that the
library introduction chapter is a rather odd place to define it considering
that it is used in the basic concepts chapter.

For what it's worth, a NTMBS (by worth of it being a NTBS) always contains
at least one character : the NUL that terminates it.  Certainly there's not
meant to be any implication in my proposal above that the NTMBSs pointed to
by the elements of argv[] are non-empty.

If the confusion is due to the wording for argv[0], the implication here is
that argv[0] points to either

  ""

or

  the initial character of a NTMBS that represents the name used to
  invoke the program

In other words, if the semantics demanded by the second form are
unavailable, passing a pointer to the first character of an empty NTMBS
is allowed to the implementation.

To clear up the confusion, perhaps it is a good idea to reverse the order
of the either...or for argv[0] to help make it a little clearer :

--------------------------------------------------------------------------
4  Where main is defined as
           int main (int argc, char *argv[]) { /* ... */ }
   (i.e. the second of the definitions given above), the parameter argc
   shall be the number of arguments passed to the program from the
   environment in which the program is run, plus one.  The value of argc
   shall be nonnegative and nonzero.  argv[0] shall be a pointer either
   to the initial character of a null-terminated multibyte string (NTMBS)
   that represents the name used to invoke the program or to ""; where
   argc is greater than 1, argv[1] through argv[argc-1] shall be pointers
   to the initial characters of NTMBSs representing the arguments;
   finally, the value of argv[argc] shall be 0.
--------------------------------------------------------------------------

: Again in a Unix environment, argv[0] is at the invoker's disposal,
: conventionally often a program filename, but sometimes not (eg a shell
: invoked as "-sh" on login or as "sh" at other times).  I think the
: wording given may cover this, as "the name used to invoke the program"
: carefully avoids talking about filenames, but I wondered if the
: description of argv[0] could be unified to make no distinction between
: empty and non-empty strings, perhaps just mentioning matters of
: convention?  Unix could meaningfully invoke a program giving it argv[0]
: "", though I do not know of any example actually doing this.

I think that what I've already said in this message covers this.  The only
addition is that your last point does seem to be a valid problem with this
scheme, in that when argv[0] points to en empty NTMBS there is no way for
the programmer to determine whether the "name used to invoke the program"
actually *was* an empty NTMBS or whether the implementation simply doesn't
support this concept.

I'd say that that was an acceptable flaw in the scheme though, wouldn't you ?

: >    finally, the value of argv[argc] shall be 0.

: Having seen some discussion of null pointers in standard C I dare not
: question this!  Thanks for some good text.

A pleasure.  Feel free to drop your national standards body a line and say
"You know this proposal to tidy up some quibbles in [basic.start.main] (ISO
WG21/NO687) ?  Well, I strongly suggest that you adopt it."

And just for those who *really* want to shoot me down in flames (as if I
haven't displayed enough targets already), here's a suggested rewording of
[basic.start.main] incorporating fixes for the previous quibbles, just to
help you along.

--------------------------------------------------------------------------

  3.6  Start and termination                       [basic.start]

  3.6.1  Main function                                [basic.start.main]

1  A program shall contain a global function named main, which is the
   designated start of the program.

2  This function is not predefined by the implementation.  The set of
   definitions for main that are acceptable (and thus by implication the
   type of main) is implementation defined, and main cannot be
   overloaded.  All implementations must include the definitions
           int main () { /* ... */ }
   and
           int main (int, char *[]) { /* ... */ }
   in that set, but are free to extend the set with additional function
   types. [ Note: It is recommended that implementations allow additional
   function types where the first two parameters are the same types and
   have the same semantics (see below) as those of the second definition
   above. ] [ Example: Implementations may allow definitions of main that
   do not return a value (i.e. void). ]

3  The  function  main shall not be called from within a program.  The
   linkage (_basic.link_) of main is implementation defined.   The
   address of main shall not be taken.  The function main shall not be
   declared except at its definition, and shall not be declared inline or
   static.  The name main is not otherwise reserved.  [ Example: member
   functions, classes, and enumerations can be called main, as can
   entities in other namespaces.  ]

4  Where main is defined as
           int main (int argc, char *argv[]) { /* ... */ }
   (i.e. the second of the definitions given above), the parameter argc
   shall be the number of arguments passed to the program from the
   environment in which the program is run, plus one.  The value of argc
   shall be nonnegative and nonzero.  argv[0] shall be a pointer to either
   "" or to the initial character of a null-terminated multibyte string
   (NTMBS) that represents the name used to invoke the program; where
   argc is greater than 1, argv[1] through argv[argc-1] shall be pointers
   to the initial characters of NTMBSs representing the arguments;
   finally, the value of argv[argc] shall be 0.

5  Calling the function
          void exit(int) ;
   declared in <cstdlib> (_lib.support.start.term_) terminates the program
   without leaving the current block and hence without destroying any
   objects with automatic storage duration (_class.dtor_).  The argument
   value  is  returned to the program's environment as the value of the
   program.

6  A return statement in function main has the effect of leaving the main
   function (destroying any objects with automatic storage duration) and
   then calling exit.

   Where main is defined in either of the forms given above, the argument
   to exit shall be the value returned from main by that statement.

   Where main is defined in either of the forms given above and control
   reaches the end of main without encountering a return statement, the
   effect is that of executing
          return 0 ;

   Where main is defined with an implementation-defined form (not listed
   above), and control reaches the end of main without encountering a
   return statement, the effect is implementation defined. [ Note:
   Implementations are expected to define behaviour that is equivalent to
   that of the return 0 case outlined above, where reasonable.  ]

--------------------------------------------------------------------------