Re: pedantic: not fussing enough?

Re: pedantic: not fussing enough?

[mike stump]

> X-Apparently-From: <cpitaar@yahoo.com.ar>
> From: "Carlos Pita" <cpitaar@yahoo.com.ar>
> To: <gcc@gcc.gnu.org>
> Date: Wed, 11 Jul 2001 04:54:16 -0300

> I think it will take some discussion until any of these observations could
> be said to be a bug.
> Perhaps this is not the right list for this kind of discussion anyway.
> Please give me advice.

comp.lang.c++ or comp.std.c++ might be a good place to discuss the
validity of any particular code.  Also, trying out the sample code
against 10 compilers that claim to be ANSI conformant is always
useful.

gcc-bugs is a more appropriate place than here for the discussion of
bugs.

Re: pedantic: not fussing enough?

[Andreas Jaeger]

Wolfgang Bangerth <wolfgang.bangerth@iwr.uni-heidelberg.de> writes:

> On Wed, 11 Jul 2001, Carlos Pita wrote:
> 
>>  I'm studying the ISO C++ standard in some detail. While Im reading it I
>> use to compile some tests using g++ (3.0) with the -pedantic command line
>> option and to compare the actual results (reports) against the ones required
>> by the statements in the standard. I think it would be helpful to post any
>> possible violations to the standard I could find (except, of course, for
>> rules for which no diagnostic is required, which would not be a violation).
> 
> I think it would even be interesting to have the test case that did _not_
> fail: they might be turned into an automatic test suite to assure that
> future gcc development does not break any conformance that exists today.
> There are such conformance test suites, but as far as I know they have
> licenses that do not allow their inclusion into gcc, so having an
> independent 'free' one that could be run as part of the usual regression
> checking would certainly be beneficial.
> 
> So maybe you could modify all your tests (not only those that fail) into a
> form that fits into the regression test suite of gcc?

That would be a worthwile task!  Currently the testsuite contains
mainly tests for things that did not work at one time but trying to
cover the complete C++ standard and therefore covering all parts of
the compiler would help compiler development a lot IMO.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: pedantic: not fussing enough?

[Wolfgang Bangerth]

On Wed, 11 Jul 2001, Carlos Pita wrote:

>  I'm studying the ISO C++ standard in some detail. While Im reading it I
> use to compile some tests using g++ (3.0) with the -pedantic command line
> option and to compare the actual results (reports) against the ones required
> by the statements in the standard. I think it would be helpful to post any
> possible violations to the standard I could find (except, of course, for
> rules for which no diagnostic is required, which would not be a violation).

I think it would even be interesting to have the test case that did _not_
fail: they might be turned into an automatic test suite to assure that
future gcc development does not break any conformance that exists today.
There are such conformance test suites, but as far as I know they have
licenses that do not allow their inclusion into gcc, so having an
independent 'free' one that could be run as part of the usual regression
checking would certainly be beneficial.

So maybe you could modify all your tests (not only those that fail) into a
form that fits into the regression test suite of gcc?

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth          email: wolfgang.bangerth@iwr.uni-heidelberg.de
                             www: http://gaia.iwr.uni-heidelberg.de/~wolf

Re: pedantic: not fussing enough?

[Joseph S. Myers]

On Wed, 11 Jul 2001, Carlos Pita wrote:

> I think it will take some discussion until any of these observations could
> be said to be a bug.
> Perhaps this is not the right list for this kind of discussion anyway.
> Please give me advice.

If the compiler fails to diagnose an invalid program, that is a bug and
should be filed as such; the appropriate class to give in the bug report
is "accepts-illegal".  If the bug report is incorrect, it will probably be
closed as such within the next few years; if correct, the problem might be
fixed immediately, or in a few years' time, but if you post to the mailing
lists rather than to GNATS then the latter option is unlikely to happen.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: pedantic: not fussing enough?

[Carlos Pita]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]

I think it will take some discussion until any of these observations could
be said to be a bug.
Perhaps this is not the right list for this kind of discussion anyway.
Please give me advice.

Thank you,
    Carlos

----- Original Message -----
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: "Carlos Pita" <cpitaar@yahoo.com.ar>
Cc: <gcc@gcc.gnu.org>
Sent: Wednesday, July 11, 2001 4:40 AM
Subject: Re: pedantic: not fussing enough?


On Wed, 11 Jul 2001, Carlos Pita wrote:

>  I'm studying the ISO C++ standard in some detail. While I´m reading it I
> use to compile some tests using g++ (3.0) with the -pedantic command line
> option and to compare the actual results (reports) against the ones
required
> by the statements in the standard. I think it would be helpful to post any
> possible violations to the standard I could find (except, of course, for
> rules for which no diagnostic is required, which would not be a
violation).
> If you don't find it useful please say it to me.

Bug reports should go to our GNATS bug tracking database, one PR per
issue, unless the C++ maintainers think some other method would be more
useful.  Anything just sent to the mailing lists is likely to be forgotten
unless someone decides to act on it immediately.

--
Joseph S. Myers
jsm28@cam.ac.uk


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: pedantic: not fussing enough?

[Carlos Pita]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4192 bytes --]

...following with the pedantic thread...



3)  <<<<<<<<<<<<<<<<<<<<<<

3.3.2.2

Local scope
....
 The potential scope of a ***function parameter name in a function
definition*** (8.4) begins at its point of declaration. If the function has
a function try-block the potential scope of a parameter ends at the end of
the last associated handler, else it ends at the end of the outermost block
of the function definition. A parameter name shall not be redeclared in the
outermost block of the function definition nor in the outermost block of any
handler associated with a function try-block .
....

3.3.3.1

Function prototype scope

 In a function declaration, or in any function declarator ***except the
declarator of a function definition*** (8.4), names of parameters (if
supplied) have function prototype scope, which terminates at the end of the
nearest enclosing function declarator.

3.3.5

... for an elaborated-type-specifier of the form class-key identifier
 *a* if the elaborated-type-specifier is used in the decl-specifier-seq or
parameter-declaration-clause of a function defined in namespace scope, the
identifier is declared as a class-name in the namespace that contains the
declaration;
 *b* otherwise, except as a friend declaration, the identifier is declared
in the smallest non-class, non-function-prototype scope that contains the
declaration...

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

class X {
public:
  void fa(class A* a) {  // declaration of a is in local scope
    class B fb(); // declaration of fb is in local scope
    B *pb; // Ok
  }
  A *pa; // Wrong, previous declaration of A should be confined to fa  (rule
*b*)   (1)
  B *pb; // Wrong, idem (rule *b*)    (2)
  void fc(class C* c); // declaration of c is in function prototype scope
  C *pc; // Right
};

namespace Y {
  void fa(class A* a) {  // declaration of a is in local scope
    //...
  }
  A *pa; // Right. This time fa is defined in a namespace scope and previous
             // declaration of A is used in its parameter-declaration-clause
(rule *a*)
};

int main() {
//....
}

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

 (2), of course, reports an error. But (1) compiles without problems. I
think this is a violation to the standard. In fact, note that if it wasn't
one, rule *a* would be only a special case of rule *b*: the
elaborated-type-specifier is considered to be used in function prototype
scope (this is the wrong hypothesis) and because the function definition is
in namespace scope (according to rule *a*) the "smallest non-class,
non-function-prototype scope that contains the declaration" will be the
namespace that contains the declaration, which reduces rule *a* to a case of
rule *b*. But if the elaborated-type-specifier is considered to be used in a
local scope, the rule *a* is in fact necessary. I'm not pretending that this
is the decisive argument: that's the reason I'm quoting you the definitions
of function prototype scope and local scope. Although perhaps they are not
the clearest definitions I've seen, I would say that they make clear the
fact that declaration of A is in local scope (in both cases) and declaration
of C is in function prototype scope in the program above.

>>>>>>>>>>>>>>>>>>>>>>>>>>


 Is this kind of maddening grammar/semantics really really necessary?
Special rules everywhere! I'm a programmer and altough I don't write
compilers I like to read the standards besides any tutorial or reference
documentation for the languages I use. But the kind of erudition that this
standard request from me makes me feel that it's just waste of time to take
it too seriously. Perhaps I should only blindly program (ok, I´m being
kitsch and melodramatic), waiting for my compiler to fuss about every
violation to standards, and for the mad rules to result in just what common
sense would expect...but this isn't realistic anyway. I'm a little
disappointed (and the subtle ambiguities of the standard increses this
feeling). Surely I'm wrong. Perhaps I've born with the -pedantic switch
turned on. :)

See you,
 Carlos P.


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: pedantic: not fussing enough?

[Joseph S. Myers]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

On Wed, 11 Jul 2001, Carlos Pita wrote:

>  I'm studying the ISO C++ standard in some detail. While I´m reading it I
> use to compile some tests using g++ (3.0) with the -pedantic command line
> option and to compare the actual results (reports) against the ones required
> by the statements in the standard. I think it would be helpful to post any
> possible violations to the standard I could find (except, of course, for
> rules for which no diagnostic is required, which would not be a violation).
> If you don't find it useful please say it to me.

Bug reports should go to our GNATS bug tracking database, one PR per
issue, unless the C++ maintainers think some other method would be more
useful.  Anything just sent to the mailing lists is likely to be forgotten
unless someone decides to act on it immediately.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

pedantic: not fussing enough?

[Carlos Pita]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4646 bytes --]

Hi!

 I'm studying the ISO C++ standard in some detail. While I´m reading it I
use to compile some tests using g++ (3.0) with the -pedantic command line
option and to compare the actual results (reports) against the ones required
by the statements in the standard. I think it would be helpful to post any
possible violations to the standard I could find (except, of course, for
rules for which no diagnostic is required, which would not be a violation).
If you don't find it useful please say it to me.

 Below is a list of possible violations I've found this time. You will see
an excerpt from the standard first and then, just below it, a list of
commented examples showing where the problem seems to be.

See you,
    Carlos P.

PD: if you think I should only write the section numbers instead of quoting
the entire (or part of the) statements I'll just do it. .

1) <<<<<<<<<<<<<<<<<

3.3.4

Given a set of declarations in a single declarative region, each of which
specifies the same unqualified name, they shall
      * all refer to the same entity, or all refer to functions and function
templates; or
      * exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all refer
to the same object or enumerator, or all refer to functions and function
templates; in this case the class name or enumeration name is hidden
(3.3.7). [Note: a namespace name or a class template name must be unique in
its declarative region (7.3.2, clause 14). ]

9.1.3

      An elaborated-type-specifier (7.1.5.3) can also be used as a
type-specifier as part of a declaration. It differs from a class declaration
in that if a class of the elaborated name is in scope the elaborated name
will refer to it. [Example:

struct s { int a; };

void g(int s)
{
 struct s* p = new struct s;               // global s
 p->a = s;                                 // local s
}

(Observation: a class declaration is also an elaborated-type-specifier of
the form 'class-key  identifier;' as stated in section 7.1.5.3. But
statement 9.1.3 is almost explicitly considering them as different
constructs... As it is in a lot of other cases, the standard is too vague
here again >:( ).

------------------
/*
 * This works without any pedantic complaint. I think it shouldn't: in both
 * examples a redeclaration of class 'a' is being done and neither every
 * declaration of 'a' refers to a function nor to the same entity. In any
 * case I can't see the point of the rule...perhaps having a class name
 * redeclared after the object/enumerator declaration would give the wrong
 * impression of putting the name into scope (when in fact it would still be
 * hidden).
 * class a should be accessed as an elaborate-type-specifier that is not
 * the sole component of a declaration, as in the declaration of h in the
 * main function.
 */

class a {
  int a;
  int b;
};

int a;
extern int a;

class a;  // violation! perhaps 'a' seems to be in scope (?)

int main() {
    .....
    class a h;
    .....
}

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

// Similar example:

class a {
  int a;
  int b;
};

int a(int);
int a(int, int);

class a;  // violation! perhaps 'a' seems to be in scope (?)

int main() {
    .....
}


>>>>>>>>>>>>>>>>>>




2)  <<<<<<<<<<<<<<<<<<

Again...


3.3.4

Given a set of declarations in a single declarative region, each of which
specifies the same unqualified name, they shall
      * all refer to the same entity, or all refer to functions and function
templates; or
      * exactly one declaration shall declare a class name or enumeration
name that is not a typedef name and the other declarations shall all refer
to the same object or enumerator, or all refer to functions and function
templates; in this case the class name or enumeration name is hidden
(3.3.7). [Note: a namespace name or a class template name must be unique in
its declarative region (7.3.2, clause 14). ]


And just remember that...

3.3

An entity is a value, object, subobject, base class subobject, array
element, variable, function, instance of a function, enumerator, **type**,
class member, template, or **namespace**.

9.1

A **class** is a **type**. Its name becomes a class-name (9.1) within its
scope.


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

// The same name, two different entities which are not functions and
// which don't make a set of 2 elements:
// { class/enumeration, object/enumerator/function}

namespace X {
....
};

class X {
....
};

int main() {
....
}

>>>>>>>>>>>>>>>>>>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com