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

[mjacob at freebsd.org]

On Mon, 21 May 2007, Bruce Evans wrote:

> 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.

I can't parse this.


>> 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.

That's right. It at least depends upon the hptmv configuring for there 
to be a non-zero controller list and for it to be possible that the 
function will be called.

I'm going to try something you indirectly suggested which is to add the 
initialization in the called function- that would be preferrable.

> [mention of style bugs deleted]

Style cleanups come after syntactic issues.