Date: Mon, 21 Oct 2002 16:45:56 +0200 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: Mike Barcroft <mike@FreeBSD.org> Cc: Bruce Evans <bde@zeta.org.au>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/isa npx.c Message-ID: <2782.1035211556@critter.freebsd.dk> In-Reply-To: Your message of "Mon, 21 Oct 2002 10:01:36 EDT." <20021021100136.B80691@espresso.q9media.com>
index | next in thread | previous in thread | raw e-mail
In message <20021021100136.B80691@espresso.q9media.com>, Mike Barcroft writes:
>Yes, but this is the second time ever "lint" has been used in a
>standard header or in a header a standard header includes. The first
>was in <sys/cdefs.h> about a month ago, but since it only modifies
>macros in the implementation namespace it isn't a problem.
>
>It might be a wise idea to do a mass rename (similar to the KERNEL to
>_KERNEL mass rename of 1999).
Well, that might be excessive.
I suspect the vast majority of the "#ifdef lint" are the copyright/version
strings:
#ifndef lint
static char const copyright[] =
"@(#) Copyright (c) 1989, 1993\n\
The Regents of the University of California. All rights reserved.\n";
#endif /* not lint */
And also, while I'll admit that various standards may think of "lint" as
a unreserved word in C language, various greps I've performed shows that
this is actually not the case: "lint" is very much an reserved word.
See our very own lint(1) for instance:
[...] The lint
utility runs the C preprocessor as its first phase, with the preprocessor
symbol ``lint'' defined to allow certain questionable code to be altered
or skipped by lint. Therefore, this symbol should be thought of as a
reserved word for all code that is to be checked by lint.
Considering the history of the "lint" symbol, I think we should
just declare ANSI and/or POSIX in error here and treat "lint" as
what it is: A well-defined reserved word.
I can personally live with any particular symbol we chose...
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2782.1035211556>