Re: [AD] Update for gfx_mode_select/ex/filter behavior for A4.3.11+ |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: Coordination of admins/developers of the game programming library Allegro <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] Update for gfx_mode_select/ex/filter behavior for A4.3.11+
- From: Elias Pschernig <elias.pschernig@xxxxxxxxxx>
- Date: Sun, 08 Mar 2009 15:05:03 +0100
On Sun, 2009-03-08 at 04:30 -0500, Edgar wrote:
> What warning would valgrind give for it?
Access of uninitialized memory.
> 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.
As I said, nothing bad can happen here as in the worst case you get a
random initial selection - but a program with execution based on
uninitialized memory simply is wrong.
>
> > I don't understand - what kind of conflict with GFX_AUTODETECT would
> > occur?
> Maybe in practice there wouldn't be one,
Good, because if there could be one, use of uninitialized variables
(i.e. someone compiling an Allegro 4.2 program with 4.4) would lead to
this very conflict.
> However, the logic inside the functions would remain the same,
Yes, only the documentation should be more clear about what you can
pass.
> 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.
As long as it solves the problem, everything is fine to me - require
that all variables must be initialized to sane values or require that
they are all initialized to 0 or -1 (then no change in the code is
required), or require that if *card is GFX_AUTODETECT *w and *h can be
uninitialized (and don't read their values then).
--
Elias Pschernig <elias@xxxxxxxxxx>