Re: is there a compiler warning for this piece of code ?

Tech-Archive recommends: Fix windows errors by optimizing your registry

Victor,

Thanks for your thoughts - I think your speculation as to the history of the
code is probably correct.

I still have no easy way of parsing the codebase to see how prevalent this
is.
I'm fairly sure there are only a couple - it just would be more comforting
if I could get the
compiler to tell me about them automatically.
Maybe MS could add this to the "constant value"/"unreachable code" compiler
checks in some future VC7 fixpack.

regards
John

"Victor Bazarov" <v.Abazarov@xxxxxxxxxxxx> wrote in message
news:OyLcYO#XFHA.3540@xxxxxxxxxxxxxxxxxxxxxxx
> Kevin D. Quitt wrote:
> > On Mon, 23 May 2005 19:50:51 +0100, "John Kelly"
> > <john_kelly@xxxxxxxxxxxxxxxxx> wrote:
> >
> >>Maybe i've misunderstood, but i've interpreted "if (fred == NULL)" to
mean
> >>"if the address of the first element in the array fred (that is,
&fred[0])
> >>is NULL".
> >
> >
> > You've misunderstood. You are comparing the address of fred to NULL,
not
> > the first element of fred. An element of a char array cannot be NULL;
it
> > might be NUL, however.
>
> No, it's you who misunderstood. (fred == NULL) is comparing the address
> of the _first_element_ of 'fred' to NULL, i.e. (&fred[0] == NULL) or
> (fred + 0 == NULL), not the _contents_ of the first element. In C as in
> C++ the name of the array used in an expression _often_ decays to the
> _address_ of the first element.
>
> The address of 'fred' would be '&fred'. In case of an array the address
> of the array and the address of its first element have the same value but
> different types.
>
> My speculation (as was the OP's probably) that the code might look like
>
> char* fred = new char[100];
> if (fred == NULL)
> {
> // no more memory left, report and bail out
> }
>
> some time ago (now 'new' doesn't return NULL unless you ask it to). It
> probably was changed later to
>
> char fred[100];
>
> by a big sweep of replacing all 'new' with statically-sized arrays (which
> are faster without a doubt). The code that verified the allocation was
> left behind.
>
> >>Given this is a stack variable, this will never be true - so i'd count
this
> >>as unreachable code
> >
> >
> > Incorrect. The uninitialized value could be zero as easily as any other
> > value. Given that you are defining fred, it cannot be NULL, so is just
so
> > happens the code is unreachable.
>
> ??? I think your "Incorrect" is based on some assumptions you made which
> were incorrect themselves.
>
> > [...]
>
> V


.

Relevant Pages