In article <Cpr0sq.9Jx@borland.com> pete@genghis.interbase.borland.com (Pete Becker) writes:
>In article <CpJHAt.A09@ucc.su.oz.au>,
>John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>>
>>Under the token equivalence formulation of the ODR, the rules
>>for which are elaborated in my paper WG21/N0369 == X3J16/94-0009,
>>if these two files are linked together in a program the program
>>is undefined.
>
> There's an important word missing here, and it makes this statement
>extremely misleading. The missing word is "proposed", and it should be inserted
>before the words "token equivalence formulation".

 The fact that this formulation is a proposal was made
very clear in the context. I should have included the word
"proposed" here as Pete indicated, just as newspapers say
"alleged" when refering to a crime which has not been proven
in a court of law. Sorry.

>This formulation of the
>one definition rule is supposedly in a proposal, not the working paper. But
>the pre San Diego mailing has no 94-0009,

 Correct.

>nor does the post San Diego mailing,
>so as far as I can tell, nobody on the committee other than the author of this
>paper has seen it.

FYI: 94-0009/N0396 is the first technical paper in the post-San Diego mailing.
Due to an administrative error, the document is not listed in the
document list 94-0000R1/SD-1. But its in the mailing all the same.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

The current WP does not mention non-member inlines in the ODR section; my
conclusion from that omission was that the "one definition per program"
rule does not apply to them.  This seems appropriate to me, since it's
perfectly valid to define static functions with the same name in multiple
translation units...

Jason

In article <9412900.17991@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>John Skaller seemed to be suggesting that introducing a module
>system wouldn't slow down standardization much, because it would
>solve various problems with the current way of doing things.

 I think I should have said "needn't" rather than "wouldn't"
at this stage. I dont know. I think investigation is called for:
an analysis is worth the effort. Whether a module system
is proposed or not depends on the results of the analysis.

>My point was that the committee would still have to worry about
>those issues (such as the one definition rule), because of the
>need for backwards compatibility, and so introducing a module
>system *would* slow down standardization.

 Without a module system, we need ODR1. With modules,
we need MODULES and ODR2.

 Without an ODR, no Standard. But ODR1 is likely
to cause howls of protest:

 // file 1
 class X {
  void f(const int*);
 } x;

 // file 2
 class X {
  void f(int const*);
 } y;

Under the token equivalence formulation of the ODR, the rules
for which are elaborated in my paper WG21/N0369 == X3J16/94-0009,
if these two files are linked together in a program the program
is undefined. No diagnostic is required for breaches of the ODR,
however. On the other hand:

 static char buffer[20];
 inline char *getBlank() {
  memset(buffer, ' ', 20); return buffer; }

 char * void f() { return getBlank(); }

is a diagnosable error.

Its easy to put up with inline functions not working properly,
if you simply dont need to use them. That means the committee
doesnt have to worry about making them work properly.

Thats a good thing. Because its either impossible or extremely
difficult ( or both :-).

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

I want to turn the question around. Consider the code:

 // file 1
 class X {
  int f() { return 1; }
 } x;

 // file 2
 class X {
  int f() { return 2; }
 } y;
 extern X x;

 int main() { return x.f()+y.f(); }

If you are happy with main returning 3, your wishes are easy
to accommodate.

This is the status quo because there is no normative One Definition
Rule, so no conformance test can invalidate the compiler
that gives 3 as the correct answer.  We attain this rule,
and solve the problem, by changing the One Definition Rule to
say "the translation unit local copy of an inline function is always called".

If you are NOT happy with backward compatibility with the
status quo -- and no sensible person would be -- then we have
to DO SOMETHING to fix it.

The easiest way to fix it is to adopt exactly the words above
I just said no sensible person would accept, and provide
a module system so no sensible person will continue to
use pre-processing.

The alternative is LOTS of hard work coming up with a rule
that doesnt work anyhow. As it happens, I have done part of that work,
the results of my studies are published in WG21/N0369, X3J16/94-0009.
Many others contributed, especially Josee Lajoie (who supervised and
reviewed) and Andrew Koenig (who convinced me 'token equivalence' was
the best way to go).

The work is not finished -- Josee's core subgroup will have to discuss
it in conjunction with papers on linkage issues. The committee will
have to discuss it. If the paper is no accepted as written, or
sections thereof, possibly with modifications, then either
Dan Saks will develop 1000 wpm fingers, or a revised paper will
have to wait for the Tokyo meeting for voting.  At some stage
or other, Andrew must incorporate it into the WD.

(Yup -- its a Working Draft now, since the first version
has already be distributed by ISO to SC22 members :-)

Failure to support inlining in the document may lead to failure to
establish consensus in WG21, SC22, ISO/IEC, X3J16, or ANSI. This may
stop progression of the document at some point or other,
possibly the application for CD registration, scheduled
for the Waterloo (Canada) meeting in July.

Agreement on what is acceptable may be enhanced if modules
render the ODR obsolete.

So its _possible_ that a module system may reduce delays in
Standardisation.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>No diagnostic is required for breaches of the ODR [...]
>On the other hand:
>
> static char buffer[20];
> inline char *getBlank() {
>  memset(buffer, ' ', 20); return buffer; }
>
> char * void f() { return getBlank(); }
>
>is a diagnosable error.

Why?  Because an inline function uses a static variable?
Would declaring the function as "static inline" help?

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <9413319.22059@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>>No diagnostic is required for breaches of the ODR [...]
>>On the other hand:
>>
>> static char buffer[20];
>> inline char *getBlank() {
>>  memset(buffer, ' ', 20); return buffer; }
>>
>> char * void f() { return getBlank(); }
>>
>>is a diagnosable error.

 WOOPS! This is correct, but the example
does not correctly explain why. See below.

>Why?  Because an inline function uses a static variable?

 Yes, I have proposed that.  (more or less)

>Would declaring the function as "static inline" help?

 No, inline implies static unless extern is specified.

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

My argument is this: the only purpose of saying 'inline'
is to duplicate the definition in more than one translation
unit. If it uses a static variable, then there have to
be two DISTINCT static variables, one in each translation unit.

That means there is a risk that the function can detect which
translation unit it is in, which would allow the same function
to vary its behaviour between translation units, which is a breach
coherence.

Now -- the example I gave above does not illustrate this correctly.
Sorry. Here's another attempt ---

 static int x;
 class X {
  static int f() {return x;} // diagnosable error
 };

This is an error because the class X has external linkage,
and the function f() is inlined but is required to have
an equivalent definition in each translation unit.
If the code above appears in more than one translation unit,
its probably an error.

Thus, inlines may not refer to nonlocal static variables,
except for constant-expressions. If you do not duplicate
a definition in more than one translation unit there
is no point declaring it inline. Inlining is neither
enabled by 'inline', nor is lack of 'inline'
a prohibition on inlining.

Thus, because banning the use of non-local statics in inlines
causes no loss of functionality, but will often be an error,
a diagnostic error is useful. The ODR itself is not diagnosable.

PLEASE NOTE THAT ALL OF THIS IS SIMPLY AS I HAVE PROPOSED IT.
THE COMMITTE MAY OR MAY NOT ACCEPT WHAT I HAVE PROPOSED.
I EXPECT IT WILL AT LEAST BE ADDED TO OR MODIFIED, AND MAYBE
THROWN OUT ALTOGETHER.

(I just want people to be aware these are NOT existing rules,
but a proposal.)

(I think f() has external linkage, but many on the committee
argue this is not the case -- both positions are tenable,
and the difference is whether the address of the function is
the same everywhere  or distinct in each translation unit.
It has to be one way or the other)

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CpJHAt.A09@ucc.su.oz.au>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>
> Without an ODR, no Standard. But ODR1 is likely
>to cause howls of protest:
>
> // file 1
> class X {
>  void f(const int*);
> } x;
>
> // file 2
> class X {
>  void f(int const*);
> } y;
>
>Under the token equivalence formulation of the ODR, the rules
>for which are elaborated in my paper WG21/N0369 == X3J16/94-0009,
>if these two files are linked together in a program the program
>is undefined.

 There's an important word missing here, and it makes this statement
extremely misleading. The missing word is "proposed", and it should be inserted
before the words "token equivalence formulation". This formulation of the
one definition rule is supposedly in a proposal, not the working paper. But
the pre San Diego mailing has no 94-0009, nor does the post San Diego mailing,
so as far as I can tell, nobody on the committee other than the author of this
paper has seen it.
 -- Pete