Re: port-i386/59402 (Inconsistently-guarded macro definitions in ptrace.h header files)

[riastradh%NetBSD.org@localhost]

Synopsis: Inconsistently-guarded macro definitions in ptrace.h header files

State-Changed-From-To: open->feedback
State-Changed-By: riastradh%NetBSD.org@localhost
State-Changed-When: Tue, 06 May 2025 23:44:57 +0000
State-Changed-Why:
I assume you're referring to something like this build failure?

https://releng.netbsd.org/pkgreports/shadow/2025Q1/NetBSD-10.0-i386/20250503.1720/lsof-4.91nb7/build.log

--- dstore.o ---
In file included from dlsof.h:382,
                 from lsof.h:221,
                 from dstore.c:39:
/usr/include/miscfs/procfs/procfs.h:120:2: error: expected ',' or '}' before 'PFSlast'
  120 |  PFSlast, /* track number of types */
      |  ^~~~~~~

arising from:

     77 #ifdef _KERNEL
...
     83 typedef enum {
     84 	PFSauxv,	/* ELF Auxiliary Vector */
...
    129 	PFSversion,	/* kernel version (if -o linux) */
    130 #ifdef __HAVE_PROCFS_MACHDEP
 => 131 	PROCFS_MACHDEP_NODE_TYPES
    132 #endif
    133 	PFSlast,	/* track number of types */
    134 } pfstype;

https://nxr.netbsd.org/xref/src/sys/miscfs/procfs/procfs.h?r=1.87#77

Presumably this happens because PROCFS_MACHDEP_NODE_TYPES is not
defined as a macro, so the C compiler thinks it's another enumerand,
and expects a comma between it and PFSlast.

But how can you get to to line 131, which is conditional on both
_KERNEL and __HAVE_PROCFS_MACHDEP, without also getting to the line
that defines PROCFS_MACHDEP_NODE_TYPES, which is conditional only on
_KERNEL and __HAVE_PROCFS_MACHDEP (and !_I386_PTRACE_H_, I suppose)?

     83 /* We have machine-dependent procfs nodes. */
     84 #define	__HAVE_PROCFS_MACHDEP
...
    125 #ifdef _KERNEL
...
    139 #define	PROCFS_MACHDEP_NODE_TYPES					\
    140 	Pmachdep_xmmregs,	/* extended FP register set */

https://nxr.netbsd.org/xref/src/sys/arch/i386/include/ptrace.h?r=1.27#83

The change you suggest is fine -- should be harmless, and it's more
consistent with the other uses -- but it also shouldn't really be
necessary (__FOO namespace is reserved to us, the implementation, so
users who rummage around where they don't belong get their just
desserts) and I'd like to better understand how sysutils/lsof has dug
itself into this hole.

Does it maybe do something really stupid like this?

#include <sys/ptrace.h>

#define _KERNEL
#include <miscfs/procfs/procfs.h>
#undef _KERNEL

That's apt to cause all kinds of havoc...  I'm also hesitant to ask
what lsof hopes to accomplish by defining _KERNEL at all (and not, say,
_KMEMUSER or _KERNTYPES) other than shooting itself in the foot.