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

[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

[RFC 1/3] ARM: Use normal types

[Juan Quintela]

Someone has a good reason why this is not a good idea?

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 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

Re: [RFC 1/3] ARM: Use normal types

[Richard Henderson]

On 5/10/23 15:39, Juan Quintela wrote:
> Someone has a good reason why this is not a good idea?
> 
> Signed-off-by: Juan Quintela<quintela@redhat.com>
> ---
>   bsd-user/arm/target_arch_reg.h | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [RFC 1/3] ARM: Use normal types

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Wed, May 10, 2023 at 8:39 AM Juan Quintela <quintela@redhat.com> wrote:

> Someone has a good reason why this is not a good idea?
>
> Signed-off-by: Juan Quintela <quintela@redhat.com>
>

Reviewed by:  Warner Losh <imp@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
>
>

[-- Attachment #2: Type: text/html, Size: 2150 bytes --]

Re: [RFC 1/3] ARM: Use normal types

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1642 bytes --]

On Mon, May 15, 2023 at 10:44 AM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Wed, May 10, 2023 at 8:39 AM Juan Quintela <quintela@redhat.com> wrote:
>
>> Someone has a good reason why this is not a good idea?
>>
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>>
>
> Reviewed by:  Warner Losh <imp@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
>>
>>

[-- Attachment #2: Type: text/html, Size: 2887 bytes --]

Re: [RFC 1/3] ARM: Use normal types

[Juan Quintela]

Warner Losh <imp@bsdimp.com> wrote:
> On Mon, May 15, 2023 at 10:44 AM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Wed, May 10, 2023 at 8:39 AM Juan Quintela <quintela@redhat.com> wrote:
>>
>>> Someone has a good reason why this is not a good idea?
>>>
>>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>>>
>>
>> Reviewed by:  Warner Losh <imp@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.

I think your bit of history would be good O:-)

Later, Juan.

[RFC 2/3] linux-user: Drop uint and ulong

[Juan Quintela]

I know I am getting into trouble and into big depths, but there is any
reason why we can't use regular type names?

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 linux-user/mmap.c    | 2 +-
 linux-user/syscall.c | 8 ++++----
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/linux-user/mmap.c b/linux-user/mmap.c
index 0aa8ae7356..51d40c77e4 100644
--- a/linux-user/mmap.c
+++ b/linux-user/mmap.c
@@ -859,7 +859,7 @@ abi_long target_mremap(abi_ulong old_addr, abi_ulong old_size,
 
 static bool can_passthrough_madvise(abi_ulong start, abi_ulong end)
 {
-    ulong addr;
+    unsigned long addr;
 
     if ((start | end) & ~qemu_host_page_mask) {
         return false;
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 69f740ff98..dd0349712b 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -309,16 +309,16 @@ _syscall0(int, sys_gettid)
 #endif
 
 #if defined(TARGET_NR_getdents) && defined(EMULATE_GETDENTS_WITH_GETDENTS)
-_syscall3(int, sys_getdents, uint, fd, struct linux_dirent *, dirp, uint, count);
+_syscall3(int, sys_getdents, unsigned int, fd, struct linux_dirent *, dirp, unsigned int, count);
 #endif
 #if (defined(TARGET_NR_getdents) && \
       !defined(EMULATE_GETDENTS_WITH_GETDENTS)) || \
     (defined(TARGET_NR_getdents64) && defined(__NR_getdents64))
-_syscall3(int, sys_getdents64, uint, fd, struct linux_dirent64 *, dirp, uint, count);
+_syscall3(int, sys_getdents64, unsigned int, fd, struct linux_dirent64 *, dirp, unsigned int, count);
 #endif
 #if defined(TARGET_NR__llseek) && defined(__NR_llseek)
-_syscall5(int, _llseek,  uint,  fd, ulong, hi, ulong, lo,
-          loff_t *, res, uint, wh);
+_syscall5(int, _llseek,  unsigned int,  fd, unsigned long, hi, unsigned long, lo,
+          loff_t *, res, unsigned int, wh);
 #endif
 _syscall3(int, sys_rt_sigqueueinfo, pid_t, pid, int, sig, siginfo_t *, uinfo)
 _syscall4(int, sys_rt_tgsigqueueinfo, pid_t, pid, pid_t, tid, int, sig,
-- 
2.40.1

Re: [RFC 2/3] linux-user: Drop uint and ulong

[Richard Henderson]

On 5/10/23 15:39, Juan Quintela wrote:
>   static bool can_passthrough_madvise(abi_ulong start, abi_ulong end)
>   {
> -    ulong addr;
> +    unsigned long addr;

This should be abi_ulong, to match the parameters.
Which should matter for 32-bit host and 64-bit guest.

Otherwise,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [RFC 2/3] linux-user: Drop uint and ulong

[Juan Quintela]

Richard Henderson <richard.henderson@linaro.org> wrote:
> On 5/10/23 15:39, Juan Quintela wrote:
>>   static bool can_passthrough_madvise(abi_ulong start, abi_ulong end)
>>   {
>> -    ulong addr;
>> +    unsigned long addr;
>
> This should be abi_ulong, to match the parameters.
> Which should matter for 32-bit host and 64-bit guest.
>
> Otherwise,

Thanks.  Changing it.

> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>
>
> r~

[RFC 3/3] s390-ccw: Getting rid of ulong

[Juan Quintela]

Any good reason why this still exist?
I can understand u* and __u* to be linux kernel like, but ulong?

Signed-off-by: Juan Quintela <quintela@redhat.com>
---
 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 ++--
 7 files changed, 21 insertions(+), 22 deletions(-)

diff --git a/pc-bios/s390-ccw/helper.h b/pc-bios/s390-ccw/helper.h
index 3d0731c4c6..8e3dfcb6d6 100644
--- a/pc-bios/s390-ccw/helper.h
+++ b/pc-bios/s390-ccw/helper.h
@@ -38,7 +38,7 @@ static inline void yield(void)
 
 static inline void sleep(unsigned int seconds)
 {
-    ulong target = get_time_seconds() + seconds;
+    unsigned long target = get_time_seconds() + seconds;
 
     while (get_time_seconds() < target) {
         yield();
diff --git a/pc-bios/s390-ccw/s390-ccw.h b/pc-bios/s390-ccw/s390-ccw.h
index b88e0550ab..f849fba74b 100644
--- a/pc-bios/s390-ccw/s390-ccw.h
+++ b/pc-bios/s390-ccw/s390-ccw.h
@@ -17,7 +17,6 @@ typedef unsigned char      u8;
 typedef unsigned short     u16;
 typedef unsigned int       u32;
 typedef unsigned long long u64;
-typedef unsigned long      ulong;
 typedef unsigned char      __u8;
 typedef unsigned short     __u16;
 typedef unsigned int       __u32;
@@ -67,11 +66,11 @@ void sclp_get_loadparm_ascii(char *loadparm);
 int sclp_read(char *str, size_t count);
 
 /* virtio.c */
-unsigned long virtio_load_direct(ulong rec_list1, ulong rec_list2,
-                                 ulong subchan_id, void *load_addr);
+unsigned long virtio_load_direct(unsigned long rec_list1, unsigned long rec_list2,
+                                 unsigned long subchan_id, void *load_addr);
 bool virtio_is_supported(SubChannelId schid);
 int virtio_blk_setup_device(SubChannelId schid);
-int virtio_read(ulong sector, void *load_addr);
+int virtio_read(unsigned long sector, void *load_addr);
 
 /* bootmap.c */
 void zipl_load(void);
diff --git a/pc-bios/s390-ccw/virtio-blkdev.c b/pc-bios/s390-ccw/virtio-blkdev.c
index 794f99b42c..a81207b52e 100644
--- a/pc-bios/s390-ccw/virtio-blkdev.c
+++ b/pc-bios/s390-ccw/virtio-blkdev.c
@@ -16,7 +16,7 @@
 #define VIRTIO_BLK_F_GEOMETRY   (1 << 4)
 #define VIRTIO_BLK_F_BLK_SIZE   (1 << 6)
 
-static int virtio_blk_read_many(VDev *vdev, ulong sector, void *load_addr,
+static int virtio_blk_read_many(VDev *vdev, unsigned long sector, void *load_addr,
                                 int sec_num)
 {
     VirtioBlkOuthdr out_hdr;
@@ -49,7 +49,7 @@ static int virtio_blk_read_many(VDev *vdev, ulong sector, void *load_addr,
     return status;
 }
 
-int virtio_read_many(ulong sector, void *load_addr, int sec_num)
+int virtio_read_many(unsigned long sector, void *load_addr, int sec_num)
 {
     VDev *vdev = virtio_get_device();
 
@@ -63,14 +63,14 @@ int virtio_read_many(ulong sector, void *load_addr, int sec_num)
     return -1;
 }
 
-unsigned long virtio_load_direct(ulong rec_list1, ulong rec_list2,
-                                 ulong subchan_id, void *load_addr)
+unsigned long virtio_load_direct(unsigned long rec_list1, unsigned long rec_list2,
+                                 unsigned long subchan_id, void *load_addr)
 {
     u8 status;
     int sec = rec_list1;
     int sec_num = ((rec_list2 >> 32) & 0xffff) + 1;
     int sec_len = rec_list2 >> 48;
-    ulong addr = (ulong)load_addr;
+    unsigned long addr = (unsigned long)load_addr;
 
     if (sec_len != virtio_get_block_size()) {
         return -1;
@@ -86,7 +86,7 @@ unsigned long virtio_load_direct(ulong rec_list1, ulong rec_list2,
     return addr;
 }
 
-int virtio_read(ulong sector, void *load_addr)
+int virtio_read(unsigned long sector, void *load_addr)
 {
     return virtio_read_many(sector, load_addr, 1);
 }
diff --git a/pc-bios/s390-ccw/virtio-scsi.c b/pc-bios/s390-ccw/virtio-scsi.c
index dcce696a33..d1a84b937c 100644
--- a/pc-bios/s390-ccw/virtio-scsi.c
+++ b/pc-bios/s390-ccw/virtio-scsi.c
@@ -150,7 +150,7 @@ static bool scsi_report_luns(VDev *vdev, void *data, uint32_t data_size)
 }
 
 static bool scsi_read_10(VDev *vdev,
-                         ulong sector, int sectors, void *data,
+                         unsigned long sector, int sectors, void *data,
                          unsigned int data_size)
 {
     ScsiCdbRead10 cdb = {
@@ -269,7 +269,7 @@ static int virtio_scsi_locate_device(VDev *vdev)
 }
 
 int virtio_scsi_read_many(VDev *vdev,
-                          ulong sector, void *load_addr, int sec_num)
+                          unsigned long sector, void *load_addr, int sec_num)
 {
     int sector_count;
     int f = vdev->blk_factor;
diff --git a/pc-bios/s390-ccw/virtio-scsi.h b/pc-bios/s390-ccw/virtio-scsi.h
index e6b6cd4815..c5612e16a2 100644
--- a/pc-bios/s390-ccw/virtio-scsi.h
+++ b/pc-bios/s390-ccw/virtio-scsi.h
@@ -68,7 +68,7 @@ static inline bool virtio_scsi_response_ok(const VirtioScsiCmdResp *r)
 }
 
 int virtio_scsi_read_many(VDev *vdev,
-                          ulong sector, void *load_addr, int sec_num);
+                          unsigned long sector, void *load_addr, int sec_num);
 int virtio_scsi_setup_device(SubChannelId schid);
 
 #endif /* VIRTIO_SCSI_H */
diff --git a/pc-bios/s390-ccw/virtio.c b/pc-bios/s390-ccw/virtio.c
index f37510f312..5edd058d88 100644
--- a/pc-bios/s390-ccw/virtio.c
+++ b/pc-bios/s390-ccw/virtio.c
@@ -48,10 +48,10 @@ VirtioDevType virtio_get_device_type(void)
 static long kvm_hypercall(unsigned long nr, unsigned long param1,
                           unsigned long param2, unsigned long param3)
 {
-    register ulong r_nr asm("1") = nr;
-    register ulong r_param1 asm("2") = param1;
-    register ulong r_param2 asm("3") = param2;
-    register ulong r_param3 asm("4") = param3;
+    register unsigned long r_nr asm("1") = nr;
+    register unsigned long r_param1 asm("2") = param1;
+    register unsigned long r_param2 asm("3") = param2;
+    register unsigned long r_param3 asm("4") = param3;
     register long retval asm("2");
 
     asm volatile ("diag %%r2,%%r4,0x500"
@@ -145,7 +145,7 @@ void vring_send_buf(VRing *vr, void *p, int len, int flags)
         vr->avail->ring[vr->avail->idx % vr->num] = vr->next_idx;
     }
 
-    vr->desc[vr->next_idx].addr = (ulong)p;
+    vr->desc[vr->next_idx].addr = (unsigned long)p;
     vr->desc[vr->next_idx].len = len;
     vr->desc[vr->next_idx].flags = flags & ~VRING_HIDDEN_IS_CHAIN;
     vr->desc[vr->next_idx].next = vr->next_idx;
@@ -182,7 +182,7 @@ int vr_poll(VRing *vr)
  */
 int vring_wait_reply(void)
 {
-    ulong target_second = get_time_seconds() + vdev.wait_reply_timeout;
+    unsigned long target_second = get_time_seconds() + vdev.wait_reply_timeout;
 
     /* Wait for any queue to be updated by the host */
     do {
diff --git a/pc-bios/s390-ccw/virtio.h b/pc-bios/s390-ccw/virtio.h
index e657d381ec..85bd9d1695 100644
--- a/pc-bios/s390-ccw/virtio.h
+++ b/pc-bios/s390-ccw/virtio.h
@@ -190,14 +190,14 @@ int virtio_get_block_size(void);
 uint8_t virtio_get_heads(void);
 uint8_t virtio_get_sectors(void);
 uint64_t virtio_get_blocks(void);
-int virtio_read_many(ulong sector, void *load_addr, int sec_num);
+int virtio_read_many(unsigned long sector, void *load_addr, int sec_num);
 
 #define VIRTIO_SECTOR_SIZE 512
 #define VIRTIO_ISO_BLOCK_SIZE 2048
 #define VIRTIO_SCSI_BLOCK_SIZE 512
 #define VIRTIO_DASD_DEFAULT_BLOCK_SIZE 4096
 
-static inline ulong virtio_sector_adjust(ulong sector)
+static inline unsigned long virtio_sector_adjust(unsigned long sector)
 {
     return sector * (virtio_get_block_size() / VIRTIO_SECTOR_SIZE);
 }
-- 
2.40.1

Re: [RFC 3/3] s390-ccw: Getting rid of ulong

[Thomas Huth]

On 10/05/2023 16.39, Juan Quintela wrote:
> Any good reason why this still exist?
> I can understand u* and __u* to be linux kernel like, but ulong?
> 
> Signed-off-by: Juan Quintela <quintela@redhat.com>
> ---
>   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 ++--
>   7 files changed, 21 insertions(+), 22 deletions(-)

Reviewed-by: Thomas Huth <thuth@redhat.com>

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

[Daniel P. Berrangé]

On Wed, May 10, 2023 at 04:39:22PM +0200, Juan Quintela wrote:
> 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

snip

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

It is a result of _GNU_SOURCE=1, which activates more or
less "everything" that GLibC exposes


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|