a2c and language standards
Ken Raeburn
As far as I know, C compilers that don't accept "//" for comments are
not all that uncommon, for people not using GCC or Windows. The C99
spec adds support for "//" comments, but C90 does not. Much of the
a2c C code uses "//" for comments; "/*...*/" would be better, unless
you want to require C99, or at least some C99 features (which should
be spelled out clearly somewhere).
The function-pointer casting bothers me a bit, but I'm something of a
purist. Strictly speaking, the code is wrong, because different
pointer types don't have to be passed the same way, so the function
signature seen by the compiler at the call site being different from
that of the real function could cause errors; it would be cleaner
(and more correct) to pass void* (or whatever) and do the conversion
in the called functions. The way the code is set up, are you getting
much type-checking benefit from using types in the signatures of
internal functions anyways?
Also, the use of A2C_Alloc as described in README is likely to get
compiler warnings (confirmed under GCC), because for example "IntH
**" isn't assignment-compatible with "void **".
In terms of modern, real-world, general-purpose computers, I'm not
aware of any system where these will actually break things. However,
compilers are getting smarter all the time, and sometimes they
include code (the type-aware alias analysis in GCC, for example) that
"knows" that correct code won't violate the standard in certain ways,
and for non-compliant code may produce results different from what
the author intended, sometimes in subtle or surprising ways. So if
they don't break today, they may still break tomorrow.
With A2C_System.h including string.h, is memory.h needed too? Are
there any remotely modern systems that do something useful in
memory.h that string.h doesn't cover? Anything useful if your code
isn't relying on non-portable extensions?
I think the naming scheme for SEQUENCE OF SEQUENCE { ... }, using
"__" as a separator, is, strictly speaking, incompatible with using
the header file from C++ code, as all such names are reserved for the
implementation (ISO/IEC 14882:1998 section 17.4.3.1.2).
(Technically, I think the same is true of the "_A2C" prefixes in C --
ISO/IEC 9899:1999, 7.1.3.) The use of "__" may conflict with the
name mangling scheme used for function name encoding. I don't have
any great ideas for fixing it, and I suspect it won't matter on most
systems, but it's a good idea to be aware of it....
Ken