cvs commit: src/sys/dev/hptmv ioctl.c
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
>>> 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.
> 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]
More information about the cvs-all