[TUHS] v7 K&R C

[Greg A. Woods]

At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy <lm at mcvoy.com> wrote:
Subject: Re: [TUHS] v7 K&R C
>
> > On Mon, May 11, 2020 at 10:28 AM <scj at yaccman.com> wrote:
> > > With respect to enums, there is a feature I've wanted for years: a typed
> > > typedef.  Saying typetdef int foo would make foo an integer, but if you
> > > passed an ordinary int to something declared as foo it would be an error.
> > > Even if it was an integer constant unless cast.
>
> Steve, I couldn't agree more, you are 100% right, this is how it should
> work.  I wanted to like enums because I naively thought they'd have these
> semantics but then learned they really aren't any different than a well
> managed list of #defines.

Absolutely agreed!

The lameness of typedef (and in how enum is related to typedef) is one
of the saddest parts of C.  (The other is the default promotion to int.)

It would be trivial to fix too -- for a "new" C, that is.  Making it
backward compatible for legacy code would be tough, even with tooling to
help fix the worst issues.  I've seen far too much code that would be
hard to fix by hand, e.g. some that even goes so far as to assume things
like arithmetic on enum values will produce other valid enum values.

Ideally enums could be a value in any native type, including float/double.

> IMHO, without your semantics, enums are pretty useless, #define is good
> enough and more clear.

Actually that's no longer true with a good modern toolchain, especially
with respect to the debugger.  A good debugger can now show the enum
symbol for a (matching) value of a properly typedefed variable.

(In fact I never thouth that a #define macro was more clear, even before
debugger support -- the debugger support just gave me a better excuse to
use to explain my preference!)

--
					Greg A. Woods <gwoods at acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>     Avoncote Farms <woods at avoncote.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP Digital Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200511/d6e7cb7d/attachment.sig>