This is the mail archive of the
mailing list for the libstdc++ project.
Re: Porting Questions
Phil Edwards wrote:
> On Wed, Jun 27, 2001 at 02:45:22PM -0400, David A. Greene wrote:
>> functions and #define be appropriate? For example, test
>> for __builting_alloca and #define ALLOCA_FUNCTION to
>> alloca or __builtin_alloca as appropriate.
> Testing is probably not unreasonable; for those systems where running the
> tests is either slow and/or pointless, there should probably be some way
> to force the results of the tests outright.
Sure, no problem. It might be better just to check whether
we're building with GNU and if not, assume __builtin_* doesn't
exist. Some platforms will lose out if they try to follow
GNU, though. Testing will catch these cases. It may not be
worth it in the initial iteration.
Of course, __builtin_* can't always be converted to *
portable (__builtin_fabsf, for example) so I'll need to
special-case those. Then there's the problem of
> Rather than additional macros, I'd recommend leaving the builtins spelled
> as they are, and if there is no (say) __builtin_alloca, then and only then
> adding a macro, like
> #define __builtin_alloca alloca
Yes, that seems reasonable. I'd considered that but was worried
it might clash with something that gcc or glibc might do. I
get nervous when #define'ing gcc names due to past experience.
> (BTW, you mentioned you had some extra autoconf work in your local tree,
> I think. Would you be adverse to contributing them to the public tree?
> I'm always up for making the configury smarter.)
Oh, absolutely. In my ideal world I will contribute everything
back so I don't have to keep resolving CVS conflicts. :)
>> - I have the same problem with NULL. Our compiler doesn't
>> like the assignment of (void *)(0) to non-void pointers.
> Good, since (void*)0 is an invalid definition for NULL. I hope we're not
> doing that anywhere in libstdc++.
It's a glibc problem. Unfortunately, I'm forced to use a really
old version of glibc so I can't control this. I suppose I could
edit the glibc version I have but I suspect this may be an issue
for other systems as well. Might as well check for it.
> What about straight 0 or 0L instead? There are potential overloading
> problems there, but at least it's legal.
Actually, that's exactly what I'm doing now. I've #ifdef __GNUC__'d
the NULL assignments and #else'd 'em with 0 (make sense?). Again,
I don't like this solution (but it was quick to get working so I
could find other problems) which is why I asked for opinions.
> GCC defines a magic __null for precisely these reasons... there's an example
> of how to define a magic NULL in userland on the libstdc++ website, but
> it needs an empty default ctor added.
Ok, I'll look into that. Solving this problem in a more general
way would be nice. But for the case where NULL is already
(incorrectly) defined, does #define'ing NULL_POINTER in configure
make sense? I'm not happy with it, but I don't see a way around
it. Somehow the NULL's have to be removed.
Hrm...The more I think about it, the more I think I ought to just
go and fix glibc. It will impact fewer people and will at least
delay additional changes to libstdc++ until someone else has the
same problem. :) I've had to hack glibc anyway due to broken
>> Now, the big whopper:
> Can't help you there, unfortunately. After the discussion involving
> definitions, specializations, instantiations, and AIX freaky-weirdness,
> my understanding of templates has regressed. I don't think I understand
> them anymore. :-)
I sympathize. This was a particularly nasty problem to diagnose.
Benjamin Kosnik is credited with writing c_locale_generic.cc
though his name doesn't appear in the other relevant files.
Perhaps he can help me out. I'm going to need some sort of
roadmap to the files in the locale subsystem. It's rather