Thanks for the reply. On Thu, Sep 25, 2025 at 7:41 AM Collin Funk <[email protected]> wrote:
> Hi Atharva, > > Adding [email protected] to this message so others can comment if they > wish. > > Atharva Tiwari <[email protected]> writes: > > > On Linux, uname -p already reports the correct processor type, but on > macOS > > the mapping was inaccurate. Adjusted preprocessor checks so that arm64, > > i386, and x86_64 are reported correctly, instead of being conflated. > > > > Signed-off-by: Atharva Tiwari <[email protected]> > > --- > > src/uname.c | 8 ++++++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > diff --git a/src/uname.c b/src/uname.c > > index 96c532b94..97e7e742a 100644 > > --- a/src/uname.c > > +++ b/src/uname.c > > @@ -315,10 +315,14 @@ main (int argc, char **argv) > > { > > char const *element = unknown; > > #ifdef __APPLE__ > > -# if defined __arm__ || defined __arm64__ > > +# if defined __arm__ > > element = "arm"; > > -# elif defined __i386__ || defined __x86_64__ > > +# elif defined __arm64__ > > + element = "arm64"; > > +# elif defined __i386__ > > element = "i386"; > > +# elif defined __x86_64__ > > + element = "x86_64"; > > # elif defined __ppc__ || defined __ppc64__ > > element = "powerpc"; > > # endif > > Thanks for the patch, but I do not think that this is correct. > > The rational for the current behavior is documented in this commit > message: > > commit e3d1ff04370b3e090e4cfeb8f6cc4a63590a516f > Author: Paul Eggert <[email protected]> > AuthorDate: Mon Dec 6 14:39:22 2021 -0800 > Commit: Paul Eggert <[email protected]> > CommitDate: Tue Dec 7 14:00:42 2021 -0800 > > uname: port to recent macOS > > Problem reported by Jakub Sokołowski (bug #52330). > * src/uname.c [__APPLE__]: Don’t include sys/syctl.h, > mach/machine.h, mach-o/arch.h. > (print_element_env): New function. With __APPLE__, it defers to the > env var UNAME_MACHINE (if given) for uname -m, and similarly for -nrsv. > (main): Use it. For -p with __APPLE__, rely on predefined macros > and omit any 64-bit indication, for compatibility with macOS uname. > > It appears that the behavior of the 'uname' command used on MacOS has > not changed [1]. > > I wrote a bit about the history of this option somewhere but can't seem > to find it at the moment. It was added in 1996, and appears to have been > an attempt to be compatible with other implementations. > > It is probably just best avoided, to be honest. There are a few open bug > reports about it's behavior on GNU/Linux (and likely many more closed): > > $ uname -p > unknown > > This is because GNU/Linux does not have something like > sysinfo (SI_PLATFORM, ...) like on Solaris [2]. > > On GNU/Linux, one could probably read /proc/cpuinfo and use the "cpu > family", "stepping", etc. to determine if the processor is i386-i686 or > amd64, or just use the CPUID instruction directly [3]. > > But each architecture would have to follow a different process like > that. Therefore, my opinion is that it probably isn't worth the hassle. > > Collin > > [1] > https://github.com/apple-oss-distributions/shell_cmds/blob/b33f386ac431f17d4799b5662f20ff2ddf0773b9/uname/uname.c#L368 > [2] https://docs.oracle.com/cd/E86824_01/html/E54765/sysinfo-2.html > [3] > https://www.scss.tcd.ie/jeremy.jones/CS4021/processor-identification-cpuid-instruction-note.pdf >
