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.mal...@laas.fr> 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.mal...@laas.fr> 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
