os.arch should be the architecture of the OS not of the process

[joshwilsdon]

In lib/os.js:

exports.arch = function() {
  return process.arch;
};

Which means that on a system that's running a 64 bit kernel but a 32 bit node binary you get:

> os.arch()
'ia32'

when you would have expected 'x64'.

[bnoordhuis]

You raise a valid point, the problem is that there doesn't seem to be a proper "always correct" fix.

In these troubled times you can have arbitrary combinations of 32 and 64 bits userlands and kernels. Take a system with a 32 bit kernel and a mostly 64 bit userland. How should it be reported? Is it 32 bits or 64 bits? Both? Neither?

Maybe we should scrap os.arch() and process.arch altogether.

[TooTallNate]

process.arch needs to stay, since it is accurate at least (the arch of the current process' executable). Plus it's very important information for node-gyp to have ;)

[bnoordhuis]

Okay, that's a good enough reason for me. Let's keep it the way it is.

[ghost]

The answer for os.arch() is an easy one on windows. And yeah, process.arch is fine but os.arch is pretty useless as is.

[rmustacc]

os.arch() should either refer to the architecture of the underlying Operating System or the list of what is actually supported by the OS, e.g. isainfo on SunOS. Since the latter isn't always knowable, it should probably just describe what the native arch of the kernel is.

[isaacs]

Either it needs to be correct, or removed. Reopening for now.

This can't be changed on a stable branch.

[jasnell]

@isaacs ... have there been any updates on this one?

[jasnell]

Doesn't appear to be a bug. Marking as a feature-request. For backwards compatibility, recommend no changes to the current behavior but it may be worthwhile to add a new process.sysarch() API that always returns the arch of the underlying kernel independently of the process arch.

[Fishrock123]

+1 deprecate os.arch() and add os.sysarch()