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
