* Re: [TUHS] #defines and enums
@ 2019-11-14 1:35 Larry McVoy
0 siblings, 0 replies; 3+ messages in thread
From: Larry McVoy @ 2019-11-14 1:35 UTC (permalink / raw)
To: tuhs
FYI.
----- Forwarded message from Linus Torvalds <torvalds@linux-foundation.org> -----
Date: Wed, 13 Nov 2019 12:37:50 -0800
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Larry McVoy <lm@mcvoy.com>
Subject: Re: enum style?
On Wed, Nov 13, 2019 at 10:28 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> and asked what was the point of the #defines. I couldn't answer, the only
> thing I can think of is so you can say
>
> int flags = MS_RDONLY;
>
> Which is cool, but why bother with the enum?
For the kernel we actually have this special "type-safe enum" checker
thing, which warns about assigning one enum type to another.
It's not really C, but it's close. It's the same tool we use for some
other kernel-specific type checking (user pointers vs kernel pointers
etc): 'sparse'.
http://man7.org/linux/man-pages/man1/sparse.1.html
and in particular the "-Wenum-mismatch" flag to enable that warning
when you assign an enum to another enum.
It's quite useful for verifying that you pass the right kind of enum
to functions etc - which is a really easy mistake to make in C, since
they all just devolve into 'int' when they are used.
However, we don't use it for the MS_xyz flag: those are just plain
#define's in the kernel. But maybe somebody at some point wanted to do
something similar for the ones you point at?
The only other reason I can think of is that somebody really wanted to
use an enum for namespace reasons, and then noticed that other people
had used a #define and used "#ifdef XYZ" to check whether it was
available, and then instead of changing the enums to #defines, they
just added the self-defines.
In the kernel we do that "use #define for discoberability" quite a lot
particularly with architecture-specific helper functions. So you migth
have
static inline some_arch_fn(..) ...
#define some_arch_fn some_arch_fn
in an architecture file, and then in generic code we have
#ifndef some_arch_fn
static inline some_arch_fn(.,,) /* generic implemenbtation goes here */
#endif
as a way to avoid extra configuration variables for the "do I have a
special version X?"
There's no way to ask "is the C symbol X available in this scope", so
using the pre-processor for that is as close as you can get.
Linus
----- End forwarded message -----
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [TUHS] Happy birthday Morris worm
@ 2019-11-12 20:56 Norman Wilson
2019-11-13 7:35 ` arnold
0 siblings, 1 reply; 3+ messages in thread
From: Norman Wilson @ 2019-11-12 20:56 UTC (permalink / raw)
To: tuhs
I think I recall an explicit statement somewhere from an
interview with Robert that the worm was inspired partly
by Shockwave Rider.
I confess my immediate reaction to the worm was uncontrollable
laughter. I was out of town when it happened, so I first
heard it from a newspaper article (and wasn't caught up in
fighting it or I'd have laughed a lot less, of course); and
it seemed to me hilarious when I read that Robert was behind
it. He had interned with 1127 for a few summers while I was
there, so I knew him as very bright but often a bit careless
about details; that seemed an exact match for the worm.
My longer-term reaction was to completely drop my sloppy
old habit (common in those days not just in my code but in
that of many others) of ignoring possible buffer overflows.
I find it mind-boggling that people still make that mistake;
it has been literal decades since the lesson was rubbed in
our community's collective noses. I am very disappointed
that programming education seems not to care enough about
this sort of thing, even today.
Norman Wilson
Toronto ON
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [TUHS] Happy birthday Morris worm
2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
@ 2019-11-13 7:35 ` arnold
2019-11-13 18:02 ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
0 siblings, 1 reply; 3+ messages in thread
From: arnold @ 2019-11-13 7:35 UTC (permalink / raw)
To: tuhs, norman
Norman Wilson <norman@oclsc.org> wrote:
> I am very disappointed that programming education seems not to care
> enough about this sort of thing, even today.
I think this is the key. Universities focus (too much?) on the theory
and not enough on the practice, and "learn how to program" courses
and books focus on the mechanics (syntax, semantics) and not enough
(or at all) on the practicum of writing code well.
We continue to rely on the school of hard knocks, and we continue
to pay for this reliance.
I also think there's a sliding scale. The fancier or higher-end
the university, the more the focus on theory, and vice versa. Sigh.
Arnold
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [TUHS] Happy birthday Morris worm [ really programming education ]
2019-11-13 7:35 ` arnold
@ 2019-11-13 18:02 ` Jon Steinhart
2019-11-13 19:15 ` [TUHS] #defines and enums ron
0 siblings, 1 reply; 3+ messages in thread
From: Jon Steinhart @ 2019-11-13 18:02 UTC (permalink / raw)
To: tuhs
arnold@skeeve.com writes:
> Norman Wilson <norman@oclsc.org> wrote:
>
> > I am very disappointed that programming education seems not to care
> > enough about this sort of thing, even today.
>
> I think this is the key. Universities focus (too much?) on the theory
> and not enough on the practice, and "learn how to program" courses
> and books focus on the mechanics (syntax, semantics) and not enough
> (or at all) on the practicum of writing code well.
>
> We continue to rely on the school of hard knocks, and we continue
> to pay for this reliance.
>
> I also think there's a sliding scale. The fancier or higher-end
> the university, the more the focus on theory, and vice versa. Sigh.
>
> Arnold
OK, this is a bit of a tangential topic for this list. But, what's the
point of obsessing on UNIX history unless it's coupled with some effort
to communicate the philosophy to a new generation of programmers?
This has been a real concern of mine for a while. As a friend of mine
put it, processors are getting so cheap that pretty soon we won't be
able to purchase pencils that don't contain them. This puts us all
at the mercy of not-great programmers. And of course, it's not just
pencils, it's stuff like airplanes too.
In my opinion, the root of the problem is that programming today is
being taught in the abstract - as if programs don't run on computers.
Programming today is taught as if it consists of importing libraries
and gluing function calls together.
I recently visited my daughter's college and attended a number of CS
related presentations. Was surprised that CS is taught in Java with
some advanced work in Python. One can almost get a CS degree there
without ever using a compiler much less learning how computers function.
Too be fair, other schools such as Dartmouth where Doug hangs out have
a better curriculum.
At the K-12 level, the stage is set by combination of the "everybody
must learn to code" curriculum with "no child left behind". School
administrators dispense with any critical thinking about the value of
the curriculum in order to chase grant dollars.
I used to be able to get into my local schools to volunteer-teach
programming. But, the learn to code curriculum has eclipsed that;
schools are led to believe that they're teaching the right stuff
(because Bill Gates says so) and aren't interested in anything else.
I recently turned my course notes into a book as an attempt to make
some small difference. Too soon to tell if it will.
Anyway, my question for you all is, how do we as seasoned practitioners
leverage our experience to contribute to the state of the art? Any of
you found a way to pass on your knowledge?
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 <sys/mount.h>:
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?
Be happy discuss this off-list.
Jon
^ permalink raw reply [flat|nested] 3+ messages in thread
* [TUHS] #defines and enums
2019-11-13 18:02 ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
@ 2019-11-13 19:15 ` ron
2019-11-13 21:11 ` Warner Losh
0 siblings, 1 reply; 3+ messages in thread
From: ron @ 2019-11-13 19:15 UTC (permalink / raw)
To: Jon Steinhart; +Cc: 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 bit
> of help. Here's something that I came across on the way in <sys/mount.h>:
>
> 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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [TUHS] #defines and enums
2019-11-13 19:15 ` [TUHS] #defines and enums ron
@ 2019-11-13 21:11 ` Warner Losh
0 siblings, 0 replies; 3+ messages in thread
From: Warner Losh @ 2019-11-13 21:11 UTC (permalink / raw)
To: Ronald Natalie; +Cc: The Eunuchs Hysterical Society
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
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. Here's something that I came across on the way in
> <sys/mount.h>:
> >
> > 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
>
[-- Attachment #2: Type: text/html, Size: 2805 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-11-14 1:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-14 1:35 [TUHS] #defines and enums Larry McVoy
-- strict thread matches above, loose matches on Subject: below --
2019-11-12 20:56 [TUHS] Happy birthday Morris worm Norman Wilson
2019-11-13 7:35 ` arnold
2019-11-13 18:02 ` [TUHS] Happy birthday Morris worm [ really programming education ] Jon Steinhart
2019-11-13 19:15 ` [TUHS] #defines and enums ron
2019-11-13 21:11 ` Warner Losh
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).