[RFC 0/3] Getting rid of "uint" and friends

[Juan Quintela]

Hi

After my last PULL request failed:

Build failures.

https://gitlab.com/qemu-project/qemu/-/jobs/4257605099#L2241

   85 | void colo_record_bitmap(RAMBlock *block, ram_addr_t *normal, uint 
normal_num);
      |                                                              ^~~~
      |                                                              u_int

it was because it had an "uint" instead of an "uint32_t".

So Richard asked me if I knew where it came from to try to poison it.

It cames from (this is Fedora38 x86_64, but I guess modern linux are similar):

/usr/include/system/types.h

...

/* Old compatibility names for C types.  */
typedef unsigned long int ulong;
typedef unsigned short int ushort;
typedef unsigned int uint;

So I decided to get rid of them.  And searching through the tree I found:
- that I had already have had this problem in the past

commit 85c93c57f162e47025441ce39e2aadd0c1e0914f
Author: Yonggang Luo <luoyonggang@gmail.com>
Date:   Sat Sep 5 14:38:13 2020 +0800

    tests: fixes test-vmstate.c compile error on msys2

    ../tests/test-vmstate.c: In function 'int_cmp':
    ../tests/test-vmstate.c:884:5: error: unknown type name 'uint'; did you mean
 'uInt'?
      884 |     uint ua = GPOINTER_TO_UINT(a);
          |     ^~~~
          |     uInt

- that someone had fixed things like this while I was not looking:

commit d7df0b41dc38327388c3f19fdf4246793d4a1e4b
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date:   Thu Jan 17 15:43:53 2019 +0400

    slirp: prefer c99 types over BSD kind

    Replace:
    - u_char -> uint8_t
    - u_short -> uint16_t
    - u_long -> uint32_t
    - u_int -> unsigned
    - caddr_t -> char *

and

commit 08dc07a32b76943417b465d2d2c464c13b566a82
Author: Stefan Weil <weil@mail.berlios.de>
Date:   Thu Jul 22 22:15:24 2010 +0200

    slirp: Remove declarations which are no longer needed

I tried sooner than that date. I digged myself in a hole and decided
to stop even trying. So hat trick, folks.

- that ARM got for some reason the only u_int32_t on the tree

- that s390-ccw is very proud to define its own ulong

- that linux-user still uses uint and ulong (no ushort)
  I can understand abi_uint and abi_ulong, but uint and ulong?  in 2023?

Should we fix this?
Should we left it as it is?

Comments people!

Later, Juan.

(*): No, I have no clue either why/where/how __USE_MISC got defined.

Juan Quintela (3):
  ARM: Use normal types
  linux-user: Drop uint and ulong
  s390-ccw: Getting rid of ulong

 bsd-user/arm/target_arch_reg.h   |  2 +-
 linux-user/mmap.c                |  2 +-
 linux-user/syscall.c             |  8 ++++----
 pc-bios/s390-ccw/helper.h        |  2 +-
 pc-bios/s390-ccw/s390-ccw.h      |  7 +++----
 pc-bios/s390-ccw/virtio-blkdev.c | 12 ++++++------
 pc-bios/s390-ccw/virtio-scsi.c   |  4 ++--
 pc-bios/s390-ccw/virtio-scsi.h   |  2 +-
 pc-bios/s390-ccw/virtio.c        | 12 ++++++------
 pc-bios/s390-ccw/virtio.h        |  4 ++--
 10 files changed, 27 insertions(+), 28 deletions(-)

-- 
2.40.1