Re: [AD] Update for gfx_mode_select/ex/filter behavior for A4.3.11+

[Edgar <edgarreynaldo@xxxxxxxxxx>]

On 3/6/2009 at 8:25 AM, Elias wrote :
> I still think the docs need to be changed to make more clear that you
> must not pass pointers to uninitialized variables in any of the three
> functions now (and a note saying so for the first one should be added to
> api._tx, as that is a change slightly breaking compatibility - valgrind
> will now warn on code which was perfectly fine before and such code
> therefore should be updated when upgrading).
I don't see why you can't pass pointers to uninitialized variables. No 
matter what the value is in memory there, if it is not in the list, the 
entry selection will just default to the first entry in the selection 
list. What warning would valgrind give for it? Not trying to be 
argumentative, just don't see what's wrong with it, as even that case is 
included in the logic for the initial index selection. Also, the point 
was to remove the restriction, as it seemed a little strange to me. 
Shouldn't users always initialize their variables anyway, and if they 
don't then it's their own problem?

> I don't understand - what kind of conflict with GFX_AUTODETECT would
> occur?
Maybe in practice there wouldn't be one, however, I was thinking that if 
you use a current driver id as the value indicating not to search for 
the values in the lists and default to the first entry, then you 
couldn't use that driver id to indicate that it is the initial value you 
would like the list selection to have. Currently, I think that 
GFX_AUTODETECT may always be the first entry in the list for 
gfx_mode_select and gfx_mode_select_ex, but if the user filters that 
mode out in gfx_mode_select_filter it would have to default to the first 
entry anyway. So perhaps it wouldn't cause any problems to use values of 
0 at the addresses passed to the function. Maybe there should be a note 
saying not to leave the *card value at GFX_NONE though, as that could 
cause problems being one of the possibly returned values, for errors, 
and for completely filtered mode lists.

However, the logic inside the functions would remain the same, but only 
check for entry matches if the values at the addresses passed to the 
functions were not zero. So each search would be wrapped in a (if 
*parameter != 0) clause. I think it's fine to always search for the 
values at the addresses passed to the function, but if you'd prefer it 
the other way that's fine. Also, the behavior would be exactly the same 
as always searching for the values anyway, as 0 would never be found on 
the lists except for the driver list as GFX_AUTODETECT, which would lead 
to the first entry anyway. We could leave the function draft as it is, 
and add a note to the documentation saying to have a value of 0 at the 
addresses if they want to always default to the first entry in each list.

Let me know what you decide, and I'll rework the functions and 
documentation and resubmit the patch.
Edgar