Re: [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...


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

> ... 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.

After closer look I have to withdraw my preference for just reverting.
Because there is one case that is not appropriate for *Solaris*.
Initially I noted that Solaris sys/ioctl.h includes sys/filio.h, but I
failed to notice and latter's inclusion is conditional and condition is
not met when OpenSSL compiles with defaults flags. As compiler targeting
Solaris doesn't *have to* define 'sun' for system headers to work, one
has to reserve for possibility that it's absent.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

Le 22/11/15 17:26, Andy Polyakov via RT a écrit :
> 
> 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}.

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?

> 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."

In the meanwhile there is -std=c99 and more recently -std=c11 that have
been published with the similar strict requirements.

Finally, I would be happy add back the check for 'sun' as well as '__sun'
if deemed necessary.

cheers,
-- 
Richard PALO


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

>> In other words I argue in favour of reverting suggested change in
>> 1.0.1/2. Because I can't find evidence that __sun is defined on said
>> platform.
>>
>>
>>
>>
> FWIW, the generally accepted and documented platform tests include:
>>  #ifdef __sun
>>  /* this is SunOS */
>>  #endif

I understand and appreciate this. But the point is that original
conditions are supposed to work on platform that predates the moment the
referred way became generally accepted. Once again, it either has to
work with old compiler, or support for old compiler has to be disclaimed
and code removed. Consider this. Do all SunOS 4 compilers define __sun?
No. Do all of them define sun? Yes, they have to, because system headers
depend on it. In worst case it probably should be sun || __sun, but sun
alone is sufficient. For SunOS 4 that is.



___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

> FWIW, the generally accepted and documented platform tests include:
>>  #ifdef __sun
>>  /* this is SunOS */
>>  #endif

By the way, was it *actually* tested on SunOS 4? And if so, when and
with which compiler? Is it possible that it simply was harmonized at
some point with "we have double-underscore everywhere, don't we"
rationale, without actual test on SunOS 4? And this way became kind of
an urban legend? Well, I'm not actually asserting that I myself have
possibility to test something on SunOS 4 now, but I have copy of system
headers and see what did gcc 2.95 define...


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

Le 22/11/15 15:42, Andy Polyakov via RT a écrit :
>> FWIW, the generally accepted and documented platform tests include:
>>>  #ifdef __sun
>>>  /* this is SunOS */
>>>  #endif
> 
> By the way, was it *actually* tested on SunOS 4? And if so, when and
> with which compiler? Is it possible that it simply was harmonized at
> some point with "we have double-underscore everywhere, don't we"
> rationale, without actual test on SunOS 4? And this way became kind of
> an urban legend? Well, I'm not actually asserting that I myself have
> possibility to test something on SunOS 4 now, but I have copy of system
> headers and see what did gcc 2.95 define...
> 
> 
> 
> 
Well, I admit I only checked back to gcc3... I did notice the following though:
https://sourceforge.net/p/predef/wiki/OperatingSystems/
> #if defined(sun) || defined(__sun)
> # if defined(__SVR4) || defined(__svr4__)
> /* Solaris */
> # else
> /* SunOS */
> # endif
> #endif

that is, if supporting that far back is indeed a goal, then *both* should be 
checked. Naturally that should be acceptable to most anybody concerned.

cheers

-- 
Richard PALO


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

Le 22/11/15 16:29, Richard PALO a écrit :
> Le 22/11/15 15:42, Andy Polyakov via RT a écrit :
>>> FWIW, the generally accepted and documented platform tests include:
  #ifdef __sun
  /* this is SunOS */
  #endif
>>
>> By the way, was it *actually* tested on SunOS 4? And if so, when and
>> with which compiler? Is it possible that it simply was harmonized at
>> some point with "we have double-underscore everywhere, don't we"
>> rationale, without actual test on SunOS 4? And this way became kind of
>> an urban legend? Well, I'm not actually asserting that I myself have
>> possibility to test something on SunOS 4 now, but I have copy of system
>> headers and see what did gcc 2.95 define...
>>
>>
>>
>>
> Well, I admit I only checked back to gcc3... I did notice the following 
> though:
> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>> #if defined(sun) || defined(__sun)
>> # if defined(__SVR4) || defined(__svr4__)
>> /* Solaris */
>> # else
>> /* SunOS */
>> # endif
>> #endif
> 
> that is, if supporting that far back is indeed a goal, then *both* should be 
> checked. Naturally that should be acceptable to most anybody concerned.
> 
> cheers
> 


BTW from what I can see, 'sun' being not defined with '-ansi' was already 
documented in https://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html


-- 
Richard PALO


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

>> I'd like to propose the attached patch to 1.0.2d which avoids problems
>> with strict ISO conforming compiler/options, which do not define 'sun' only
>> '__sun' as usual... such as gcc/clang -std=c99
>>
>> This affects the build itself, but also any user of openssl/opensslconf.h
> 
> I've commited only the part that applied to the master branch, but
> fixed that in all the branches.  Please let me know if you need
> other changes in the stable branches.

There is partial contradiction here. It's argued in terms of
contemporary compilers, while the code fragments in question, mostly
those in e_os.h target specific *legacy* platform which is unlikely to
have contemporary compiler. So that attempt to harmonize with recent
compiler one breaks things for old compiler. One can argue that it's
probably broken anyway, but it doesn't really make harmonization more
right, does it? If platform is broken, then support should be disclaimed
and correct approach would be to *remove* code. If support is not
disclaimed then correct approach would be to look at target system, not
what gcc/clang do on Linux. BTW, support for platform in question *is*
disclaimed in master, so that in master code should be removed. Even
that sys/filio.h thing, because default alternative works fine on Solaris.

Side note about "#if define (sun) /* Newer Sparc's */" "sun" denotes OS
vendor, not processor. So that it would be more appropriate to switch to
sparc || __sparc__.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Kurt Roeckx via RT]

On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote:
> I'd like to propose the attached patch to 1.0.2d which avoids problems
> with strict ISO conforming compiler/options, which do not define 'sun' only
> '__sun' as usual... such as gcc/clang -std=c99
> 
> This affects the build itself, but also any user of openssl/opensslconf.h

I've commited only the part that applied to the master branch, but
fixed that in all the branches.  Please let me know if you need
other changes in the stable branches.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

>>> I'd like to propose the attached patch to 1.0.2d which avoids problems
>>> with strict ISO conforming compiler/options, which do not define 'sun' only
>>> '__sun' as usual... such as gcc/clang -std=c99
>>>
>>> This affects the build itself, but also any user of openssl/opensslconf.h
>>
>> I've commited only the part that applied to the master branch, but
>> fixed that in all the branches.  Please let me know if you need
>> other changes in the stable branches.
> 
> ... If support [for SunOS 4] is not
> disclaimed then correct approach would be to look at target system, not
> what gcc/clang do on Linux.

In other words I argue in favour of reverting suggested change in
1.0.1/2. Because I can't find evidence that __sun is defined on said
platform.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Andy Polyakov via RT]

>>> FWIW, the generally accepted and documented platform tests include:
  #ifdef __sun
  /* this is SunOS */
  #endif
>>
>> By the way, was it *actually* tested on SunOS 4? And if so, when and
>> with which compiler? Is it possible that it simply was harmonized at
>> some point with "we have double-underscore everywhere, don't we"
>> rationale, without actual test on SunOS 4? And this way became kind of
>> an urban legend? Well, I'm not actually asserting that I myself have
>> possibility to test something on SunOS 4 now, but I have copy of system
>> headers and see what did gcc 2.95 define...
>>
>>
>>
>>
> Well, I admit I only checked back to gcc3... I did notice the following 
> though:
> https://sourceforge.net/p/predef/wiki/OperatingSystems/
>> #if defined(sun) || defined(__sun)
>> # if defined(__SVR4) || defined(__svr4__)
>> /* Solaris */
>> # else
>> /* SunOS */
>> # endif
>> #endif
> 
> that is, if supporting that far back is indeed a goal,

Irregardless whether or not goal is formulated like *this*, it's
definitely can be formulated at least as "keep even legacy platforms in
mind". I mean it's more about discipline.

> then *both* should be checked. Naturally that should be acceptable to most 
> anybody concerned.

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.

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.


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

Le 17/11/15 19:47, Kurt Roeckx via RT a écrit :
> On Tue, Nov 17, 2015 at 06:33:22PM +, Richard PALO via RT wrote:
>>
>> Strict ISO conforming compilers don't define 'sun', only __sun.
> 
> Ah, I clearly misunderstood your earlier message.
> 
> 
> Kurt
> 

Sorry, perhaps it was a bit terse...

Here's a comparison of 'with extensions' and then 'strict' for studio

> richard@omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -xc99 -E 
> -xdumpmacros /dev/null |& egrep  'sun|svr4|SVR4'
> #define __SVR4 1
> #define __sun 1
> #define sun 1
> richard@omnis:/home/richard$ /opt/solarisstudio12.4/bin/cc -Xc -xc99 -E 
> -xdumpmacros /dev/null |& egrep  'sun|svr4|SVR4'
> #define __SVR4 1
> #define __sun 1

and for gcc (or clang)

> richard@omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=gnu99 -E -dM - 
>  #define __SVR4 1
> #define __sun 1
> #define sun 1
> #define __sun__ 1
> #define __svr4__ 1
> richard@omnis:/home/richard$ /opt/gcc-4.8.1/bin/gcc -std=c99 -E -dM - 
>  #define __SVR4 1
> #define __sun 1
> #define __sun__ 1
> #define __svr4__ 1

-- 
Richard PALO


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

Le 17/11/15 19:09, Kurt Roeckx via RT a écrit :
> On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote:
>> I'd like to propose the attached patch to 1.0.2d which avoids problems
>> with strict ISO conforming compiler/options, which do not define 'sun' only
>> '__sun' as usual... such as gcc/clang -std=c99
> 
> I fail to understand how this would cause any problems for you.
> Also, we're not targetting C99, we're still at C89/C90 with some
> extentions.  If a newer standard conflicts we should of course try
> to fix it, but it build just as fine using gnu99 or gnu11 for me.
> 
> 
> Kurt

Straight from Oracle concerning Solaris:
>  
> #ifdef __sun
>Sun compiler
> #endif
> #ifdef __SUNPRO_C
>Sun C compiler /* __SUNPRO_C value is the version number */
> #endif
> #ifdef __SUNPRO_CC
>Sun C++ compiler /* __SUNPRO_CC value is the version number */
> #endif
> #ifdef __sparc
>generate code for SPARC (R) architecture
> #endif
> #ifdef __sparcv9
>generate code for 64-bit SPARC architecture
> #endif
> #ifdef __i386
>generate code for x86 architecture
> #endif
> #ifdef __amd64
>generate code for x64 architecture
> #endif
> 

Using 'sun' is an extension and has not been recommended for years (decades?)

Strict ISO conforming compilers don't define 'sun', only __sun.
examples: cc -Xc -xc99; gcc -std=c99; clang -std=c99  
 
As I mentioned, there are two issues:
1. building openssl with a strict ISO conforming compiler
2. building other programs including opensslconf.h with a strict ISO compiler

cheers
-- 
Richard PALO


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Richard PALO via RT]

I'd like to propose the attached patch to 1.0.2d which avoids problems
with strict ISO conforming compiler/options, which do not define 'sun' only
'__sun' as usual... such as gcc/clang -std=c99

This affects the build itself, but also any user of openssl/opensslconf.h


-- 
Richard PALO


>From 95695ef607535135da38f6f7cdd62238aa55a97b Mon Sep 17 00:00:00 2001
From: Richard PALO 
Date: Tue, 17 Nov 2015 14:34:16 +0100
Subject: [PATCH] Use '__sun' instead of 'sun' for strict ISO conforming
 compiler/options

Signed-off-by: Richard PALO 
---
 crypto/bf/bf_opts.c | 2 +-
 crypto/bf/bfspeed.c | 2 +-
 crypto/bn/bnspeed.c | 2 +-
 crypto/bn/expspeed.c| 2 +-
 crypto/cast/cast_spd.c  | 2 +-
 crypto/cast/castopts.c  | 2 +-
 crypto/des/des_opts.c   | 2 +-
 crypto/des/speed.c  | 2 +-
 crypto/idea/idea_spd.c  | 2 +-
 crypto/opensslconf.h.in | 2 +-
 crypto/rc2/rc2speed.c   | 2 +-
 crypto/rc4/rc4speed.c   | 2 +-
 crypto/rc5/rc5speed.c   | 2 +-
 e_os.h  | 4 ++--
 14 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/crypto/bf/bf_opts.c b/crypto/bf/bf_opts.c
index f85495c..a583c33 100644
--- a/crypto/bf/bf_opts.c
+++ b/crypto/bf/bf_opts.c
@@ -92,7 +92,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/bf/bfspeed.c b/crypto/bf/bfspeed.c
index 305ad8b..ac2f957 100644
--- a/crypto/bf/bfspeed.c
+++ b/crypto/bf/bfspeed.c
@@ -90,7 +90,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/bn/bnspeed.c b/crypto/bn/bnspeed.c
index e387fdf..ff86336 100644
--- a/crypto/bn/bnspeed.c
+++ b/crypto/bn/bnspeed.c
@@ -97,7 +97,7 @@
 # include 
 #endif
 
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/bn/expspeed.c b/crypto/bn/expspeed.c
index 513a568..249a4c2 100644
--- a/crypto/bn/expspeed.c
+++ b/crypto/bn/expspeed.c
@@ -123,7 +123,7 @@ static void genprime_cb(int p, int n, void *arg);
 # include 
 #endif
 
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/cast/cast_spd.c b/crypto/cast/cast_spd.c
index 91d2ce2..e157f46 100644
--- a/crypto/cast/cast_spd.c
+++ b/crypto/cast/cast_spd.c
@@ -90,7 +90,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/cast/castopts.c b/crypto/cast/castopts.c
index 42687f2..55684e7 100644
--- a/crypto/cast/castopts.c
+++ b/crypto/cast/castopts.c
@@ -92,7 +92,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/des/des_opts.c b/crypto/des/des_opts.c
index ec50e94..1ccd432 100644
--- a/crypto/des/des_opts.c
+++ b/crypto/des/des_opts.c
@@ -100,7 +100,7 @@ extern void exit();
 # include 
 #endif
 
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/des/speed.c b/crypto/des/speed.c
index 9a3d929..a1d801b 100644
--- a/crypto/des/speed.c
+++ b/crypto/des/speed.c
@@ -91,7 +91,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/idea/idea_spd.c b/crypto/idea/idea_spd.c
index 59acc40..70ec3eb 100644
--- a/crypto/idea/idea_spd.c
+++ b/crypto/idea/idea_spd.c
@@ -90,7 +90,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git a/crypto/opensslconf.h.in b/crypto/opensslconf.h.in
index 814309b..d8e6abc 100644
--- a/crypto/opensslconf.h.in
+++ b/crypto/opensslconf.h.in
@@ -120,7 +120,7 @@
optimization options.  Older Sparc's work better with only UNROLL, but
there's no way to tell at compile time what it is you're running on */
  
-#if defined( sun )		/* Newer Sparc's */
+#if defined( __sun )		/* Newer Sparc's */
 #  define DES_PTR
 #  define DES_RISC1
 #  define DES_UNROLL
diff --git a/crypto/rc2/rc2speed.c b/crypto/rc2/rc2speed.c
index 3e45eb0..bce854c 100644
--- a/crypto/rc2/rc2speed.c
+++ b/crypto/rc2/rc2speed.c
@@ -90,7 +90,7 @@ OPENSSL_DECLARE_EXIT
 #ifndef TIMES
 # include 
 #endif
-#if defined(sun) || defined(__ultrix)
+#if defined(__sun) || defined(__ultrix)
 # define _POSIX_SOURCE
 # include 
 # include 
diff --git 

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

[Kurt Roeckx via RT]

On Tue, Nov 17, 2015 at 05:43:45PM +, Richard PALO via RT wrote:
> I'd like to propose the attached patch to 1.0.2d which avoids problems
> with strict ISO conforming compiler/options, which do not define 'sun' only
> '__sun' as usual... such as gcc/clang -std=c99

I fail to understand how this would cause any problems for you.
Also, we're not targetting C99, we're still at C89/C90 with some
extentions.  If a newer standard conflicts we should of course try
to fix it, but it build just as fine using gnu99 or gnu11 for me.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

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

[Kurt Roeckx via RT]

On Tue, Nov 17, 2015 at 06:33:22PM +, Richard PALO via RT wrote:
> 
> Strict ISO conforming compilers don't define 'sun', only __sun.

Ah, I clearly misunderstood your earlier message.


Kurt


___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev