[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