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.
> ---
> 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
>
>
