From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id e353bb06 for ; Wed, 13 Nov 2019 21:12:15 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 2B9399C133; Thu, 14 Nov 2019 07:12:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 16BBE93D97; Thu, 14 Nov 2019 07:11:36 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=bsdimp-com.20150623.gappssmtp.com header.i=@bsdimp-com.20150623.gappssmtp.com header.b="Z1v+H+2Z"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1FF7593D97; Thu, 14 Nov 2019 07:11:34 +1000 (AEST) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) by minnie.tuhs.org (Postfix) with ESMTPS id 4961793D52 for ; Thu, 14 Nov 2019 07:11:33 +1000 (AEST) Received: by mail-qt1-f171.google.com with SMTP id o3so4215320qtj.8 for ; Wed, 13 Nov 2019 13:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Og6rgn4K+x6V3k2l5QHg2YPfwuzUlRM1x0fOXOn9EVc=; b=Z1v+H+2ZlHYHbX66wLJO7DVGltIr0ILjLXjECdSiXK2zjgR4+7DxoDYSZ1b+ZUoNe+ E4pDTAXkepkwNOcQxHPMZEnfoY8CA1b+4TB7xUq5gocnAdC/DZezdjiUGZtS8oAxl9nk 5DqRa5Li8Zk9PDRZmduXr7Rf4ZgJ3Mgn1TctCNs8cwCpggG6caHgFDvhJF9B+a1DkXaO KZ6fQvpD2oD36yzfZwn9MudAKcIXH8HveASuSXSbORlR6oQKE4nUvvhEXa3DUctnbgNQ aUbpsXzjW11kcDfszud+1VFU9Lo5iUWSlMq4JCb2yTiiL1uYJUI84LlefwG64lAsnJsj r2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Og6rgn4K+x6V3k2l5QHg2YPfwuzUlRM1x0fOXOn9EVc=; b=taSzZN/2HXnEF0Ger8jVCocgF9KCBHZ/9hDIZRc7PUmUSzFiBYL1fTvQ0C5cymaMXE SGG/24W7xSxxjEX0ibZzirhB1fZ3+Mz7f0N/rCxQrg4GLAhPfX7QkIBA7X/h4AE4paRh PfHrbUz5+87el/ra0PzfFtSReBvaTcQrTFL/2SxXMcvB3NKOMn06Qpzjwuh6F7tjkaAO Hezl+p4C/rbyXzCVoYt2CXcgYITBBma0z5uW6PzbiVGiWOKdOpCwjUNoGjHavWmmbUWZ N1GpnX55bYVDWqj2LyBkE3gWuPAx9EM5JLO2mg83v951OumvenkjbE7ieA1/0tmLMqE5 mc5A== X-Gm-Message-State: APjAAAUJsLO9dsoT9idexm8geBR24hExIsC5Vq8KSpD+x7iHZZ4pTfna mnSuBDE+/3R0MdYz8WvSJkY13gtroA/voozxVNuUViK4cvs= X-Google-Smtp-Source: APXvYqwDXuDKlmybQHjJLbilC8bCVSFm8mN96+r/FLvBuzhJ9VgZKlUWAo/v3ELPO+U+stbZ7iy6Of/M3ikMeMZf4Gs= X-Received: by 2002:ac8:754c:: with SMTP id b12mr4835925qtr.291.1573679492125; Wed, 13 Nov 2019 13:11:32 -0800 (PST) MIME-Version: 1.0 References: <1573592179.5935.for-standards-violators@oclsc.org> <201911130735.xAD7ZQD6014497@freefriends.org> <201911131802.xADI2fxE752068@darkstar.fourwinds.com> <055e389cb6a223888c86228963327efc.squirrel@squirrelmail.tuffmail.net> In-Reply-To: <055e389cb6a223888c86228963327efc.squirrel@squirrelmail.tuffmail.net> From: Warner Losh Date: Wed, 13 Nov 2019 14:11:19 -0700 Message-ID: To: Ronald Natalie Content-Type: multipart/alternative; boundary="0000000000001e6a5a059740cf5c" Subject: Re: [TUHS] #defines and enums X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000001e6a5a059740cf5c Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019, 12:15 PM wrote: > > > > > BTW, I'm doing my first messing around with the Linux kernel these days; > > if anyone knows the guts of the generic filesystem code I could use a bit > > of help. Here's something that I came across on the way in > : > > > > enum > > { > > MS_RDONLY = 1, /* Mount read-only. */ > > #define MS_RDONLY MS_RDONLY > > MS_NOSUID = 2, /* Ignore suid and sgid bits. */ > > #define MS_NOSUID MS_NOSUID > > MS_NODEV = 4, /* Disallow access to device > special files. */ > > #define MS_NODEV MS_NODEV > > ... > > }; > > > > Can anyone explain the value of this programming style? Is this just an > > example of the result of how programming is taught today? > > > > > > This really is more a C question than a UNIX one. The problem is that > the preprocessor macros are really kind of a kludge. Making things > either enums (or in later C/C++ const int definitions) is a lot cleaner. > The #define is just probably backwards a compatibility kludge (for people > using things like MS_RDONLY or whatever in other macros). > It lets the users of these interfaces conditionally use them as ifdef. A pure enum interface doesn't let you do that. This makes it harder to write portable code that is driven directly by what is defined. While it seems purer to use enum, it is problematic. C++ doesn't let you use it for bit fields due to special rules around enums that aren't there to get in the way in C. Conditional code is important, as are providing enough compat scaffolding when sharing code between many systems, or when different compilers are used. Macro processing accomplishes this rather well, though not without other issues. In an ideal world, you could put other constructs into the language to accomplish these goals... But none that have been good enough to gain any traction at all.... Warner > --0000000000001e6a5a059740cf5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 13, 2019, 12:15 PM <ron@ronnatalie.com> wrote:

>
> BTW, I'm doing my first messing around with the Linux kernel these= days;
> if anyone knows the guts of the generic filesystem code I could use a = bit
> of help.=C2=A0 Here's something that I came across on the way in &= lt;sys/mount.h>:
>
> enum
> {
>=C2=A0 =C2=A0MS_RDONLY =3D 1,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 /* Mount read-only.=C2=A0 */
> #define MS_RDONLY=C2=A0 =C2=A0 =C2=A0MS_RDONLY
>=C2=A0 =C2=A0MS_NOSUID =3D 2,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 /* Ignore suid and sgid bits.=C2=A0 */
> #define MS_NOSUID=C2=A0 =C2=A0 =C2=A0MS_NOSUID
>=C2=A0 =C2=A0MS_NODEV =3D 4,=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* Disallow access to device speci= al files.=C2=A0 */
> #define MS_NODEV=C2=A0 =C2=A0 =C2=A0 MS_NODEV
> ...
> };
>
> Can anyone explain the value of this programming style?=C2=A0 Is this = just an
> example of the result of how programming is taught today?
>
>

This really is more a C question than a UNIX one.=C2=A0 =C2=A0 The problem = is that
the preprocessor macros are really kind of a kludge.=C2=A0 =C2=A0Making thi= ngs
either enums (or in later C/C++ const int definitions) is a lot cleaner.=C2= =A0
=C2=A0The #define is just probably backwards a compatibility kludge (for pe= ople
using things like MS_RDONLY or whatever in other macros).
<= /div>

It lets the users = of these interfaces conditionally use them as ifdef. A pure enum interface = doesn't let you do that. This makes it harder to write portable code th= at is driven directly by what is defined.

=
While it seems purer to use enum, it is problematic. C++ = doesn't let you use it for bit fields due to special rules around enums= that aren't there to get in the way in C.

<= /div>
Conditional code is important, as are providing enou= gh compat scaffolding when sharing code between many systems, or when diffe= rent compilers are used. Macro processing accomplishes this rather well, th= ough not without other issues. In an ideal world, you could put other const= ructs into the language to accomplish these goals... But none that have bee= n good enough to gain any traction at all....

Warner
--0000000000001e6a5a059740cf5c--