nanogui: Thread: Nano-X and Ansi-C compliance.

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

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: ####@####.####

: 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