gcc-in-cxx update

gcc-in-cxx update

[Ian Lance Taylor]

I've finished my set of patches which fix -Wc++-compat to check for enum
conversions which are valid in C++.  Adding those checks forced a lot of
changes in mainline to compile cleanly with -Wc++-compat.  I have merged
those changes over to the gcc-in-cxx branch.  In the gcc directory
itself, excluding changes to configure and Makefile, the gcc-in-cxx
branch compared to mainline is now

 113 files changed, 1558 insertions(+), 1241 deletions(-)

Some of the remaining issues:

* C permits using the ++ and -- operators with a variable of enum type.
  C++ does not (unless you explicit declare the operators, which for
  purposes of -Wc++-compat I think we can assume to not occur).

* C permits defining a struct/enum/union within a struct/union and then
  referring to the inner struct/enum/union outside of the enclosing
  struct/union.  C++ does not permit this--in C++ it has to be public
  and you have to use a scope qualifier.

* C permits "struct s { }; typedef int s;".  That is, you may reuse a
  name as both a struct/enum/union tag and as a type.  C++ does not
  permit this.

* The C++ frontend warns about "while (true);" when there is no
  whitespace between the ')' and the ';'.  The C frontend does not.  I'm
  not sure how to best handle this.  It doesn't make much sense to warn
  about this with -Wc++-compat.  Should the C frontend warn about this?
  Should the C++ frontend not warn about this?  Any opinions?

* In C an externally visible "inline" function (i.e., not "extern", not
  "static") is assumed to be accessible outside of the current
  translation unit (e.g., vn_nary_op_compute_hash in
  gcc/tree-ssa-sccvn.c).  In C++ this is not the case.  It is also not
  the case in C99, so this should be addressed anyhow, somehow, although
  it doesn't seem to be a good fit for -Wc++-compat.

* In C a const variable which is neither "extern" nor "static" is
  visible outside of the current translation unit.  In C++ it is not,
  without an explicit "extern" declaration.  I'm not sure how best to
  handle this with -Wc++-compat, since C does not permit initializing an
  "extern const" variable.

* The C++ frontend does not support __attribute__ ((unused)) on labels.
  The generator programs produce a lot of unused labels.  Fixing this in
  the C++ frontend may be awkward because C++ syntax permits a
  declaration to follow a label, so it may not be clear which one gets
  the attribute.

* The C++ frontend emits some warnings on code which is known to be
  never executed, which the C frontend does not.  This leads to some
  warnings compiling code in gcc.  I think it is reasonable to fix this
  in the C++ frontend.

Ian

Re: gcc-in-cxx update

[Richard Guenther]

On Wed, Apr 29, 2009 at 9:39 AM, Ian Lance Taylor <iant@google.com> wrote:
> I've finished my set of patches which fix -Wc++-compat to check for enum
> conversions which are valid in C++.  Adding those checks forced a lot of
> changes in mainline to compile cleanly with -Wc++-compat.  I have merged
> those changes over to the gcc-in-cxx branch.  In the gcc directory
> itself, excluding changes to configure and Makefile, the gcc-in-cxx
> branch compared to mainline is now
>
>  113 files changed, 1558 insertions(+), 1241 deletions(-)
>
> Some of the remaining issues:
>
> * C permits using the ++ and -- operators with a variable of enum type.
>  C++ does not (unless you explicit declare the operators, which for
>  purposes of -Wc++-compat I think we can assume to not occur).
>
> * C permits defining a struct/enum/union within a struct/union and then
>  referring to the inner struct/enum/union outside of the enclosing
>  struct/union.  C++ does not permit this--in C++ it has to be public
>  and you have to use a scope qualifier.
>
> * C permits "struct s { }; typedef int s;".  That is, you may reuse a
>  name as both a struct/enum/union tag and as a type.  C++ does not
>  permit this.
>
> * The C++ frontend warns about "while (true);" when there is no
>  whitespace between the ')' and the ';'.  The C frontend does not.  I'm
>  not sure how to best handle this.  It doesn't make much sense to warn
>  about this with -Wc++-compat.  Should the C frontend warn about this?
>  Should the C++ frontend not warn about this?  Any opinions?

The C frontend should warn about this as well.

> * In C an externally visible "inline" function (i.e., not "extern", not
>  "static") is assumed to be accessible outside of the current
>  translation unit (e.g., vn_nary_op_compute_hash in
>  gcc/tree-ssa-sccvn.c).  In C++ this is not the case.  It is also not
>  the case in C99, so this should be addressed anyhow, somehow, although
>  it doesn't seem to be a good fit for -Wc++-compat.

Right.  Just fix it.

> * In C a const variable which is neither "extern" nor "static" is
>  visible outside of the current translation unit.  In C++ it is not,
>  without an explicit "extern" declaration.  I'm not sure how best to
>  handle this with -Wc++-compat, since C does not permit initializing an
>  "extern const" variable.

Does putting an extern const declaration in addition to the const
definition work in C and C++?  If so you could warn about a
missing declaration just like we do for missing prototypes.

> * The C++ frontend does not support __attribute__ ((unused)) on labels.
>  The generator programs produce a lot of unused labels.  Fixing this in
>  the C++ frontend may be awkward because C++ syntax permits a
>  declaration to follow a label, so it may not be clear which one gets
>  the attribute.
>
> * The C++ frontend emits some warnings on code which is known to be
>  never executed, which the C frontend does not.  This leads to some
>  warnings compiling code in gcc.  I think it is reasonable to fix this
>  in the C++ frontend.

Or just amend the C frontend to also warn in these cases?

Richard.

> Ian
>

Re: gcc-in-cxx update

[Joseph S. Myers]

On Wed, 29 Apr 2009, Ian Lance Taylor wrote:

> * The C++ frontend warns about "while (true);" when there is no
>   whitespace between the ')' and the ';'.  The C frontend does not.  I'm
>   not sure how to best handle this.  It doesn't make much sense to warn
>   about this with -Wc++-compat.  Should the C frontend warn about this?
>   Should the C++ frontend not warn about this?  Any opinions?

I consider this whitespace-sensitive warning very dubious.

> * In C a const variable which is neither "extern" nor "static" is
>   visible outside of the current translation unit.  In C++ it is not,
>   without an explicit "extern" declaration.  I'm not sure how best to
>   handle this with -Wc++-compat, since C does not permit initializing an
>   "extern const" variable.

C does permit it; there's a warning, not a pedwarn.  Add an option to 
disable this warning (at least where "const" is used)?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx update

[Manuel López-Ibáñez]

2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
>
>> * The C++ frontend warns about "while (true);" when there is no
>>   whitespace between the ')' and the ';'.  The C frontend does not.  I'm
>>   not sure how to best handle this.  It doesn't make much sense to warn
>>   about this with -Wc++-compat.  Should the C frontend warn about this?
>>   Should the C++ frontend not warn about this?  Any opinions?
>
> I consider this whitespace-sensitive warning very dubious.

So would you like it if it were not sensitive to whitespace?
(It could be silenced by while(true) (void)0;)

I think the point is more whether the warning itself is useful or not.

>
>> * In C a const variable which is neither "extern" nor "static" is
>>   visible outside of the current translation unit.  In C++ it is not,
>>   without an explicit "extern" declaration.  I'm not sure how best to
>>   handle this with -Wc++-compat, since C does not permit initializing an
>>   "extern const" variable.
>
> C does permit it; there's a warning, not a pedwarn.  Add an option to
> disable this warning (at least where "const" is used)?

In any case, -Wc++-compat should warn about the difference in
behaviour, shouldn't it?

I see the current code already handles this somehow:

          /* It is fine to have 'extern const' when compiling at C
              and C++ intersection.  */
           if (!(warn_cxx_compat && constp))
             warning (0, "%qs initialized and declared %<extern%>", name);

BTW, why is this warned about?

Cheers,

Manuel.

Re: gcc-in-cxx update

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1466 bytes --]

On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:

> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> > On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
> >
> >> * The C++ frontend warns about "while (true);" when there is no
> >>   whitespace between the ')' and the ';'.  The C frontend does not.  I'm
> >>   not sure how to best handle this.  It doesn't make much sense to warn
> >>   about this with -Wc++-compat.  Should the C frontend warn about this?
> >>   Should the C++ frontend not warn about this?  Any opinions?
> >
> > I consider this whitespace-sensitive warning very dubious.
> 
> So would you like it if it were not sensitive to whitespace?
> (It could be silenced by while(true) (void)0;)
> 
> I think the point is more whether the warning itself is useful or not.

I don't know the rationale for this warning.  Is it to do with the C++0x 
specification that certain loops may be assumed to terminate?

> I see the current code already handles this somehow:
> 
>           /* It is fine to have 'extern const' when compiling at C
>               and C++ intersection.  */
>            if (!(warn_cxx_compat && constp))
>              warning (0, "%qs initialized and declared %<extern%>", name);
> 
> BTW, why is this warned about?

I imagine because in C it is not conventional to use "extern" when 
defining something, only on a declaration that is not a definition.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx update

[Manuel López-Ibáñez]

2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
> I don't know the rationale for this warning.  Is it to do with the C++0x
> specification that certain loops may be assumed to terminate?

I guess the rationale is that there is little use for while(true) ;
so it is probably an unintended mistake. I think in this trivial case
we should warn always (in C and C++), whitespace or not (it may come
from a strange macro expansion).

>>
>> BTW, why is this warned about?
>
> I imagine because in C it is not conventional to use "extern" when
> defining something, only on a declaration that is not a definition.

But may it lead to some confusion or subtle error? It seems overly
pedantic to me if it is just a matter of style, because  extern is
implicit if missing,

If one wants to use the same code in C and C++, then it is definitely
a spurious warning in my opinion.

Cheers,

Manuel.

Re: gcc-in-cxx update

[Sebastian Redl]

Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>   
>> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
>>     
>>> On Wed, 29 Apr 2009, Ian Lance Taylor wrote:
>>>
>>>       
>>>> * The C++ frontend warns about "while (true);" when there is no
>>>>   whitespace between the ')' and the ';'.  The C frontend does not.  I'm
>>>>   not sure how to best handle this.  It doesn't make much sense to warn
>>>>   about this with -Wc++-compat.  Should the C frontend warn about this?
>>>>   Should the C++ frontend not warn about this?  Any opinions?
>>>>         
>>> I consider this whitespace-sensitive warning very dubious.
>>>       
>> So would you like it if it were not sensitive to whitespace?
>> (It could be silenced by while(true) (void)0;)
>>
>> I think the point is more whether the warning itself is useful or not.
>>     
>
> I don't know the rationale for this warning.  Is it to do with the C++0x 
> specification that certain loops may be assumed to terminate?
>   
I think the rationale is to capture this mistake:

for(...);
{
}

Microsoft's compiler has a similar warning, but stricter: it doesn't
care about whitespace, and the only way to get a warning-free empty loop
is to give it an empty compound statement as the body.
So MSC will warn about this construct, but GCC will not, due to its
whitespace rule:
for(...)
  ;

Sebastian

Re: gcc-in-cxx update

[Manuel López-Ibáñez]

2009/4/29 Sebastian Redl <sebastian.redl@getdesigned.at>:
> So MSC will warn about this construct, but GCC will not, due to its
> whitespace rule:

I think we should just remove the whitespace rule and implement the
warning in C.

Cheers,

Manuel.

Re: gcc-in-cxx update

[Ian Lance Taylor]

Richard Guenther <richard.guenther@gmail.com> writes:

>> * The C++ frontend emits some warnings on code which is known to be
>>  never executed, which the C frontend does not.  This leads to some
>>  warnings compiling code in gcc.  I think it is reasonable to fix this
>>  in the C++ frontend.
>
> Or just amend the C frontend to also warn in these cases?

We could do that, but we would have to adjust gcc's code base to avoid
the warnings.  For example, in insn-modes.c we emit code like this:

#define MODE_MASK(m)                          \
  ((m) >= HOST_BITS_PER_WIDE_INT)             \
   ? ~(unsigned HOST_WIDE_INT) 0              \
   : ((unsigned HOST_WIDE_INT) 1 << (m)) - 1

  MODE_MASK (0),           /* VOID */

With the current C++ frontend, this issues a warning about a shift
larger than the word size.  The C frontend sees that the condition is a
constant, so it does not issue any warnings about the unexecuted side of
the conditional.  This is done by manipulating skip_evaluation in
c_parser_conditional_expression and testing it in build_binary_op.

Ian

Re: gcc-in-cxx update

[Ian Lance Taylor]

Manuel López-Ibáñez <lopezibanez@gmail.com> writes:

> 2009/4/29 Sebastian Redl <sebastian.redl@getdesigned.at>:
>> So MSC will warn about this construct, but GCC will not, due to its
>> whitespace rule:
>
> I think we should just remove the whitespace rule and implement the
> warning in C.

Actually it appears that the whitespace rule was already removed from
the C++ frontend in PR 36478.  So this may be a non-issue for
gcc-in-cxx.

Ian

Re: gcc-in-cxx update

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 501 bytes --]

On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:

> >> BTW, why is this warned about?
> >
> > I imagine because in C it is not conventional to use "extern" when
> > defining something, only on a declaration that is not a definition.
> 
> But may it lead to some confusion or subtle error? It seems overly
> pedantic to me if it is just a matter of style, because  extern is
> implicit if missing,

"int i;" is not the same as "extern int i;".

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx update

[Manuel López-Ibáñez]

2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>> >> BTW, why is this warned about?
>> >
>> > I imagine because in C it is not conventional to use "extern" when
>> > defining something, only on a declaration that is not a definition.
>>
>> But may it lead to some confusion or subtle error? It seems overly
>> pedantic to me if it is just a matter of style, because  extern is
>> implicit if missing,
>
> "int i;" is not the same as "extern int i;".

Sorry for my ignorance but I have been reading and searching for the
answer and I cannot tell what is the difference between "int i = 1"
and "extern int i = 1" at file-scope in C.

Would you or someone else mind to point me out to the answer? Thanks in advance.

Manuel.

Re: gcc-in-cxx update

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 984 bytes --]

On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:

> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
> >
> >> >> BTW, why is this warned about?
> >> >
> >> > I imagine because in C it is not conventional to use "extern" when
> >> > defining something, only on a declaration that is not a definition.
> >>
> >> But may it lead to some confusion or subtle error? It seems overly
> >> pedantic to me if it is just a matter of style, because  extern is
> >> implicit if missing,
> >
> > "int i;" is not the same as "extern int i;".
> 
> Sorry for my ignorance but I have been reading and searching for the
> answer and I cannot tell what is the difference between "int i = 1"
> and "extern int i = 1" at file-scope in C.

I did not say those were different, I said the uninitialized case was 
different, so "extern is implicit if missing" is not a general C rule.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-in-cxx update

[Manuel López-Ibáñez]

2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>
>> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
>> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>> >
>> >> >> BTW, why is this warned about?
>> >> >
>> >> > I imagine because in C it is not conventional to use "extern" when
>> >> > defining something, only on a declaration that is not a definition.
>> >>
>> >> But may it lead to some confusion or subtle error? It seems overly
>> >> pedantic to me if it is just a matter of style, because  extern is
>> >> implicit if missing,
>> >
>> > "int i;" is not the same as "extern int i;".
>>
>> Sorry for my ignorance but I have been reading and searching for the
>> answer and I cannot tell what is the difference between "int i = 1"
>> and "extern int i = 1" at file-scope in C.
>
> I did not say those were different, I said the uninitialized case was
> different, so "extern is implicit if missing" is not a general C rule.

OK, then. I assumed that we were discussing about the initialized
case, which is the origin of this thread. Hence, my suggestion stands:
get rid of the warning.

Cheers,

Manuel.

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[Eus]

Hi Ho!

Sorry, if I sort of hijack this thread.

On Wed, 2009-04-29 at 15:43 +0000, Joseph S. Myers wrote:

> > > "int i;" is not the same as "extern int i;".
> > 
> > Sorry for my ignorance but I have been reading and searching for the
> > answer and I cannot tell what is the difference between "int i = 1"
> > and "extern int i = 1" at file-scope in C.
> 
> I did not say those were different, I said the uninitialized case was 
> different, so "extern is implicit if missing" is not a general C rule.

I think the difference between "int i;" and "extern int i;" at
file-scope in C is that "int i;" will only be treated as a definition if
it is not defined in another place in the same file/TU. IOW, its linkage
is internal within the TU itself. But, "extern int i" is definitely
treated as a declaration only that can later be defined either in the
same TU or in another one.

Is that true?


Finally, is there any difference in declaring a non-inline function
prototype with and without "extern" in C? That is, is there any
difference between:

extern int foo (int *bar);

and

int foo (int *bar);

?

I think they are completely identical. Is that correct?

Also, is there any difference in defining a non-inline function with and
without "extern" in C? That is, is there any difference between:

extern int foo (int *bar)
{
    return *bar + 5;
}

and

int foo (int *bar)
{
    return *bar + 5;
}

?

I think they are also identical. Am I right? Who knows the one with
"extern" can be overridden in another TU defining its own definition
without "extern".

Thank you for your help :-)

> -- 
> Joseph S. Myers
> joseph@codesourcery.com

-- 
Best regards,
Eus (FSF member #4445)

In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.

Join free software movement today! It is free as in freedom, not as in
free beer!

Join: http://www.fsf.org/jf?referrer=4445

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[Ian Lance Taylor]

Eus <reply.to.eus.at.member.fsf.org@gmail.com> writes:

> I think the difference between "int i;" and "extern int i;" at
> file-scope in C is that "int i;" will only be treated as a definition if
> it is not defined in another place in the same file/TU. IOW, its linkage
> is internal within the TU itself. But, "extern int i" is definitely
> treated as a declaration only that can later be defined either in the
> same TU or in another one.
>
> Is that true?

What you are describing is a common and traditional implementation of C,
but it is not strictly standard conformant.  The ISO C standard says
that "int i;" is always a definition, and "extern int i;" is always a
declaration.  What you decribe is listed as a common extension (at least
in C90--I didn't bother to check C99).


> Finally, is there any difference in declaring a non-inline function
> prototype with and without "extern" in C? That is, is there any
> difference between:
>
> extern int foo (int *bar);
>
> and
>
> int foo (int *bar);
>
> ?
>
> I think they are completely identical. Is that correct?

Yes.  In a function (not variable) declaration, the "extern" is
optional.  This is true in both C and C++.


> Also, is there any difference in defining a non-inline function with and
> without "extern" in C? That is, is there any difference between:
>
> extern int foo (int *bar)
> {
>     return *bar + 5;
> }
>
> and
>
> int foo (int *bar)
> {
>     return *bar + 5;
> }
>
> ?
>
> I think they are also identical. Am I right? Who knows the one with
> "extern" can be overridden in another TU defining its own definition
> without "extern".

These are not identical, but the meaning in C is complex because it
changes depending on which standard you are using.  Look at the docs for
the -fgnu89-inline option and the gnu_inline function attribute.

Ian

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[James Dennett]

On Thu, Apr 30, 2009 at 11:57 AM, Ian Lance Taylor <iant@google.com> wrote:
> Eus <reply.to.eus.at.member.fsf.org@gmail.com> writes:
>
>> I think the difference between "int i;" and "extern int i;" at
>> file-scope in C is that "int i;" will only be treated as a definition if
>> it is not defined in another place in the same file/TU. IOW, its linkage
>> is internal within the TU itself. But, "extern int i" is definitely
>> treated as a declaration only that can later be defined either in the
>> same TU or in another one.
>>
>> Is that true?
>
> What you are describing is a common and traditional implementation of C,
> but it is not strictly standard conformant.  The ISO C standard says
> that "int i;" is always a definition, and "extern int i;" is always a
> declaration.  What you decribe is listed as a common extension (at least
> in C90--I didn't bother to check C99).

[I imagine Ian is aware of this anywyay, but to try to clarify...]

At file scope, "int i;" with no initializer is a "tentative
definition" in C, see 6.9.2/2; a tentative definition is an odd beast
that works in some ways rather unlike other definitions (e.g., it's
perfectly valid to have multiple tentative definitions for the same
variable in the same file).  Informally (only) it seems fair to say
that a tentative definition is "treated as a declaration only".  If
you want precision though, such fudging isn't helpful.

C++ does not have the concept of a tentative declaration:
  int i;
  int i;  // legal in C99, invalid as a duplicate definition in C++03

To me that's amusing when compared to:
  typedef int j;
  typedef int j; // legal in C++03, invalid as a duplication definition in C99

-- James

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[Eus]

Hi Ho!

On Thu, 2009-04-30 at 11:57 -0700, Ian Lance Taylor wrote:

> What you are describing is a common and traditional implementation of C,
> but it is not strictly standard conformant.  The ISO C standard says
> that "int i;" is always a definition, and "extern int i;" is always a
> declaration.  What you decribe is listed as a common extension (at least
> in C90--I didn't bother to check C99).

Thank you for clarifying further in light of the standard.

> Yes.  In a function (not variable) declaration, the "extern" is
> optional.  This is true in both C and C++.

Thanks for the answer. I had been pondering upon this point for about a
year or so since I hacked the Linux kernel for the very last time. It is
because in some header files, some prototypes use "extern" and some
don't. So, I was curious as to whether they have a different semantic.

> > Also, is there any difference in defining a non-inline function with
> and
> > without "extern" in C? That is, is there any difference between:
> >
> > extern int foo (int *bar)
> > {
> >     return *bar + 5;
> > }
> >
> > and
> >
> > int foo (int *bar)
> > {
> >     return *bar + 5;
> > }
> >
> > ?
> >
> > I think they are also identical. Am I right? Who knows the one with
> > "extern" can be overridden in another TU defining its own definition
> > without "extern".
> 
> These are not identical, but the meaning in C is complex because it
> changes depending on which standard you are using.  Look at the docs
> for
> the -fgnu89-inline option and the gnu_inline function attribute.

Ah, I get it.

Yes, I am aware of the different semantic when inline is involved like
what you have specified here:
http://gcc.gnu.org/ml/gcc/2006-11/msg00006.html

> Ian

Thanks for your answers :-)

-- 
Best regards,
Eus (FSF member #4445)

In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.

Join free software movement today! It is free as in freedom, not as in
free beer!

Join: http://www.fsf.org/jf?referrer=4445

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[Eus]

Hi Ho!

On Thu, 2009-04-30 at 12:40 -0700, James Dennett wrote:

> [I imagine Ian is aware of this anywyay, but to try to clarify...]
> 
> At file scope, "int i;" with no initializer is a "tentative
> definition" in C, see 6.9.2/2; a tentative definition is an odd beast
> that works in some ways rather unlike other definitions (e.g., it's
> perfectly valid to have multiple tentative definitions for the same
> variable in the same file).  Informally (only) it seems fair to say
> that a tentative definition is "treated as a declaration only".  If
> you want precision though, such fudging isn't helpful.

Yup, I am aware of this.

> C++ does not have the concept of a tentative declaration:
>   int i;
>   int i;  // legal in C99, invalid as a duplicate definition in C++03
> 
> To me that's amusing when compared to:
>   typedef int j;
>   typedef int j; // legal in C++03, invalid as a duplication definition in C99

Heh, that's strange ;-)

Thanks for your further clarification :-)

> -- James

-- 
Best regards,
Eus (FSF member #4445)

In this digital era, where computing technology is pervasive, your
freedom depends on the software controlling those computing devices.

Join free software movement today! It is free as in freedom, not as in
free beer!

Join: http://www.fsf.org/jf?referrer=4445

Re: gcc-in-cxx update

[Gabriel Dos Reis]

On Wed, Apr 29, 2009 at 7:13 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

>>> * In C a const variable which is neither "extern" nor "static" is
>>>   visible outside of the current translation unit.  In C++ it is not,
>>>   without an explicit "extern" declaration.  I'm not sure how best to
>>>   handle this with -Wc++-compat, since C does not permit initializing an
>>>   "extern const" variable.
>>
>> C does permit it; there's a warning, not a pedwarn.  Add an option to
>> disable this warning (at least where "const" is used)?
>
> In any case, -Wc++-compat should warn about the difference in
> behaviour, shouldn't it?
>
> I see the current code already handles this somehow:
>
>          /* It is fine to have 'extern const' when compiling at C
>              and C++ intersection.  */
>           if (!(warn_cxx_compat && constp))
>             warning (0, "%qs initialized and declared %<extern%>", name);
>
> BTW, why is this warned about?

I believe I'm the author of that code.

We had had this debate a couple of years back, when I had more resources
to work on GCC.  At the time, I was doing an incremental version of the amazing
job Ian just accomplished and the CPP component had the construct that
declared a variable as const but did not initialize it, and did not contain
the `extern' specifier.  That in C++ meant that the variable has an internal
linkage -- but in C, the variable would have an external linkage.
So, to write the code that meant the same thing in C and in C++, an
'extern' specifier is needed.

The C people (I bellieve) at the time felt strongly that if not -Wc++-compat
it probably should be warned about (because it is not "typical" C).

-- Gaby

Re: gcc-in-cxx update

[Gabriel Dos Reis]

On Wed, Apr 29, 2009 at 8:42 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:

>>>
>>> BTW, why is this warned about?
>>
>> I imagine because in C it is not conventional to use "extern" when
>> defining something, only on a declaration that is not a definition.
>
> But may it lead to some confusion or subtle error? It seems overly
> pedantic to me if it is just a matter of style, because  extern is
> implicit if missing,
>
> If one wants to use the same code in C and C++, then it is definitely
> a spurious warning in my opinion.

I do not understand your reasoning.

-- Gaby

Re: gcc-in-cxx update

[Gabriel Dos Reis]

On Wed, Apr 29, 2009 at 10:19 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
>> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>>
>>> >> BTW, why is this warned about?
>>> >
>>> > I imagine because in C it is not conventional to use "extern" when
>>> > defining something, only on a declaration that is not a definition.
>>>
>>> But may it lead to some confusion or subtle error? It seems overly
>>> pedantic to me if it is just a matter of style, because  extern is
>>> implicit if missing,
>>
>> "int i;" is not the same as "extern int i;".
>
> Sorry for my ignorance but I have been reading and searching for the
> answer and I cannot tell what is the difference between "int i = 1"
> and "extern int i = 1" at file-scope in C.
>
> Would you or someone else mind to point me out to the answer? Thanks in advance.

I suspect you wanted to know the difference between

     const int i;

and

     extern const int;

at file scope.

>
> Manuel.
>

Re: gcc-in-cxx update

[Gabriel Dos Reis]

On Wed, Apr 29, 2009 at 10:54 AM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
>> On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>>
>>> 2009/4/29 Joseph S. Myers <joseph@codesourcery.com>:
>>> > On Wed, 29 Apr 2009, Manuel López-Ibáñez wrote:
>>> >
>>> >> >> BTW, why is this warned about?
>>> >> >
>>> >> > I imagine because in C it is not conventional to use "extern" when
>>> >> > defining something, only on a declaration that is not a definition.
>>> >>
>>> >> But may it lead to some confusion or subtle error? It seems overly
>>> >> pedantic to me if it is just a matter of style, because  extern is
>>> >> implicit if missing,
>>> >
>>> > "int i;" is not the same as "extern int i;".
>>>
>>> Sorry for my ignorance but I have been reading and searching for the
>>> answer and I cannot tell what is the difference between "int i = 1"
>>> and "extern int i = 1" at file-scope in C.
>>
>> I did not say those were different, I said the uninitialized case was
>> different, so "extern is implicit if missing" is not a general C rule.
>
> OK, then. I assumed that we were discussing about the initialized
> case, which is the origin of this thread. Hence, my suggestion stands:
> get rid of the warning.

I do not follow your reasoning here.

BTW, I already the history of the warning.

-- Gaby

Re: (extern int vs. int) and (extern function vs. function) (was: gcc-in-cxx update)

[Gabriel Dos Reis]

On Thu, Apr 30, 2009 at 6:54 AM, Eus
<reply.to.eus.at.member.fsf.org@gmail.com> wrote:
> Hi Ho!
>
> Sorry, if I sort of hijack this thread.
>
> On Wed, 2009-04-29 at 15:43 +0000, Joseph S. Myers wrote:
>
>> > > "int i;" is not the same as "extern int i;".
>> >
>> > Sorry for my ignorance but I have been reading and searching for the
>> > answer and I cannot tell what is the difference between "int i = 1"
>> > and "extern int i = 1" at file-scope in C.
>>
>> I did not say those were different, I said the uninitialized case was
>> different, so "extern is implicit if missing" is not a general C rule.
>
> I think the difference between "int i;" and "extern int i;" at
> file-scope in C is that "int i;" will only be treated as a definition if
> it is not defined in another place in the same file/TU. IOW, its linkage
> is internal within the TU itself. But, "extern int i" is definitely
> treated as a declaration only that can later be defined either in the
> same TU or in another one.
>
> Is that true?

Yes.  C has the notion of tentative definition and C++ does not.  I.e.
in C,

     int i;

is a tentative definition of 'i'; in C++ it is a definition -- so
cannot be repeated.