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 > > I have some code that defines these methods in a C++ class: > int32_t major() const > int32_t minor() const > (for the context: this is in protobuf generated code from a message > that has major/minor fields). > > The generated code fails to compile because it conflicts with major(3) > macro and minor(3) macros from sys/types.h: > > #define major(x) ((devmajor_t)(((uint32_t)(x) & 0x000fff00) >> 8)) > #define minor(x) ... > > Do major(3) and minor(3) really need to be macros? What do you mean "need to be"? They've been macros in every Unix since approximately forever, at least in Unix terms, since the Epoch, or at least 7th Edition. :-) Perhaps your code doesn't need full native NetBSD system compatability and so could do without defining _NETBSD_SOURCE -- maybe define _POSIX_C_SOURCE instead (which explicitly then tells the system headers to _not_ define _NETBSD_SOURCE, and that will hide those macros). Or fix that code to use more descriptive and thus unique names for those methods! :-) -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpBIFok1GhDd.pgp
Description: OpenPGP Digital Signature