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.
Thanks!
-nc