On Wed, 12 Jul 2017 15:59:17 +0200, Natanael Copa wrote:
On Wed, 12 Jul 2017 14:42:21 +0200 Takashi Iwai tiwai@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