Date: Thu, 27 Jul 2023 17:22:45 -0700 From: Mark Millard <marklmi@yahoo.com> To: "mckusick@freebsd.org" <mckusick@FreeBSD.org>, dev-commits-src-main@freebsd.org Subject: RE: git: 831b1ff7913f - main - UFS/FFS: Migrate to modern uintXX_t from u_intXX_t. Message-ID: <B1344E0F-E41E-4BCD-9A78-5BF8A6B1D6BA@yahoo.com> References: <B1344E0F-E41E-4BCD-9A78-5BF8A6B1D6BA.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusick <mckusick_at_FreeBSD.org> wrote on Date: Thu, 27 Jul 2023 22:27:49 UTC : > The branch main has been updated by mckusick: >=20 > URL: = https://cgit.FreeBSD.org/src/commit/?id=3D831b1ff7913fb0b317a258a43dce5abe= fee03a31 >=20 > commit 831b1ff7913fb0b317a258a43dce5abefee03a31 > Author: Kirk McKusick <mckusick@FreeBSD.org> > AuthorDate: 2023-07-27 22:26:01 +0000 > Commit: Kirk McKusick <mckusick@FreeBSD.org> > CommitDate: 2023-07-27 22:27:36 +0000 >=20 > UFS/FFS: Migrate to modern uintXX_t from u_intXX_t. >=20 > As per = https://lists.freebsd.org/archives/freebsd-scsi/2023-July/000257.html > move to the modern uintXX_t. While here also migrate u_char to = uint8_t. > Where other kernel interfaces allow, migrate u_long to uint64_t. Looks dangerous to me . . . u_long (a.k.a. unsigned long) on armv7, for example, is 32 bits, not 64. Same for i386, I expect. For reference, from /usr/include/sys/types.h : #if __BSD_VISIBLE typedef unsigned char u_char; typedef unsigned short u_short; typedef unsigned int u_int; typedef unsigned long u_long; #ifndef _KERNEL typedef unsigned short ushort; /* Sys V compatibility */ typedef unsigned int uint; /* Sys V compatibility */ #endif #endif Quoting FreeBSD's man arch: ILP32 int, long, void * types machine representations all have = 4-byte size. LP64 int type machine representation uses 4 bytes, while long = and void * are 8 bytes. armv7 is ILP32, as, likely, i386 would be as well. Note that u_int is 32 bits for both ILP32 and LP64, not 64. But there are a lot of u_int -> uint64_t replacements in the update. > No functional changes intended. It would appear that it would take a bunch of validation to know if the size changes actually make no actual difference on the architectures where some sizes changed. > MFC-after: 1 week > Sponsored-by: The FreeBSD Foundation . . . =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B1344E0F-E41E-4BCD-9A78-5BF8A6B1D6BA>