[openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

[Andy Polyakov via RT]

>> If you want distinguish Solaris, yes. But if you want to distinguish
>> specifically SunOS 4, 'sun' is guaranteed to do the job. Because
>> compiler that targets SunOS 4 *has to* have it. Either way, we seem to
>> agree that *replacing* sun with __sun is not right thing to do in SunOS
>> 4 context. One can argue for sun || __sun, or one can argue in favour of
>> reverting. My vote goes for latter, because original conditions [in
>> e_os.h] do work adequately. Well, one can argue that it works
>> *incidentally*, but in such situation I usually reason that released
>> software has certain "mass" and one should approach it more
>> pragmatically. At the very least one shouldn't consider "strict ISO
>> conformity" in broadest sense, but even answer question how does it
>> affect platforms in specific supported configurations reflected in
>> Configure.
>>
> 
> Not really looking to argue, but I don't believe this to be entirely
> true.  That is, gcc 2.95 is certainly not the only compiler available
> on SunOS 4... even today SunOS can install packages from, for a perfect
> example, pkgsrc which provides gcc{2..5}.

I didn't say that gcc 2.95 is the only one available. But to make the
[above] point any that underpins it is sufficient. So it happens to be 2.95.

> Any gcc3 or higher *always* generates '__sun'. So does clang.
> Sun/Solaris Studio do so as well. Compilers for the obsolete BSD-based SunOS also defined __sun (according to http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system)
> 
> On the other hand, I believe openssl 1.0 was released somewhere around 2010,
> ten years after (love the group:-) the 2.95 release of gcc.  So I wonder which
> compiler is really used in practice?

Once again, question is not what contemporary compilers do, but if there
a way that is guaranteed to work. Because if there is, we have freedom
not to think which compiler is actually used in any particular case, as
well as give more swing room to end user/developer. If you wish one can
say that objective is to make it work in maximum amount of situations,
*and* not necessarily limited to ISO pure-room conditions.

>> As for reference to 'sun' not being defined with -ansi already in 2.95.
>> At the same time it also says that it's basically counterproductive,
>> because [once again] system headers require it. One should also keep in
>> mind that standard compliance is never perfect, especially on older
>> systems, and you're driven to make trade-offs. Like the one in question.
>>
>>
> 
> Well, I can't speak for the author of the above note on the gcc site,
> but to extract a recent quote from a NetBSD and pkgsrc developer: 
> "Programs should be written to standards, not gcc extensions."

Sure, but world is simply not perfect. I'm not saying that we shouldn't
try to improve it, we totally should. It's only that sometimes we can't
be as categorical, and I don't think we should feel bad about making
some compromises, most notably when it comes to legacy systems...