Re: Parameter Name Warning?

From: Michael Kennedy [UB] (mkennedy_at_REMOVETHIS.unitedbinary.com)
Date: 04/13/04 

Date: Tue, 13 Apr 2004 12:03:16 -0700

Hi Adam,

I want to follow up on another issue you raised below.

You said:

> > Note that parameter names are _irrelevant_ here. Just like in any other
> > function _declaration_. They are (a) of no importance to the compiler
> > and (b) ignored.

There is still an issue with this that is *not* ignored by Visual Studio.
First, I am aware that the compile disregards the parameter names here. But
there is more to those names than just what the compiler does with them.

Take the most extreme case: Consider a class exported out of a DLL. That is,
a class were you have no knowledge of the implementation parameter names.
You know only what you get in the header. Suppose that the class developer
swapped the variable names in the header but not the implementation by
mistake. Consumers of that class only see the header and will program
against it using the variable names indicated there. If the swapped types
are the same type (like char *'s in my example), then they will be sending
invalid data to the method.

To make matters worse, the VS.NET intellisense comes from the header, not
the implementation. So when those parameters are swapped, VS.NET encourages
you to use the method incorrectly.

This is why I think there should be a compiler warning when it is clear that
the parameters are mismatched (swapped around).

Regards,
Michael

"Adam Clauss" <cabadam@tamu.edu> wrote in message
news:ecMwCMYIEHA.2876@TK2MSFTNGP09.phx.gbl...
> I just wrote up a similar test program on VS 2003. Variable values were
correct for me in the watch window.
> f and localF were both 5; e and localE were both 6.
>
> Verified that they were all correct in the auto, local, and Watch 1
windows.
>
> --
> Adam Clauss
> cabadam@tamu.edu
>
> "Victor Bazarov" <v.Abazarov@comAcast.net> wrote in message
news:eifX$jXIEHA.2244@TK2MSFTNGP09.phx.gbl...
> > Michael Kennedy [UB] wrote:
> > > I recently spend too long tracking down a bug in a project I'm working
on
> > > using VC++ and VS.NET 2003 that I think could have easily been avoided
if
> > > the VC++ compiler could have reported a warning. Here's the problem:
> > >
> > > I have a typical C++ class (call it class A) defining a member method
(call
> > > it method M) with the definition defined in the header and the
> > > implementation defined in the cpp file. But two of the parameters got
their
> > > order switched *only* in the definition but not in the implementation.
In
> > > code that is:
> > > -----------------------------------------
> > > class A
> > > {
> > > public:
> > > void M(int a, int b, int c, int d, int e, int f); // note e, then
f.
> >
> > Note that parameter names are _irrelevant_ here. Just like in any other
> > function _declaration_. They are (a) of no importance to the compiler
> > and (b) ignored.
> >
> > > };
> > >
> > > void A::M(int a, int b, int c, int d, int f, int e) // note f, then e.
> > > {
> > > int localE = e;
> > > int localF = f;
> > > // ...
> > > }
> > > -----------------------------------------
> > >
> > > Obviously my values weren't named a,b,c, ... so the reversed order
wasn't so
> > > apparent. Plus, the method took many parameters so it wasn't that easy
to
> > > notice. But what was worse was when debugging into the method with the
> > > debugger, the watch window showed different values for e and f than
they
> > > actually had!
> >
> > That is VERY HARD to believe. Could you provide a screen shot? Are you
> > sure you didn't have _local_ variables named 'e' and 'f' that _hid_ the
> > values of the parameters?
> >
> > > So, consider only f in this scenario. Suppose we called method
> > > M like this M(1, 2, 3, 4, 5, 6). Then f will have the value f = 5. But
in
> > > the watch window f = 6!
> >
> > REALLY? Are you sure it's not a figment of your imagination?
> >
> > > Now if you step through the code to the // ... line,
> > > in the watch window you get:
> > >
> > > localF = 5
> > > f = 6
> > >
> > > How about that to drive you crazy! That is, immediately after the line
> > >
> > > int localF = f;
> > >
> > > executes, you get localF = 5, f = 6 in the watch window!
> >
> > What product is that, again? I have VC++6sp5 and the watch window is
fine.
> >
> > I took the code you posted, wrote a tiny driver and got this:
> > --------------------
> > class A
> > {
> > public:
> > void M(int a, int b, int c, int d, int e, int f); // note e, then f.
> > };
> >
> > void A::M(int a, int b, int c, int d, int f, int e) // note f, then e.
> > {
> > int localE = e;
> > int localF = f;
> > // ...
> > }
> >
> > int main()
> > {
> > A a;
> > a.M(1,2,3,4,5,6);
> > return 0;
> > }
> > --------------------
> >
> > Then I build a Debug version and stepped into the 'A::M' function. My
> > watch window showed 'f' as 5 at the very beginning and then later
'localF'
> > as 5 as well.
> >
> > >
> > > So here's where I think the compiler could have saved me. If it
realized
> > > that both in the definition and implementation of the method I use
exactly
> > > the same parameter names, but they are swapped around, it could have
warned
> > > me about that.
> >
> > It could. What about warning you if you misspelled something in your
> > comments? Or should the IDE do that instead? Wouldn't it be silly?
> >
> > >
> > > I realize that I could have defined the method as void M(int, int,
int, int,
> > > int, int); and the compiler wouldn't be able to say anything. But
since I am
> > > actually using the same names a,b,c,d,e,f in both the definition and
> > > implementation and they don't match, I think a warning could be in
order.
> > >
> > > Also, the debugger could have helped. If the debugger got it's
parameter
> > > definitions from the implmentation rather than the definition as the
C++
> >
> > I cannot imagine it would do that. (BTW, it's definition and
declaration,
> > not "implementation and definition") And again, I cannot imagine MS
screw
> > up so badly (well, actually, I can, but I am fairly certain there would
be
> > a patch for that already).
> >
> > > runtime/compiler does, then I would have at least noticed that the
incoming
> > > parameters e and f had the wrong values. It would have avoided the
crazy int
> > > localF = f; => localF != f in the watch window.
> > >
> > > What do you (especially Microsoft C++ guys) think?
> >
> > I think you're looking in the wrong place. I tried reproducing what you
> > described and couldn't. Of course, I'm using version 6 of VC++. Is
that
> > what you use? If not, forgive my not trusting you, and take my advice:
> > call MS Technical Support. If their debugger is so buggy itself, they
> > need to take care of it.
> >
> > Victor
> > --
> > Please remove capital As from my address when replying by mail
>
>

Relevant Pages

  • Re: Parameter Name Warning?
    ... the names on the declarations do not matter, it should perhaps give a warning regarding different names being used. ... > there is more to those names than just what the compiler does with them. ... > You know only what you get in the header. ... >>> int main ...
    (microsoft.public.vc.language)
  • Re: Error in compliling AODB _ConnectionPtr
    ... The compiler ignores ALL input ... because it may affect the definitions in that header. ... >> int main ... I had it wrong at first anf the complier never complained. ...
    (microsoft.public.vc.atl)
  • Re: Micro$haft desperate! Buy Windoze 7, get (virtual) XP free!
    ... You would need to edit a few header files so they no longer use 'int' for the basic definitions. ... The defines are alternate names that can be controlled outside the compiler, ... Apple is still keeping Carbon up to date due to the OpenGL requirements. ...
    (comp.sys.mac.advocacy)
  • Re: Tool to determine which headers are needed/not_needed?
    ... Surely that's too simplistic - consider a header containing: ... #undef FOO ... int a=1; ... Then with the default options on a lot of compilers the compiler will *not* complain, it will just silently compiler the code with what is now undefined behaviour which may or may not work. ...
    (comp.lang.c)
  • [git patches] net driver updates for .26
    ... Fix a bug where the pointer never moves for dma_unmap... ... Update and fix driver debugging messages ... int reset); ... * header structure can be anywhere in the mcp. ...
    (Linux-Kernel)