49640 - C cast used on C++ object

Status: RESOLVED INCOMPLETE

(Core :: XPCOM, defect)

Description

[Bruce Mitchener]

nsIFile.idl has this line in it:
*result = (nsIFile*)dir.get();

The HP compiler warns about this, but I was under the impression that we 
shouldn't be using C-style casts on any C++ objects like that.

For reference, the HP warning is:
Warning 749: "../../dist/include/nsIFile.h", line 761 # The cast from 
'nsDerivedSafe<nsISupports> *' to 'nsIFile *' is performed as a 
'reinterpret_cast'. This operation is non-portable and potentially unsafe.
        *result = (nsIFile*)dir.get();

Comment 1

[Ray Whitmer]

Doing a simple search, for example, on ".get()" would seem ti indicate that this 
type of cast is being done all over the place.  Are the others somehow not 
reported as warnings by the HP compiler?  What would you suggest to replace this 
reinterpret cast?

Comment 2

[Bruce Mitchener]

Some are ... I've reported most of the non-mail/news instances of this warning. 
If nothing else, it'd be nice to see the actual C++ cast via NS_REINTERPRET_CAST
used rather than the C-style one.

One other thing that I'm not clear on is what the order of operations is in the
case of this expression.  Is it doing:  ((nsIFile*)dir).get(), or is it doing
(nsIFile*)(dir.get()) ?

Comment 3

[Ray Whitmer]

I was just determining the priority so I could triage it properly.

Dots bind much tighter than casting.  You always have to use extra parents to 
cast before using a dot.

Are you saying the HP warning goes a way when we use REINTERPRET_CAST?  If so, 
I'd hope we could make a single bug and get someone to go through all the source 
eliminating the older form.  I am making this future.

Comment 4

[Bruce Mitchener]

I already went through the HP build logs and filed almost all of the appropriate
bugs. (I left out anything involving structs rather than real C++ classes.)

If I submit a patch for this trivial fix to nsIFile.idl, can you review it, so
that I can get it approved by waterson?  (This particular warning is the single
most common instance of it in the source, with the 2nd most common being some
xpconnect ones that jband is already on.)

Comment 5

[Warren Harris]

Edward: Welcome to xpcom!

Comment 6

[Warren Harris]

Once again... attempting to reassign from Ray to Edward.

Comment 7

[Edward Kandrot]

Submit the patch, and I'll review it (rayw is no longer associated with XPCOM).

Comment 8

[Doug Turner (:dougt)]

reassign all kandrot xpcom bug.

Comment 9

[Benjamin Smedberg]

Don't care about C casts enough to keep this bug open.