On Mon, May 15, 2023 at 10:44 AM Warner Losh <i...@bsdimp.com> wrote:
>
>
> On Wed, May 10, 2023 at 8:39 AM Juan Quintela <quint...@redhat.com> wrote:
>
>> Someone has a good reason why this is not a good idea?
>>
>> Signed-off-by: Juan Quintela <quint...@redhat.com>
>>
>
> Reviewed by: Warner Losh <i...@bsdimp.com>
>
> This has been that way the bsd-user sources were reorganized in 2015. I
> can find
> no good reason in the FreeBSD sources to do this (we've been transitioning
> from
> the pre-standardized BSD convention of u_intXX_t -> uintXX_t for 25 years
> now
> it seems). I don't see any old or ancient usage as far back as I looked
> why they'd
> be different. Up through FreeBSD 12.x, this was u_int32_t (for all of
> them), but
> they switched to __uint32_t in FreeBSD 13 to avoid namespace pollution.
>
> tl;dr: change good, all should match.
>
Though a better commit message would be good. With that, I'll queue it to
my branch.
Warner
> ---
>> bsd-user/arm/target_arch_reg.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/bsd-user/arm/target_arch_reg.h
>> b/bsd-user/arm/target_arch_reg.h
>> index 070fa24da1..5f1eea4291 100644
>> --- a/bsd-user/arm/target_arch_reg.h
>> +++ b/bsd-user/arm/target_arch_reg.h
>> @@ -32,7 +32,7 @@ typedef struct target_reg {
>> typedef struct target_fp_reg {
>> uint32_t fp_exponent;
>> uint32_t fp_mantissa_hi;
>> - u_int32_t fp_mantissa_lo;
>> + uint32_t fp_mantissa_lo;
>> } target_fp_reg_t;
>>
>> typedef struct target_fpreg {
>> --
>> 2.40.1
>>
>>
