: I am not quite sure whether this is the best way to proceed. It would make
: ELKS easier to find bugs in, but the -ansi option to bcc is not a very
: clean solution to wanting to convert the code to ANSI. The other thing is
: that it may make it harder to build the code natively under ELKS.
There's no question that it would help with bugs significantly.
However, there is currently a problem getting native ELKS compilation going.
Currently, I've got bcc running under ELKS, but it's got problems. There's
also < 512 bytes left in the code segment, and that's using the special
compilation model, -Mf. Also, unproto is not currently ported. My first look
at it confirmed it'd be a little work, and I skipped it. BTW, copt also
isn't ported, and is work, so even without -ansi we've got work to do to
self-compile ELKS.
Another idea is that we could have a makefile pre-processor
pass that would run unproto on all the source and create another entire
tree that is K&R compatible. With this scheme, the master source would
always be kept in ansi, but anybody could make a K&R tree if they have
a linux box. I think we should consider this idea highly.
: If we can be fairly sure that compiling ELKS with -ansi does not have any
: significant downside, and we can run bcc natively under ELKS with ansi
: support included, then I think this is the right way to go, but it needs to
: be properly discussed before we make the decision.
ELKS has enough bugs currently that it's probably worth keeping
it check with a real ansi compiler.
:
Comments?
Greg
