[TUHS] v7 K&R C
Larry McVoy
lm at mcvoy.com
Tue May 12 04:37:20 AEST 2020
On Mon, May 11, 2020 at 02:25:15PM -0400, Paul Winalski wrote:
> On 5/11/20, Greg A. Woods <woods at robohack.ca> wrote:
> >
> > 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.)
>
> I would add a third: file-scope declarations being global by default.
> One must use the keyword "static" to restrict a file-scope declaration
> to the file it's declared in. And why "static"? All file-scope
I never cared for "static" either, seemed weird. All my code is
#define private static
private int
super_duper(void)
{
...
}
and everyone knows what that means at a glance.
> declarations have static allocation. Why isn't the keyword "local" or
> "own"? Anyway, the way it ought to be is that file-scope declarations
> are restricted to the file they're declared in. To make the symbol
> visible outside its file, you should have to explicitly say "global".
>
> > 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.
>
> This ought to be easy to fix using a compiler command line option for
> the legacy behavior. Many C compilers do this already to support K&R
> semantics vs. standard C semantics.
>
> > Ideally enums could be a value in any native type, including float/double.
>
> Except pointers, of course.
>
> >> 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.
>
> Indeed.
>
> -Paul W.
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
More information about the TUHS
mailing list