[v3] solaris c include model

[Benjamin Kosnik]

Thanks for the feedback. It will be a bit of time before I can do 
something more constructive with this, so please bear with me.

> Thanks a lot for doing this work.
> (precision: I won't have much access to any solaris system for a long
> time, so I can only comment from what I remember of my earlier attempts)

You're welcome. It was interesting.

FYI I broke down and installed on x86 hardware with the solaris dev 
stuff, after years of trying to get reliable access to sun hardware.

:(

It was an old-skool weekend for me, pushing solaris uphill and rocking 
out to Run DMC on a boom box while wearing parachute pants. Remember 
when sushi was this "new" kind of food? Ha.

(I had a list of 15 things that bugged me about solaris in the first 30 
minutes. For instance, will solaris coreutils always suck? Yes, apparently.)

> Some comments in random order:
> 
> * for qsort and bsearch, the problem comes from bug 2316. Your fix seems
>   strange, you now declare (for recent __cplusplus) only the extern c++
>   version of bsearch, which is defined nowhere. I would rather simply
>   remove the extern "C++" declaration and keep the other one as is until
>   2316 is fixed (not as violent as what I was mentionning in 30928. By
>   the way 30928 shows an other approach that gives a more uniform result
>   across solaris 8-11 but does not use the system headers as nicely as
>   you are trying to do). If 2316 is fixed then an extern "C++" version of
>   bsearch and qsort will need to be provided probably in libsupc++ or
>   some such.

Interesting, thanks. My "fix" is a hack, and yes, I agree it's strange. 
I think string.h also runs into issues but I forgot to copy over those 
diffs to my linux machine before I rebooted. Whoops.

Why does SunPro not complain about the clashing storage specifications 
here? I guess I'm trying to figure out why Sun thinks this is ok (which 
they must, as it's in the headers.) Can you parse out the logic going on 
here? Or, is this a gcc bug?

> * in math.h (for instance), you could #include <cmath> and #include_next
>   <math.h>, not simply the second one (not sure right now why I wanted
>   that, maybe just so cos(2) works after including math.h)

This is confusing to me.

When you say "math.h" you mean /usr/include/math.h, right?

I was trying to not make major changes to the solaris headers, and 
instead do as much work as possible in the C++ includes.

> * a number of things become useless in the headers since you assume
>   solaris 7+ (like no stdlib.h or similar things)

Can you give more detail here? I don't have much of an idea what changes 
in solaris headers between 7,8,9,10 and 11. Is this documented by Sun 
anywhere?

> * I am surprised you have not hit bug 30112 (only gives 4 failures in the
>   testsuite) and more importantly bug 27340 which should make valarray
>   unusable.

I didn't test, sorry. I ran out of time. No doubt I am only hitting the 
tip of the iceberg here.

I'll double check this when I'm back at it.

> * for C99 functions you are going to have a hard time getting something
>   nice until solaris updates its headers some time after the standard is
>   accepted...

I guess I've not seen a compelling solution to this problem on any 
platform yet.

> Good luck for continuing this work, and once again thank you.

Thanks for the encouragement. As this progresses, I'll update. Or hang 
myself. This is a particularly maddening puzzle.

I'm thinking of checking in the header bits now, since it's not in the 
default config and thus out of the way. It would make things easier for me.

best,
benjamin