[Fwd: Ansification: macros for all the rest]

Tom Leete (tleete@access.mountain.net)
Fri, 09 Jul 1999 10:34:53 +0000


This is a multi-part message in MIME format.
--------------5F985E1DC3E01E38DF0BE580
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------5F985E1DC3E01E38DF0BE580
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3785D005.543AC7DB@access.mountain.net>
Date: Fri, 09 Jul 1999 10:33:41 +0000
From: Tom Leete <tleete@access.mountain.net>
X-Mozilla-Draft-Info: internal/draft; vcard=0; receipt=0; uuencode=0; html=0; linewidth=0
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i486)
X-Accept-Language: en-US,en-GB,en,fr,es,it,de,ru
MIME-Version: 1.0
To: Alan Cox <alan@redhat.com>
Subject: Ansification: macros for all the rest
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello,

Here are the remaining patches for the substitution inline=>__inline__.
I found no case where asm=>__asm__ was needed; the macro form is truly
common practice in the headers.

That's the stupid trivial mechanical part done. I wanted to do it
separately and first, since I assumed it was uncontroversial. We'll see.

>From here on out I need to treat the headers individually, and I'll be
dealing with their maintainers for that. No more bulk mail from me. I'm
also posting the set at my homepage, sparing the kernel list further
attachments. I'll send a copy of this to the list without attachments.

If you please, I'd like to outline my plan for comment.

The goal is to permit user-space developers to use gcc -pedantic or
-ansi as a portability check on their code. This will have the side
effect of permitting user-space developers to use their choice of tools.

The next thing to go at is non-standard gcc extensions. Where these are
needed by the kernel, I hope to be able to contain them in an #ifdef
__KERNEL__ block. Where they are neutral or harmful to the kernel, I'll
consult the maintainer about rewriting them.

I'll save function macros for last. They will provide most of the hard
cases. If they can't be isolated and can be improved by it, I'd like to
change them to inline functions. Some of them may be technically
impossible to change or isolate. That's ok, there's a -Wnowarn- for that
and compilers agree on what they do. I'll consider the project a success
if only these remain.

In no case will I touch *.c files. This is strictly about prototypes for
the exported symbols.

Now I mean to go through the exported ksyms and test compile each
corresponding header with gcc -pedantic. I'll get lots of warnings, and
then I dig in.

Regards,
Tom

"It is wise to resort to exclamations such as 'Help!' 'Hey!' etc."--J.T.

--------------5F985E1DC3E01E38DF0BE580--

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/