cvs commit: src/sys/dev/hptmv ioctl.c

Bruce Evans bde at optusnet.com.au
Mon May 21 08:46:11 UTC 2007


On Sun, 20 May 2007 mjacob at FreeBSD.org wrote:

>>> mjacob      2007-05-20 16:49:10 UTC
>>> 
>>>  FreeBSD src repository
>>> 
>>>  Modified files:
>>>    sys/dev/hptmv        ioctl.c
>>>  Log:
>>>  Make gcc 4.2 happy by initiatlizing controller && channel prior
>>>  to a call to a function which *might* then initialize them.
>>> 
>>>  MFC after:      3 days
>> 
>> Isn't the bug that the function doesn't always initialize them?

> That was a meta-comment- I should have made it clearer. The function 
> get_disk_location *will* always init them, but gcc-4.2 doesn't know that,

But the non-bug is still in the function and should be fixed and documented
there, not in all callers.

> and 
> unlike previous versions of gcc, gcc-4.2 no longer will assume that a 
> function that you pass a pointer to local data to will actually fill them in.

No, gcc-4.2 isn't that broken.  Initializing variables indirectly using
init(&var1, &var1) is a C idiom and is used a lot, but gcc-4.2 only
warns about a few such calls.  A typical use is bzero(&var, sizeof(var))
to initialize a variable to all 0's.  gcc-4.2 doesn't warn about this,
and I think it wouldn't warn if you misspelled the size parameter so
that the variable is only half initialized...

I think gcc-4.2 only warns if it can look inside the function, and the
function either doesn't initialize the variables or gcc cannot tell
whether it does.

In hptmv/ioctl.c, the problem is that the function searches a list and
only initializes the variables if the list is non-empty.  gcc cannot see
if the list is non-empty, and neither can I.

[mention of style bugs deleted]

Bruce


More information about the cvs-src mailing list