proposed changes to eliminate P macro

[Ken Pizzini]

On Thu, Nov 15, 2007 at 03:47:27PM +0700, Robert Elz wrote:
>   |   * use angle brackets <> instead of double-quotes for system #include-s,
>   |     for the benefit of any compiler that handles those more efficiently
>   |     (e.g., support of pre-compiled system headers)
> 
> The change you're doing there should be OK, but the rationale you give
> makes no sense to me ... all <> ever did in C was to skip the default
> search of the current directory for the file to include - but if -I.
> is given, that comes back again - there's no real distinction (in the
> syntax of the #include) between "system" and other include files.
> If the compiler wants to support pre-"compiled" include files, it needs
> some other mechanism to recognise them than the <> vs "" in the .c file.

What you describe is the traditional Unix interpretation.
And perhaps I'm misremembering and it was C++ only,
but I *do* recall that at least one of the two language standard
*does* explicitly state that the <> notation for include files
allows the language implementation (compiler) to use built-in
(even beyond "precompiled") headers for the <> notation.

That said, I have never actually worked with a compiler that did this;
I just make it a habit to use <> when I want the system headers and ""
when I want the application headers, for both the above-stated
rationale and just to be clear about my intent.



> That is, don't make changes just for the sake of changing things, even if
> it is strictly OK to do that, and even if you wouldn't bother to do it the
> old way if you were writing the code today - there needs to be some positive
> benefit to the change to justify all the work everyone else is going to need
> to do looking over the diffs from the last version before integrating the
> updated code into the many distributions that use it.

I understand your point here, but here's my view:  even "dead" code has
a cost in maintenance and comprehension.  Note my follow-up correction
for the prototype fix to the logwtmp() code, for example.  If 99% of the
time the strerror() code is ignored, then it will suffer bit-rot.  When
scanning the source, one must skip over it.  Granted, ignoring the
function while reading the code is a low-cost operation, but still,
given that it was the standardization process that lead to C *89* that
both created function prototypes and mandated the strerror() function
(and effectively deprecated the sys_errlist[] array that the
locally-defined strerror() function relies on), it seemed worth the
one-time cost of eliminating it during this "let's modernize and
clean-up the code" project.

That said, I'm not adamant that strerror() and isascii() be removed.
It is my opinion that they should be removed, but beyond offering the
patch and explaining why I think they should go, I really don't care
whether they stay in or not.


I probably should have split out my proposed changes into a set of more
focused patches, rather than bundling them all up at once, to both
simplify review and discussion.  Sorry about that: I just got a bit
carried away during my edit session and swatted at several ancillary
gnats that happened to be in my path while I was busy with the primary
task of ensuring that all functions used prototype in their declarations
and definitions.  I *did* back off from including some larger change
sets, like the deletion of register annotations (which, based on recent
discussion I'll probably not submit), and I am sitting on some clean-ups
to castings (not necessarily the same ones you're looking at) until the
dust settles on the current round of patches.


Oh, and while I'm extemporising on my opinions, I'd like to make an
additional comment about the use of "register" in the code: either
we should eliminate it altogether, or we need to make a pass through
the code to *add* "register" in all the places that it is currently
missing.  There are many variables that are not declared "register"
that could be.  My personal preference is to simply remove "register"
everywhere, but if we're going to use it to prevent accidental use
of "&" on the wrong variable, we should be consistent about it and
use it on every variable that it can be applied to.

		--Ken Pizzini