Date: Sat, 12 Oct 2002 17:49:24 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Terry Lambert <tlambert2@mindspring.com> Cc: Craig Rodrigues <rodrigc@attbi.com>, <freebsd-standards@FreeBSD.ORG>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: Problem detecting POSIX symbolic constants Message-ID: <20021012171803.F15910-100000@gamplex.bde.org> In-Reply-To: <3DA72A53.9D2D61E5@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 portability for theirs. > > > > Undefined symbols being 0 in cpp in expressions was in early C compilers > > if not the original one. Consult your archives for a posting 10-15 years > > or so ago by dmr in comp.std.c about him checking this in his archives. > > You mean "in preprocessor expressions", of course. Oop. I meant only one "in" in "being 0 in cpp in [sic] expressions". > > > This can't be the case; specifically, the sysconf() test will > > > only work at runtime, which means that the symbols had to be > > > there and resolvable at link time. > > > > Symbols can be resolved at runtime using dlopen(), etc. They would only > > actually be available on systems where sysconf() says that they are. > > You can't depend on people using the standard C library via dlopen, > as opposed to, uh, "linking". Yes, a more careful reading of POSIX shows that if _POSIX_REALTIME_SIGNAL_ is undefined, then the (compile-time) system makes no claims as to the feature being either supported or unsupported. (Systems should leave it undefined it they are clueless about it.) The feature may still work at runtime, but the compile-time system makes no claims that it will or won't. Applications would have to do something magic to use it at runtime if it turns out to be present at runtime. It could easily be present at runtime because you update the OS. > > > Uh, the 1990 standard, which allowed "#if" is only 12 years old. > > > > #if is in K&R1 (1978). > > According to my first edition "The C Programming Language": > > 12.3 Conditional compilation > A compiler control line of the form > > #if constant-expression > > checks whether the constant expression (see section 15) > evaluates to non-zero. > > ... > > 15 Constant expressions > In several places C requires expressions which evaluate > to a constant: after case, as array bounds, and in initializers. > In the first two cases, the expression can involve only integer > constants, character constants, and sizeof expressions, possibly > connected by the binary operators > > + - * / % & | ^ << >> == != < > <= >= > > or by the unary operators > > - ~ > > or by the ternary operator > > ?: > > ...no "&&" or "||"... sorry. Also, "defined()" is not defined. > > I think you will find that "&&" and "||" in #if statements are > later extensions. > > The value of undefined macros in preprocessor expressions being > assumed to be zero is also not documented in the book. I would > have to imagine that they were not considered constant expressions. 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 are (informally) constant expessions. I think you are right that defined() didn't exist then. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021012171803.F15910-100000>