On Mon, 2013-11-04 at 21:14 +0600, Alexander E. Patrakov wrote:
> 2013/11/4 Luiz Augusto von Dentz <luiz.dentz at gmail.com>:
> > +/** Stores extended information about a specific profile of a card. \since 5.0 */
> > +typedef struct pa_card_profile_info2 {
> > + const char *name; /**< Name of this profile */
> > + const char *description; /**< Description of this profile */
> > + uint32_t n_sinks; /**< Number of sinks this profile would create */
> > + uint32_t n_sources; /**< Number of sources this profile would create */
> > + uint32_t priority; /**< The higher this value is, the more useful this profile is as a default. */
> > int available;
> > /**< Is this profile available? If this is zero, meaning "unavailable",
> > * then it makes no sense to try to activate this profile. If this is
> > * non-zero, it's still not a guarantee that activating the profile will
> > * result in anything useful, it just means that the server isn't aware of
> > * any reason why the profile would definitely be useless. \since 5.0 */
> > -} pa_card_profile_info;
> > +} pa_card_profile_info2;
>
> I'd say that at some time in the future we are going to need some new
> fields in this structure. I suggest (yes, Microsoft-style, I know) to
> add an array of reserved fields to the end of the structure, while it
> is not too late. The idea is that these reserved fields can get some
> new meaning in the future without changing the struct size and thus
> without breaking the ABI each time a new meaningful field is needed.
We can safely add new fields to the struct without any padding. This
patch fixes a one-time glitch due to a design mistake in pa_card_info.
pa_card_info should have had an array of pointers to
pa_card_profile_info, but it had an array of the structs themselves
instead. Clients that used the array broke. If that array had contained
pointers, clients would have been fine when pa_card_profile_info was
extended with the available flag.
--
Tanu
