From: Tim Rice <tim@multitalents.net>
To: Bruno Haible <bruno@clisp.org>
Cc: Benji Wiebe <benjiwiebe14@gmail.com>, bug-gnulib@gnu.org
Subject: Re: Port getprogname module to SCO OpenServer
Date: Sat, 3 Oct 2020 17:28:47 -0700 (PDT) [thread overview]
Message-ID: <alpine.UW2.2.11.2010031545360.4044@server01.int.multitalents.net> (raw)
In-Reply-To: <200221218.LiDKksLvd5@omega>
Hi Bruno,
On Sat, 3 Oct 2020, Bruno Haible wrote:
> Tim Rice wrote:
> > > +# elif defined __SCO_VERSION__ /* SCO OpenServer/UnixWare */
> >
> > While __SCO_VERSION__ covers Openserver 6 and UnixWare 7,
> > what is normally used for 6 and 7 is __USLC__ for the native compiler
> > and __sysv5__ for gcc
> >
> > Ie.
> > # elif defined __USLC__ || defined __sysv5__
>
> If the code depends only on the operating system, let's use a #if for
> the operating system, not for the compilers (__USLC__). Because the day
> clang gets ported to that operating systems, the condition would not
> work any more.
>
> https://sourceforge.net/p/predef/wiki/OperatingSystems/ says that
> _SCO_DS can be used to test for SCO OpenServer. It seems that you say that
> __SCO_VERSION__ works as well. So let's use one of these.
_SCO_DS is only for Openserver 5 (which the proposed patch will not work for)
and __SCO_VERSION__ only works for the native compiler on OpenServer 6 and
UnixWare 7. Sorry I did not make that clear before.
__sysv5__ works for the GCC 7.3.0 on 6 and 7. If clang is ported, chances
are extremely high it will also include the __sysv5__ manifest define.
As to __SCO_VERSION__ vs __USLC__ for native compiler, I am fine
with __SCO_VERSION__ in this case. In the general case, I strongly
advocate __USLC__ as that is what most of us have been using for many years.
>
> Bruno
>
--
Tim Rice Multitalents
tim@multitalents.net
next prev parent reply other threads:[~2020-10-04 0:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-01 3:30 Port getprogname module to SCO OpenServer Benji Wiebe
2020-10-01 15:59 ` Bruno Haible
[not found] ` <fd7272ba-fc7a-2204-ee0e-d6c8f3be35cd@gmail.com>
2020-10-03 14:08 ` Bruno Haible
2020-10-07 2:13 ` Benji Wiebe
2020-10-11 19:18 ` Bruno Haible
2020-10-01 18:59 ` Tim Rice
2020-10-02 0:52 ` Benji Wiebe
2020-10-03 13:54 ` Bruno Haible
2020-10-04 0:28 ` Tim Rice [this message]
2020-10-04 2:48 ` Bruno Haible
2020-10-06 0:10 ` Tim Rice
2020-10-06 21:21 ` Bruno Haible
2020-10-06 2:23 ` Benji Wiebe
2020-10-06 3:00 ` Tim Rice
2020-10-06 21:16 ` Bruno Haible
2020-10-06 21:47 ` Tim Rice
2020-10-06 22:01 ` Bruno Haible
2020-10-06 22:45 ` Tim Rice
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.UW2.2.11.2010031545360.4044@server01.int.multitalents.net \
--to=tim@multitalents.net \
--cc=benjiwiebe14@gmail.com \
--cc=bruno@clisp.org \
--cc=bug-gnulib@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).