nanogui: Nano-X and Ansi-C compliance.
Subject:
Re: Nano-X and Ansi-C compliance.
From:
"Greg Haerr" ####@####.####
Date:
29 Mar 2001 18:24:01 -0000
Message-Id: <05ca01c0b946$05122b60$3aba46a6@xmission.com>
: Firstly there are (quite) a few c++ comments - Please don't do this, it's not
big or cleaver, and is making me cry....
Feel free to submit a patch to get rid of these... I did it once before for the
ELKS compiler, but people keep on using 'em...
:
: More important there are a number of non-ansi compliant function calls and
includes, and I'm not sure on the most portable way to deal with these. My
feeling is that we should aim to have the code 100% ansi-c compliant, so that
someone could pick up compiler xzy (which is Ansi-C) and build straight off.
I think it would be a good idea ot be ansi-c compliant. It shouldn't be that
big
of a deal, with the exception of the #include madness. Please submit patches
for the non-#include stuff, function definitions, etc. I mention a method for
the #include madness below.
: I thought that providing a conversion library (possibly included in libmwin)
where ansi-c functions can be remapped to local functions, or coded up would be
the way to go,
Please discuss which functions you're talking about here. I'm not crazy
about #defining many functions to be other functions. Are you talking
about C lib stuff, or kernel system calls?
: Would the following be OK in the code?
: #ifdef ANSI_C
: #include <time.h>
: #else
: #if (UNIX | DJGPP)
: #include <sys/time.h>
: #endif
: #include "ansiconv.h" /* include platform specific conversions */
: #endif
I have tried hard to keep Microwindows from having 8 lines of stupid
#ifdef stuff when one should work (well, in theory). However, there are
too many cases where exactly the above is needed, and no one will ever
agree/implement on where time.h should live. I don't want to litter
every file with 20 lines of #ifdef's, I've lived for 20 years with C code
like that and I can't stand it anymore. I would suggest instead, that
perhaps all this lives in device.h, which already contains system-specific
#defines and other junk. We could reserve a section of this file that
could handle some of this.
On another note - I would rather use the specific system name from
Arch.rules rather than a general name for the ANSI_C vs DJGPP
ifdefs so that we don't have to create many more preprocessor indentifiers.
This is a complicated subject, and to do it right probably means a lot more
coding. I'm trying to keep Microwindows simple, but it might be worth
it, if we're careful.
Regards,
Greg
