Message-ID: <8D53104ECD0CD211AF4000A0C9D60AE31E7699@probe-2.Acclaim-Euro.net> From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: RE: ALLEGRO and ANSI C ???? Date: Wed, 7 Oct 1998 10:42:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1460.8) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com ddomingu AT mlg DOT cit DOT alcatel DOT es writes: > Is ALLEGRO 3.0 non ANSI C? Very much so. You will not find any mention of Allegro in the ANSI spec, and it is a very platform/hardware specific library. Sure, the API could be ported to many different environments, but in the interests of efficiency quite a lot of code is inlined directly in the main header file, and there is no way that this could be compiled in strict ANSI compliant mode. It is a nonsense to expect a program to be portable, when it contains several inline asm functions! > True but even so perhaps the header should be parsable in strict > ANSI mode. This allows people to write the rest of their code > portably, apart from the Allegro calls. It'll make it easier to > port to WinAllegro+MSVC, for instance. The -ansi switch isn't really a good way to check your program for portability. If you take a look at: info gcc invoking "c dialect" you will see that this only disables some gcc extensions like the asm and inline keywords, but doesn't check for any of the more significant issues like using nonstandard library functions, or making assumptions that may not hold true across different platforms. Even if you add the -pedantic option, gcc will still miss a lot of significant problems. IMHO it is useless to depend on compiler warnings to make sure that your code is portable. These can only tell you about the most glaringly obvious issues, and such things are trivial to fix in any case because you will get errors as soon as you try to build your program on some other system. The real work in doing a port is to do with things like the size of datatypes, processor endianness, file naming conventions, and specifics of the runtime environment, and that sort of portability can only be achieved through careful programming, rather than just relying on an automated error check... About the -pedantic switch, the gcc info pages make a comment which I think is pretty much spot on: This option is not intended to be useful; it exists only to satisfy pedants who would otherwise claim that GNU CC fails to support the ANSI standard. Some users try to use `-pedantic' to check programs for strict ANSI C conformance. They soon find that it does not do quite what they want: it finds some non-ANSI practices, but not all--only those for which ANSI C *requires* a diagnostic. A feature to report any failure to conform to ANSI C might be useful in some instances, but would require considerable additional work and would be quite different from `-pedantic'. > I think it can be time consuming making it ANSI C compilable by > making a lot of changes in the header and some things may even > be corrupted after the process. Absolutely. In fact I suspect that you could not rewrite this header in straight ANSI C without losing some performance and functionality. Particular things that would cause problems are: - The "extern inline" function qualifier. No, I'm not going to take this out, because it is the only way to reliably inline a function without bloating the resulting executable with multiple copies of the code. - includes and , neither of which are ANSI headers. - The LOCK_VARIABLE() and LOCK_FUNCTION() macros expand into calls to _go32_dpmi_lock_data() and _go32_dpmi_lock_code() respectively. This could be avoided by making them use a helper function in one of the library sources, but it is slightly more efficient to do this directly in the header. - The _set_color() function calls outportb(), directly accessing the VGA palette registers. This cannot be avoided, because the entire purpose of this function is that it will be inlined, so it is safe to use it for doing palette effects within a timer handler. - The bmp_write_line(), bmp_read_line(), _putpixel(), _getpixel(), fadd(), fsub(), fmul(), and fdiv() functions are written in inline asm, which is of course inherently non-portable. Shawn Hargreaves.