Mail Archives: djgpp/1998/10/07/05:45:37
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.
- <allegro.h> includes <dpmi.h> and <pc.h>, 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.
- Raw text -