On Sat, Oct 12, 2002 at 01:20:03PM -0700, Terry Lambert wrote:
Tony Finch wrote:
No -- the short-circuiting behaviour of and || only matters if
you can have side-effects, which you can't in the preprocessor,
so there is no need to implement it (unifdef doesn't).
Consider:
#if
Tony Finch wrote:
No -- the short-circuiting behaviour of and || only matters if
you can have side-effects, which you can't in the preprocessor,
so there is no need to implement it (unifdef doesn't).
Consider:
#if _DEFINED_SUPPORTED defined(SOMETHING)
That's a syntax error
On Sat, Oct 12, 2002 at 01:44:36AM -0700, Terry Lambert wrote:
I think the lack of || and mostly had to do with the fact
that there was conditional evaluation of the RHS of the operator,
based on the result of the LHS.
With just an or an |, you actually need a much less complicated
On Fri, 11 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
I know it's not fashionable to write code that's portable to
compilers other than GCC, but even if FreeBSD is going to ignore
portability for it's own source code, it's probably unreasonable
to expect ACE to ignore
Bruce Evans wrote:
This book has lots of bugs (mostly from being too informal and/or
omitting necessary details). Note that section 15 doesn't even mention
and || working in non-cpp constant expressions. But they
cetainly worked in expressions, and expressions with only constants
in them
Tony Finch wrote:
With just an or an |, you actually need a much less complicated
state machine to evaluate a constant expression. With the ||/,
you almost have to do an edge associative operation, which implies a
much more complex state machine for the preprocessor, I think.
No --
On Thu, 10 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
In Standard C, this is equivalent to the non-verbose version:
#if _POSIX_REALTIME_SIGNALS != -1
...
#endif
since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to
0 in cpp
On Thu, 10 Oct 2002, Terry Lambert wrote:
Bruce Evans wrote:
_POSIX_REALTIME_SIGNALS is undefined:
Apparently the same as when it is defined to 0, except you cannot assume
that anything related to it works until you call sysconf(), so you must
not reference its interfaces statically,
Bruce Evans wrote:
I know it's not fashionable to write code that's portable to
compilers other than GCC, but even if FreeBSD is going to ignore
portability for it's own source code, it's probably unreasonable
to expect ACE to ignore portability for theirs.
Undefined symbols being 0 in
Bruce Evans wrote:
_POSIX_REALTIME_SIGNALS is only valid in versions of POSIX that support
it. Applications must also conditionalize on _POSIX_VERSION if they
want to check for features that are not in all versions.
Yeah; I mentioned that I was afraid of this...
Runtime configuration only
On Thu, 10 Oct 2002, Craig Rodrigues wrote:
On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote:
Perhaps because they wanted you to use sysconf() instead of these mistakes.
Well in the case of ACE, it is a C++ library that is compiled on
platforms which may or may not have sysconf()
Garrett Wollman wrote:
On Wed, 9 Oct 2002 22:23:07 -0400, Craig Rodrigues [EMAIL PROTECTED] said:
I was advised by Terry Lambert to use:
#ifdef _POSIX_REALTIME_SIGNALS
Terry was wrong. If _POSIX_REALTIME_SIGNALS is undefined, it means
one of two things:
- The RTS option is not
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote:
To be totally correct, you will need to:
#ifdef _POSIX_REALTIME_SIGNALS
#if (_POSIX_REALTIME_SIGNALS != -1)
...
#endif
#endif
It's annoying, but
On Wed, 9 Oct 2002, Craig Rodrigues wrote:
Earlier this year on the FreeBSD hackers mailing list:
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=278142+0+/usr/local/www/db/text/2002/freebsd-hackers/20020317.freebsd-hackers
I was advised by Terry Lambert to use:
#ifdef _POSIX_REALTIME_SIGNALS
On 2002-10-10 01:07, Terry Lambert [EMAIL PROTECTED] wrote:
So the test is:
#ifdef _POSIX_REALTIME_SIGNALS
#if _POSIX_REALTIME_SIGNALS 0
...or, if you want to assume all preprocessors support #if:
#if defined(_POSIX_REALTIME_SIGNALS) (_POSIX_REALTIME_SIGNALS 0)
I think the first is
On Thu, Oct 10, 2002 at 09:31:56PM +1000, Bruce Evans wrote:
Perhaps because they wanted you to use sysconf() instead of these mistakes.
Well in the case of ACE, it is a C++ library that is compiled on
platforms which may or may not have sysconf() (ie. Windows), so using sysconf() is
not
Giorgos Keramidas wrote:
I think the first is safer, in that if #if is not supported, it
being an undefined preprocessor directive would be non-fatal,
being in an uncompiled #ifdef block...
Well, almost. There is one exception. A compiler that doesn't support
#if but happens to run in
Bruce Evans wrote:
In Standard C, this is equivalent to the non-verbose version:
#if _POSIX_REALTIME_SIGNALS != -1
...
#endif
since if _POSIX_REALTIME_SIGNALS is not defined then it is equivalent to
0 in cpp expressions. The problem cases are if
Bruce Evans wrote:
_POSIX_REALTIME_SIGNALS is defined to 0:
This means that the interface may work, and that it exists in headers and
libraries, so applications may reference it in normal ways. It may fail
at runtime; applications must use sysconf() to determine if it is actually
Craig Rodrigues wrote:
#ifdef _POSIX_REALTIME_SIGNALS
According to the letter of the law:
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap02.html
The following symbolic constants shall either be undefined or defined
with a value other than -1.
So, this is legal way to
On Wed, Oct 09, 2002 at 07:29:48PM -0700, Terry Lambert wrote:
To be totally correct, you will need to:
#ifdef _POSIX_REALTIME_SIGNALS
#if (_POSIX_REALTIME_SIGNALS != -1)
...
#endif
#endif
It's annoying, but doing this will ensure that there are no
21 matches
Mail list logo
