🚀 go-pugleaf

vavasis@CS.Cornell.EDU (Stephen Vavasis) wrote:

>I would like to make a plea to the compiler-writers who read this
>group: please issue warnings for syntactic trouble spots!  Implicit
>type conversion probably creates other traps that I haven't thought
>of.  C++ programmers like me need help from the compiler to navigate
>the traps!

What about when I create a normal object?

MyClass* pMyObject = new MyClass(Initializer);

Should this also generate a warning?  If the syntax was exceptional,
but legal,  then I'd say'd it should generate a warning.  However,
this syntax is not exception and is used quite frequently.

===============================================
DISCLAIMER: I may be a member of humanity,
but I'm not a spokesman for humanity.
	davidb@datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4k3q4p$lkd@syn.cs.cornell.edu> vavasis@CS.Cornell.EDU
(Stephen Vavasis) writes:

|> I have just spent a long time tracking down a mysterious bug (the
|> heap-trashing variety of bug) in my program caused by a syntactic trap
|> in C++.  The troubling thing about this trap is that none of the unix
|> compilers I tried (gcc-2.7.2, Sun SC3.0.1, HP-UX cfront 3.0.3) issued
|> a warning about the mistake, even on the highest warning level.  Only
|> Visual C++4.0 observed that there might be a problem.  Here is an
|> example of the trap.  This program asks the user how many asterisks,
|> and then prints out that many asterisks.

|> #include <iostream.h>
|> int main() {
|>   cout << " How many *'s? ";
|>   int sz; cin >> sz;
|>   char* a = new char(sz + 1); // bug is here, but syntax is legal.
|>   for (int i = 0; i < sz; i++)
|>     a[i] = '*';
|>   a[sz] = 0;
|>   cout << a << endl;
|>   delete[] a;
|>   return 0;
|> }

|> (Does everyone see the error?  I did not, even after staring at my
|> code for a long time.  The point is that the marked statement is an
|> unintended cast from int to char because I used () instead of [].)

|> I would like to make a plea to the compiler-writers who read this
|> group: please issue warnings for syntactic trouble spots!  Implicit
|> type conversion probably creates other traps that I haven't thought
|> of.  C++ programmers like me need help from the compiler to navigate
|> the traps!

The problem is that most of the time, it is the initialization of a
single object (the form that you used) which is wanted.  In practice,
one simply doesn't allocate arrays.  Thus, your program would typically
be more like:

    int
    main()
    {
        int             results( EXIT_FAILURE ) ;
        cout << " How many *'s? " << flush ;
        int             sz ;
        cin >> sz ;
        if ( ! cin || sz < 0 )
            cerr << "Illegal input value or EOF" << endl ;
        else
        {
            cout << string( sz , '*" ) << endl ;
            result = EXIT_SUCCESS ;
        }
        return results ;
    }

Even if the purpose of the exercise is to use a loop to fill a vector,
the else branch of the if would be something like:

    {
        vector< char >      a( sz + 1 ) ;
        //  ...
    }

(Note that in this case, the input validation would have to reject the
value of INT_MAX, as well as negative values, in order to avoid a
possible overflow.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Stephen Vavasis (vavasis@CS.Cornell.EDU) wrote:
> #include <iostream.h>
> int main() {
>   cout << " How many *'s? ";
>   int sz; cin >> sz;
>   char* a = new char(sz + 1); // bug is here, but syntax is legal.
>   for (int i = 0; i < sz; i++)
>     a[i] = '*';
>   a[sz] = 0;
>   cout << a << endl;
>   delete[] a;
>   return 0;
> }

> (Does everyone see the error?  I did not, even after staring at my
> code for a long time.  The point is that the marked statement is an
> unintended cast from int to char because I used () instead of [].)

> I would like to make a plea to the compiler-writers who read this
> group: please issue warnings for syntactic trouble spots!  Implicit
> type conversion probably creates other traps that I haven't thought
> of.  C++ programmers like me need help from the compiler to navigate
> the traps!

At the risk of sounding insulting, I wonder if you have been using C++ 
long. This strikes being similar the the error in the latest 
PC-Lint ads ("for (i = 0; i <= 10; i++)"): It looks like it would be easy 
to make but does not occur often in practice because programmers who use 
the language often are simply not accustomed to writing the incorrect 
version and would never do it under normal circumstances.

I agree that it is uusual to allocate a single object of a built-in type 
this way, but how do you propose to write this in such a way that such a 
warning would not be generated? All I can think of is to warn when *any* 
conversion occurs (this one looks pretty explicit to me), forcing you to 
write something like this:

  char *foo = new char(static_cast<char>(10));

(Actually this rule doesn't seem too bad if applied only to built-in 
types...)

--
class JohnWilliams: public Student, public Programmer {
public:
  char const *operator&() const { return "johnw@jove.acs.unt.edu"; }
  char const *homepage () const { return "http://www.unt.edu/~johnw"; }
};
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

In article <4kcrhk$aj1@hermes.acs.unt.edu> johnw@jove.acs.unt.edu (John
R. Williams) writes:

    [Concerning a warning for `new char( 10 )'...]
|> I agree that it is uusual to allocate a single object of a built-in type 
|> this way, but how do you propose to write this in such a way that such a 
|> warning would not be generated? All I can think of is to warn when *any* 
|> conversion occurs (this one looks pretty explicit to me), forcing you to 
|> write something like this:

|>   char *foo = new char(static_cast<char>(10));

|> (Actually this rule doesn't seem too bad if applied only to built-in 
|> types...)

Let's see:

    int*        pi = new int( static_cast< int >( 10 ) ) ;

Do you want the compiler to warn if you omit the static_cast (of int to
int)? 

I do not think that I have a single instance of allocation of an array
in any of my code.  Why should you make the most frequent case the most
difficult.  (And allocating a single int is not that infrequent.  You
might look at the implementation of counted_ptr in Barton and Nackman,
for example.  It is certainly more frequent than allocating an array of
int's, at least in well written C++ code.)
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4k3q4p$lkd@syn.cs.cornell.edu>,
vavasis@CS.Cornell.EDU (Stephen Vavasis) wrote:

|> The troubling thing about this trap is that none of the unix
|> compilers I tried (gcc-2.7.2, Sun SC3.0.1, HP-UX cfront 3.0.3) issued
|> a warning about the mistake, even on the highest warning level.  Only
|> Visual C++4.0 observed that there might be a problem.  Here is an
|> example of the trap. 
...
|>   char* a = new char(sz + 1); // bug is here, but syntax is legal.

Perhaps you should try one of the C++ lints? There are many, many areas
where the (draft) standard allows constructs of dubious value but the
committee have always been careful not to remove a construct solely on the
grounds that programmers might shoot themselves in the foot.

Sean A Corfield
Object Consultancy Services
C++ - Beyond the ARM - http://nw.demon.co.uk/ocsltd/c++/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze (kanze@gabi-soft.fr) wrote:
> In article <4kcrhk$aj1@hermes.acs.unt.edu> johnw@jove.acs.unt.edu (John
> R. Williams) writes:

>     [Concerning a warning for `new char( 10 )'...]
> |> I agree that it is uusual to allocate a single object of a built-in type 
> |> this way, but how do you propose to write this in such a way that such a 
> |> warning would not be generated? All I can think of is to warn when *any* 
> |> conversion occurs (this one looks pretty explicit to me), forcing you to 
> |> write something like this:

> |>   char *foo = new char(static_cast<char>(10));

> |> (Actually this rule doesn't seem too bad if applied only to built-in 
> |> types...)

> Let's see:

>     int*        pi = new int( static_cast< int >( 10 ) ) ;

> Do you want the compiler to warn if you omit the static_cast (of int to
> int)? 

What I meant (but perhaps did not make clear) is that the warning would 
only be in the case of *conversions* (and possibly promotions). In this 
case my rule would allow more comfortable syntax without a warning.

> I do not think that I have a single instance of allocation of an array
> in any of my code.  Why should you make the most frequent case the most
> difficult.  (And allocating a single int is not that infrequent.  You
> might look at the implementation of counted_ptr in Barton and Nackman,
> for example.  It is certainly more frequent than allocating an array of
> int's, at least in well written C++ code.)

I admit that since I get a copy of HP's STL I have almost entirely 
stopped using array new, but OTOH I can't remeber a single time I've 
allocated just one object of a built-in type. This suggests to me that
the issue is one of of style and context, not ability to program.

At any rate, I don't like my idea either--I was just throwing it out to 
see what people would think.

--
class JohnWilliams: public Student, public Programmer {
public:
  char const *operator&() const { return "johnw@jove.acs.unt.edu"; }
  char const *homepage () const { return "http://www.unt.edu/~johnw"; }
};


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]