[alsa-devel] [PATCH v2 - alsa-lib] cleanup: Use uint*_t instead of u_int*_t everythwere

[Takashi Iwai]

On Wed, 12 Jul 2017 15:59:17 +0200,
Natanael Copa wrote:
> 
> On Wed, 12 Jul 2017 14:42:21 +0200
> Takashi Iwai <tiwai at suse.de> wrote:
> 
> > On Wed, 12 Jul 2017 13:50:48 +0200,
> > Natanael Copa wrote:
> > > 
> > > Use the standard uint{8,16,32,64}_t everywhere instead of the
> > > non-standard u_int{8,16,32,64}_t.  
> > 
> > Note that, since it changes the types in the public header, it's no
> > trivial "cleanup".  It has even a risk of breakage, in theory.
> 
> Yes.
> 
> > So, this has to be carried with a care, and it needs a better
> > clarification why the change has to be applied.
> > Could you give more background?
> 
> The intention was just to clean up code and to not add custom data
> types when there are standard ones to use.
> 
> The standard uint{8,32,64}_t are also used various places in alsa-lib
> code, so I thought it was better to be consistent to avoid
> unintentional side-effects and breakages.
> 
> If you have a system where you rely on u_int8_t != uint8_t etc, then
> you have system which is so weird that you probably know how to handle
> it.
> 
> If you on the other hand unintentionally have u_int8_t != uint8_t then
> you probably want things to break early and at minimum give a compiler
> warning.
> 
> The thinking is, if things breaks due to this, then it probably
> *should* break.
> 
> If there are any plans for ABI breakage in near future, then it might
> be an idea to do this at that point.

Well, it's not my point.  This change wouldn't break the *ABI*.  These
types are strictly defined with the bit width, so the resultant binary
has to be same.  If that were broken, it's a bug to be fixed, indeed.

However, *API* might be still potentially broken by the type changes.
That is, your program might not be built with this change, although
the new alsa-lib binary still works as is.  That's my only concern.

Basically I'm not objecting against this change.  But we should be
aware of this potential breakage, and clarify why still carrying such
a change, namely showing the merit by this change clearly in the
commit log.


thanks,

Takashi