Re: major/minor(3) macros conflict with regular code

[enh <enh%google.com@localhost>]

trying the experiment, we find there's code like this which _does_
work with macros (because major() and minor() are _function-like
macros_) but does not work with static inlines:

u32 erofs_new_encode_dev(dev_t dev)
{
  const unsigned int major = major(dev);
  const unsigned int minor = minor(dev);

  return (minor & 0xff) | (major << 8) | ((minor & ~0xff) << 12);
}

so "move the macros to <sys/sysmacros.h>" might be the least worst
option unless you're prepared to deal with a lot of disruption...

On Fri, Feb 7, 2025 at 11:13 AM enh <enh%google.com@localhost> wrote:
>
> yeah, i've seen this in Android a couple of times (and at least one of
> those was a similar protobuf).
>
> fwiw the "linux" libcs have moved this stuff out into
> <sys/sysmacros.h> where it seems to cause much less trouble (at least
> now we're past the transition period where source had to be updated to
> add the new #include).
>
> Apple still has it in <sys/types.h>, but they choose between macros
> and inline functions based on whether or not you're compiling c++:
>
> #if defined(__cplusplus)
> /*
>  * These lowercase macros tend to match member functions in some C++ code,
>  * so for C++, we must use inline functions instead.
>  */
>
> interestingly, bionic _used_ to use inline functions when i inherited
> it ... but the definitions were wrong, and when i fixed the
> definitions i also switched to macros (seemingly with no motivation
> beyond "that's what everyone else does").
>
> ...which isn't quite true for glibc, where they have inline functions
> with gnu_ prefixes and then macros that forward to the gnu_ names.
> (which seems like the worst of all worlds to me?)
>
> personally i'm quite tempted to change bionic back to inline functions
> (and maybe add `#define major major`/`#define minor minor` if we find
> anyone out there is using #ifdef to check for availability, though
> that would be quite weird given the need to explicitly include
> <sys/sysmacros.h>).
>
> On Fri, Feb 7, 2025 at 3:59 AM Anthony Mallet <anthony.mallet%laas.fr@localhost> wrote:
> >
> > On Thursday  6 Feb 2025, at 18:01, Greg A. Woods wrote:
> > > At Thu, 6 Feb 2025 23:48:48 +0100, Anthony Mallet
> > > <anthony.mallet%laas.fr@localhost> wrote: Subject: major/minor(3) macros
> > > conflict with regular code
> > > >
> > > > Do major(3) and minor(3) really need to be macros?
> > >
> > > What do you mean "need to be"?
> >
> > I meant: they could be static inline functions without breaking
> > anything, I guess?
> >
> > > Perhaps your code doesn't need full native NetBSD system
> > > compatability and so could do without defining _NETBSD_SOURCE --
> >
> > It's actually sys/featuretest.h that defines _NETBSD_SOURCE under the
> > hood, not me :)
> > Indeed, I fixed the build by passing -D_POSIX_C_SOURCE, which should
> > not hurt in this case.
> >
> > > Or fix that code to use more descriptive and thus unique names for
> > > those methods!  :-)
> >
> > Well, the code is just:
> > message Version
> > {
> >   int32 major = 1;
> >   int32 minor = 2;
> > }
> >
> > Then protobuf generates the C++ code that fails. Seems hard to blame
> > in this case. For a global symbol, of course 'major' is a really bad
> > name, but as a method in a class that's more debatable :)
> >
> >
> > On Friday  7 Feb 2025, at 10:44, Robert Elz wrote:
> > > Or just
> > >       #undef major
> > >       #undef minor
> > > between the system #includes and the first mention.
> >
> > Since it's 100% generated code it's not easy (not possible?) to do
> > that, in this case