Re: [cc65] Problems with va_copy

Hi!

On Sun, Dec 11, 2005 at 02:26:42PM +0100, Spiro Trikaliotis wrote:
> Oh, this was the reason for <dnc8md$8j3$1@moppi.musoftware.de>?

Yes.

> This is true. Anyway, I ask if it would not be better to use some other
> approach:
>
> 1. Define some function/macro/whatever called "my_va_copy()"
>
> 2. Let some script (./configure comes to find) try to determine if
>    va_copy() is available and working on your compiler. If so, let
>    my_va_copy() call va_copy(). If not, let my_va_copy() be your own
>    implementation.
>
> BTW: autoconf helps very much here!

I'm no friend of autoconf, because it is just a way of #ifdef management. It
encourages people to write unportable programs, by supplying an automated way
to manage all the needed #ifdefs. Apart from that, autoconf is not available
on all platforms, and there are many operating systems that don't have it by
default (which means it has to be compiled and installed). I've seen programs
that use autoconf for *nix, custom makefiles for Windows, and manual #ifdef
management for all others (like OS/2, Amiga, ...) and in my eyes it's a
nightmare. As long as I can make my programs portable by adhering to the
standard, this is definitely the better way.

Using my own script to figure out, if va_copy is supported, is not much
better. I would have to make sure that this script/program will compile and
run on all platforms. I cannot use perl, because Windows and others don't have
it. I cannot use a shell script either. So I have to supply platform dependent
solutions for the test script/program. This is leading onto the same path as
adding #ifdefs manually.

> Even if you want to ommit step 2, at least, you could let the user
> decide if he wants to use the va_copy() of the compiler ("$CC -D
> HAVE_VA_COPY").

Let me repeat from my last post: If the compiler is C99 compliant it *must*
have a working va_copy. If the compiler is C89 compliant, it does not have
va_copy, and it is not even allowed to have a macro or external identifier
with this name. So there's absolutely no choice here. Of course there is still
the problem to find a working va_copy for compilers that don't have it, but
this is a much simpler problem. In most cases, src=dest will work, and for the
exceptions, #ifdefs have to be added. Since this is only necessary for C89
compilers, and C89 compilers are more and more becoming extinct, this problem
will vanish over time.

> I'm no C expert, but: Isn't a compiler (or its standard libraries)
> allowed to define more symbols than the standard gives?

There are reserved namespaces (for example, identifiers with two leading
underscores). The compiler is free to use these reserved namespaces for its
own identifiers. The compiler is not allowed to define identifiers that are in
the user namespace. So the simple answer to your question is no, it is not
allowed to do this. The reason is obvious if you think about it: If the
compiler would be free to define whatever it wants, there is no guarantee that
*any* conforming program would compile out of the box with a conforming
compiler, because any user identifier may clash with something that comes from
the compiler.
                                           
BTW: This is the reason why I had to change the code that used fileno().
fileno is non standard, but defined in a standard header file (which is a bad
idea by itself, but that's a different thing). If you force gcc into ISO mode,
it will (correctly) remove the visibility of fileno. This is different if you
include non standard header files. Non standard headers (like unistd.h) are of
course allowed to contain non standard identifiers, because a program using
non standard headers is not conforming anyway.

> Is this change already in today's snapshot?

I've started a snapshot build manually some time ago, and it's finished now,
so the current snapshot does contain the changes.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz@musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.