In article <28ineo$kjq@paperboy.osf.org>, karl@dme3.osf.org (Karl Heuer) writes:
|> In article <CE8qLE.wM@crdnns.crd.ge.com> volpe@ausable.crd.ge.com writes:
|> >That's how I feel, but as Larry recently pointed out, this is undefined
|> >according to a recent misinterpretation ruling. Another opportunity
|> >to make the language have some semblence of common sense is shot to hell.
|>
|> On the other hand, if "void f(int a[])" is really illegal, maybe people
|> will stop using it as a synonym for "void f(int *a)", and the Brader-Heuer
|> proposal will have a chance after all.

No, no, no. The above example is legal because the element type is a
complete type, namely int. The only thing that was rendered illegal is
a declaration like "void f(struct incomplete a[])".

|>
|> (Mark and I independently proposed that the Standard should disallow the
|> use of brackets in a prototype to mean "pointer", so that it would be
|> possible for an implementation to provide an extension in which it means
|> "array".  This wart is the only thing standing in the way of array copy,
|> and the invention of prototype syntax was the perfect time to fix it.)

Not a bad idea. The only problem is that it would enable you to do
something with parameter passing that you couldn't do with simple
assignment.

--

Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com

> > (Mark and I independently proposed that the Standard should disallow the
> > use of brackets in a prototype to mean "pointer", so that it would be
> > possible for an implementation to provide an extension in which it means
> > "array".  This wart is the only thing standing in the way of array copy,
> > and the invention of prototype syntax was the perfect time to fix it.)
>
> Not a bad idea. The only problem is that it would enable you to do
> something with parameter passing that you couldn't do with simple
> assignment.

No.  The extension we were both thinking of was like this:

 - An lvalue which denotes an array is modifiable; and
 - The automatic conversion of array-type values to pointer
   types occurs only in the contexts where it already occurs,
   and not when an array value is required for assignment or
   parameter passing.

This extension cannot usefully be added to ANSI C because it enables you
to do something with *simple assignment* that you can't do with *parameter
passing*, and the reason for *that* is that you can't declare an array
parameter and be allowed to mean what you said.  If declaration of array
parameters in prototypes had been prohibited (in an unextended ANSI C
implementation), this would not have been a problem.

If this explanation doesn't end the thread, please change the Subject line.
Followups are again directed to comp.std.c; this is not about C++.
--
Mark Brader  "Strong typing isn't for weak minds; the argument
Toronto   'strong typing is for weak minds' is for weak minds."
utzoo!sq!msb, msb@sq.com     -- Guy Harris

This article is in the public domain.

In article <749496180snz@swidev.demon.co.uk> simonh@swidev.demon.co.uk writes:
>In article <rfgCE3wyD.MML@netcom.com> rfg@netcom.com writes:
>
>>In article <1993Sep20.212907.831@vitsemi.COM> tsai@vitsemi.COM (Jodi Tsai)
>> writes:
>>>
>>>I'm trying to compile libg++ using the DEC C++ compiler on their Alpha AXP
>>>machine...it chokes on the following two lines...
>>>
>>>  friend int        split(const String& x, String res[], int maxn,
>>>                          const String& sep);
>>>  friend int        split(const String& x, String res[], int maxn,
>>>                          const Regex&  sep);
>>>
>>>../g++-include/String.h:315: error: In the declaration of "res", the element
>> ty\
>>>pe of an array type is incomplete.
>>>../g++-include/String.h:317: error: In the declaration of "res", the element
>> ty\
>>>pe of an array type is incomplete.
>>>
>
>The function declarations are correct. The initial [] in a function argument
>declarator is equivalent to a pointer declarator. The compiler should accept
>String res[] and treat it as String* res.

I seems that you may have missed the follow-up from out friends over in
comp.std.c.

As far as X3J11 is concerned, `T formal[]' produces undefined behavior (if
`T' is an incomplete type).


--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <1993Sep20.212907.831@vitsemi.COM> tsai@vitsemi.COM (Jodi Tsai) writes:
>
>I'm trying to compile libg++ using the DEC C++ compiler on their Alpha AXP
>machine...it chokes on the following two lines...
>
>  friend int        split(const String& x, String res[], int maxn,
>                          const String& sep);
>  friend int        split(const String& x, String res[], int maxn,
>                          const Regex&  sep);
>
>../g++-include/String.h:315: error: In the declaration of "res", the element ty\
>pe of an array type is incomplete.
>../g++-include/String.h:317: error: In the declaration of "res", the element ty\
>pe of an array type is incomplete.
>
>Is this a bug in their C++ compiler?
>Or was this a change in the C++ 3.0 standard?
>--
>| Jodi Tsai   | Vitesse Semiconductor Corporation | e-mail: tsai@vitsemi.com |
>|             | 741 Calle Plano                   | Voice: (805) 389-7121    |
>|             | Camarillo, CA 93012               | FAX:   (805) 389-7126    |

This is an interesting question which relates back to the ANSI C standard,
and which involves a question which I (for one) have never seen a completely
adequate answer to.

The ANSI C standard says that arrays are formed of elements, each of which
is an object.  But "object types" and "incomplete types" are entirely
disjoint sets as far as the ANSI C standard is concerned.

So given:

 struct incomplete;
 static struct incomplete array[10];

it would appear that this violates a semantic rule of the ANSI C standard
and thus, although it is in a sense "erroneous", no diagnostic is required,
but the implementation does appear to be permitted (and indeed encouraged)
to produce one.

The situation may be slightly different however in the case of:

 struct incomplete;
 void foobar (struct incomplete array[10]) { /* ... */ }

Here, we know that there is a special kind if "array type decay" which
applies to the formal parameter `array', and that this type decay should
end up giving us a type for the formal (after decay) which is simply a
valid pointer-to-incomplete type, but does the check (if any) for arrays
of incomplete type happen before or after the type decay?  I don't know.
(If anyone else knows the answer, I would love to hear all about it.)

If the check for array-of-incomplete must (or may) occur first, then I
think that implementation are allowed (but apparently not strictly required)
to produce a diagnostic for the above code.  If on the other hand the
type decay for the formal parameter's type must occur before the check
for array-of-incomplete, then NO implementation would EVER be permitted
to issue a diagnostic for the above code.... unless of course it wanted
to :-) ... cuz the ANSI C standard seems to permit diagnostics to be
issued at any time for anything (a permission which I, for one, have never
been entirely comfortable with).

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCE3wyD.MML@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:
> So given:
> struct incomplete;
> static struct incomplete array[10];
> it would appear that this violates a semantic rule of the ANSI C standard
> and thus, although it is in a sense "erroneous", no diagnostic is required,
> but the implementation does appear to be permitted (and indeed encouraged)
> to produce one.

Correct. 6.7.2 semantics make this undefined, but don't require a
diagnostic. If the "static" had been omitted, then the code would have
been perfectly legal. In that case, the type "struct incomplete" must be
completed before:
  - the definition of array, if any (to be a definition, it will have to
    have an initializer) (see 6.5.7 constraints)
  - the end of the translation unit, as the second line is a tentative
    definition (see 6.7.2 semantics)
  - before the size of array is needed (for example, in "sizeof array").

If the static had been replaced by extern, then the second point would
not apply.

> The situation may be slightly different however in the case of:
> struct incomplete;
> void foobar (struct incomplete array[10]) { /* ... */ }

This was resolved by a Defect Report, which stated that, because the
ordering of completion testing and array-to-pointer-decay is undefined,
the entire definition of foobar is undefined behaviour. No diagnostic is
required.

--
Clive D.W. Feather     | Santa Cruz Operation    | If you lie to the compiler,
clive@sco.com          | Croxley Centre          | it will get its revenge.
Phone: +44 923 816 344 | Hatters Lane, Watford   |   - Henry Spencer
Fax:   +44 923 817 688 | WD1 8YN, United Kingdom | <== * NOTE NEW INFORMATION *

In article <rfgCE3wyD.MML@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> In article <1993Sep20.212907.831@vitsemi.COM> tsai@vitsemi.COM (Jodi Tsai) writes:
|> >
|> >
|> >  friend int        split(const String& x, String res[], int maxn,
|> >                          const String& sep);
|> >  friend int        split(const String& x, String res[], int maxn,
|> >                          const Regex&  sep);
|> >
|> >../g++-include/String.h:315: error: In the declaration of "res", the element ty\
|> >pe of an array type is incomplete.
|> >../g++-include/String.h:317: error: In the declaration of "res", the element ty\
|> >pe of an array type is incomplete.
|>
|> This is an interesting question which relates back to the ANSI C standard,
[...]
|>
|> So given:
|>
[...]
|>
|>  struct incomplete;
|>  void foobar (struct incomplete array[10]) { /* ... */ }
|>
|> Here, we know that there is a special kind if "array type decay" which
|> applies to the formal parameter `array', and that this type decay should
|> end up giving us a type for the formal (after decay) which is simply a
|> valid pointer-to-incomplete type, but does the check (if any) for arrays
|> of incomplete type happen before or after the type decay?  I don't know.
|> (If anyone else knows the answer, I would love to hear all about it.)

My $0.02:
  I'm uncomfortable with applying the terminology "array type decay" to
the formal parameter declaration above, since it's a completely different
process from what goes on when an actual array object identifier is used in
an expression. I believe that the "array-to-pointer conversion" that takes
place here isn't really a conversion, rather, the array declaration is
synonymous with the pointer declaration. At no time does there ever
exist (i.e. storage is never allocated for) an array of 10 structs. The only
thing that ever exists is a pointer. It is as if the code is translated
textually to "struct incomplete *array". The equivalence is akin to that of
"p[i]" and "*(p+i)". And I would like to see an interpretation ruling, er,
Defect Report, confirm this.

|> If the check for array-of-incomplete must (or may) occur first, then I
|> think that implementation are allowed (but apparently not strictly required)
|> to produce a diagnostic for the above code.  If on the other hand the
|> type decay for the formal parameter's type must occur before the check
|> for array-of-incomplete, then NO implementation would EVER be permitted
|> to issue a diagnostic for the above code.... unless of course it wanted
|> to :-) ... cuz the ANSI C standard seems to permit diagnostics to be
|> issued at any time for anything (a permission which I, for one, have never
|> been entirely comfortable with).

I hear you. I would prefer to require that implementations indicate whether
or not ANY of the diagnostics generated are required. Or perhaps a message
at the end like "0 syntax or constraint violations".

|>
|> --
|>
|> -- Ronald F. Guilmette ------------------------------------------------------
|> ------ domain address: rfg@netcom.com ---------------------------------------
|> ------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

--

Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com

In article <rfgCE3wyD.MML@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
> Here, we know that there is a special kind if "array type decay" which
> applies to the formal parameter `array', and that this type decay should
> end up giving us a type for the formal (after decay) which is simply a
> valid pointer-to-incomplete type, but does the check (if any) for arrays
> of incomplete type happen before or after the type decay?  I don't know.

This was the subject of an interpretation request.  The committee's
response was that the standard does not specify whether the check
happens before or after the type conversion.  Thus, an implementation is
free to use either order and a strictly conforming program must use an
explicit pointer type rather than an array type in this situation.
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070
larry.jones@sdrc.com
I suppose if I had two X chromosomes, I'd feel hostile too. -- Calvin

In article <rfgCE3wyD.MML@netcom.com> rfg@netcom.com writes:

>In article <1993Sep20.212907.831@vitsemi.COM> tsai@vitsemi.COM (Jodi Tsai)
> writes:
>>
>>I'm trying to compile libg++ using the DEC C++ compiler on their Alpha AXP
>>machine...it chokes on the following two lines...
>>
>>  friend int        split(const String& x, String res[], int maxn,
>>                          const String& sep);
>>  friend int        split(const String& x, String res[], int maxn,
>>                          const Regex&  sep);
>>
>>../g++-include/String.h:315: error: In the declaration of "res", the element
> ty\
>>pe of an array type is incomplete.
>>../g++-include/String.h:317: error: In the declaration of "res", the element
> ty\
>>pe of an array type is incomplete.
>>

The function declarations are correct. The initial [] in a function argument
declarator is equivalent to a pointer declarator. The compiler should accept
String res[] and treat it as String* res.


--
Simon Huntington
Software Interrupt Developments. Leeds, UK.

In article <749496180snz@swidev.demon.co.uk>, simonh@swidev.demon.co.uk (Simon Huntington) writes:
|> In article <rfgCE3wyD.MML@netcom.com> rfg@netcom.com writes:
|>
|> >In article <1993Sep20.212907.831@vitsemi.COM> tsai@vitsemi.COM (Jodi Tsai)
|> > writes:
|> >>
|> >>I'm trying to compile libg++ using the DEC C++ compiler on their Alpha AXP
|> >>machine...it chokes on the following two lines...
|> >>
|> >>  friend int        split(const String& x, String res[], int maxn,
|> >>                          const String& sep);
|> >>  friend int        split(const String& x, String res[], int maxn,
|> >>                          const Regex&  sep);
|> >>
|> >>../g++-include/String.h:315: error: In the declaration of "res", the element
|> > ty\
|> >>pe of an array type is incomplete.
|> >>../g++-include/String.h:317: error: In the declaration of "res", the element
|> > ty\
|> >>pe of an array type is incomplete.
|> >>
|>
|> The function declarations are correct. The initial [] in a function argument
|> declarator is equivalent to a pointer declarator. The compiler should accept
|> String res[] and treat it as String* res.
|>

That's how I feel, but as Larry recently pointed out, this is undefined
according to a recent misinterpretation ruling. Another opportunity
to make the language have some semblence of common sense is shot to hell.

|>
|> --
|> Simon Huntington
|> Software Interrupt Developments. Leeds, UK.

--

Chris Volpe
G.E. Corporate R&D
volpecr@crd.ge.com

In article <CE8qLE.wM@crdnns.crd.ge.com> volpe@ausable.crd.ge.com writes:
>That's how I feel, but as Larry recently pointed out, this is undefined
>according to a recent misinterpretation ruling. Another opportunity
>to make the language have some semblence of common sense is shot to hell.

On the other hand, if "void f(int a[])" is really illegal, maybe people
will stop using it as a synonym for "void f(int *a)", and the Brader-Heuer
proposal will have a chance after all.

(Mark and I independently proposed that the Standard should disallow the
use of brackets in a prototype to mean "pointer", so that it would be
possible for an implementation to provide an extension in which it means
"array".  This wart is the only thing standing in the way of array copy,
and the invention of prototype syntax was the perfect time to fix it.)

Karl Heuer (karl@dme3.osf.org) writes:
> On the other hand, if "void f(int a[])" is really illegal, maybe people
> will stop using it as a synonym for "void f(int *a)", and the Brader-Heuer
> proposal will have a chance after all.

But Larry didn't say that *that* had been ruled illegal.  He said it
was illegal if there was an incomplete type in place of the int.

> (Mark and I independently proposed that the Standard should disallow the
> use of brackets in a prototype to mean "pointer", so that it would be
> possible for an implementation to provide an extension in which it means
> "array".  This wart is the only thing standing in the way of array copy,
> and the invention of prototype syntax was the perfect time to fix it.)

Yes, "was".  The time is past and the opportunity missed.

Note: this thread is cross-posted.  I'm talking about C.  I claim no
expertise in C++.  Followups are directed to comp.std.c.
--
Mark Brader    "It is never good to adapt the design
SoftQuad Inc., Toronto    to the software; it should be the
utzoo!sq!msb, msb@sq.com   other way around."    -- J.A. Durieux

This article is in the public domain.