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.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, 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 d62dcae1 for ; Wed, 13 Nov 2019 19:15:46 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id E98039C115; Thu, 14 Nov 2019 05:15:44 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 51CB693D97; Thu, 14 Nov 2019 05:15:18 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 31FEC93D97; Thu, 14 Nov 2019 05:15:17 +1000 (AEST) Received: from smtp-out-4.mxes.net (smtp-out-4.mxes.net [198.205.123.69]) by minnie.tuhs.org (Postfix) with ESMTPS id BD76E93D52 for ; Thu, 14 Nov 2019 05:15:16 +1000 (AEST) Received: from squirrelmail.mxes.net (squirrelmail.mxes.net [198.205.123.113]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPS id 319FC273DD; Wed, 13 Nov 2019 14:15:15 -0500 (EST) Received: from squirrelmail.tuffmail.net (squirrelmail.mxes.net [198.205.123.113]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by squirrelmail.mxes.net (Postfix) with ESMTPSA id 92CBD75AF1; Wed, 13 Nov 2019 14:15:14 -0500 (EST) Message-ID: <055e389cb6a223888c86228963327efc.squirrel@squirrelmail.tuffmail.net> In-Reply-To: <201911131802.xADI2fxE752068@darkstar.fourwinds.com> References: <1573592179.5935.for-standards-violators@oclsc.org> <201911130735.xAD7ZQD6014497@freefriends.org> <201911131802.xADI2fxE752068@darkstar.fourwinds.com> Date: Wed, 13 Nov 2019 14:15:14 -0500 From: ron@ronnatalie.com To: "Jon Steinhart" MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Sent-To: Subject: [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: tuhs@tuhs.org Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" > > 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 b= it > of help. Here's something that I came across on the way in : > > enum > { > MS_RDONLY =3D 1, /* Mount read-only. */ > #define MS_RDONLY MS_RDONLY > MS_NOSUID =3D 2, /* Ignore suid and sgid bits. */ > #define MS_NOSUID MS_NOSUID > MS_NODEV =3D 4, /* Disallow access to device special files. */ > #define MS_NODEV MS_NODEV > ... > }; > > Can anyone explain the value of this programming style? Is this just a= n > 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. = =20 The #define is just probably backwards a compatibility kludge (for peopl= e using things like MS_RDONLY or whatever in other macros).