>On Sat, 23 Jan 1999, Alistair Riddoch wrote:
>
>> I am exagerating a bit. The main problem was that it generated so many
>> errors that I could not get it to tell me anything useful.
>
>You'll probably find that most of these errors are the fault of
>prototyping, or some other simple problem. You may even find that fixing
>the first error removes 100 more.
>
>Davey
>
I'm a little new to this project, but here's what I think
The ELKS project source code should be kept as clean as possible, of course.
Running lint is a good idea, but the source also should be regularly
compiled (not
necessarily run, just compiled) using a sophisticated error-checking
compiler
like gcc on occasion (built into makes is relatively easy). But - in order
to get all that neat type checking etc, the source needs to be in ANSI
declaration
format. Ansi compilers won't perform type checking if function prototypes
aren't used.
In this way gcc checks all sorts of neat stuff, and bcc can use it's -ansi
option
to run unproto on the source for the real ELKS make.
However, this is only the beginning. The real answer is that bcc needs to
become
an ANSI compiler. A tall order maybe, but, I've already started in this
direction.
The real reason for this is that I'm personally interested in small,
self-hosted systems
that include OS, Compilers, linkers and libraries that can self-replicate
themselves...
Anyway, back to the subject. I see bcc moving to ansi in two steps. First
step
is to get it to compile 100% ansi compliant source input without
complaining. The second
step is to get it to perform type-checking and implement the new ansi
features.
So, I've debugged bcc's TESTING_PROTOTYPES code and got it to accept ansi
compliant function definitions. I've also fixed the macro preprocessing for
closer ansi-compliance.
I've added #elif and #error, etc. To check the compiler, I've ported bcc,
as86 and ld86 to
a test MINIX 2.0 system that I've put up, and am currently recompiling
minix's libc routines,
which all use ansi. Currently, I'm working on const and typedef'd function
declarations.
I'll be checking all this in to Rob de Bath when I'm done, and of course
will check that ELKS
still works.
So, I think we should use these compiler changes to allow the ELKS source to
move
to an ansi-compliant status, become checked, while we continue to build our
tools, etc.
Does anyone want to help "proto-izing" elks?
Greg Haerr
[EMAIL PROTECTED]
>
