nanogui: Nano-X and Ansi-C compliance.
Subject:
Re: Nano-X and Ansi-C compliance.
From:
Jordan Crouse ####@####.####
Date:
29 Mar 2001 15:10:50 -0000
Message-Id: <3AC350F3.1151430B@censoft.com>
It is of course important to fix the various broken bits throughout the
system as they become a problem, but there is absolutely no reason to go
overboard and start
going willy nilly on the code just because there are portions that may
not be ANSI compliant. Errors and warnings I can do without, but it
really doesn't bother me
if somebody chooses to declare a function with no parameters, and
doesn't use void. As the code evolves, the non ANSI compliant code will
go away eventually, and
as far as I am concerned, thats in the best interest of the project. I
have been compiling Microwindows on a ANSI compliant compiler for about
2 months now, and I have encountered only a few minor problems (for
example, nxwidgets are completely broken, but nobody uses them).
I would like to remind you that 90% of the code that you can get at any
one time is not ANSI compliant. In fact, up until real recently, not
even the kernel was ANSI compliant. Your compiler should encourage
folks to make more ANSI compliant code, but at the same time gracefully
handle the non compliant code in the same cheerful manner.
We should endeavor to fix the compilation problems when ever we can, but
I don't know if we should really worry about submitting a 4 MB patch to
Greg that will add a level of complexity that really isn't called for.
Jordan
(And apparently, the word of the day is "compliant" .... :-) )
Simon Wood wrote:
>
> Hello all,
> I'm currently running Microwindows through a 'new' compiler and I'm coming up with a few quirks.
>
> Firstly there are (quite) a few c++ comments - Please don't do this, it's not big or cleaver, and is making me cry....
>
> 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.
>
> But how can we achieve this?
>
> 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, but I can't see how this would help with the standard include calls, for things such as include<time.h>.
>
> 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
>
> Let me know what you guys think. I don't particularly want to waste a lot of time coding if it's no use to others.
>
> Simon Wood
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
