Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > compile detection of powf, etc

Reply
Thread Tools

compile detection of powf, etc

 
 
Eric Sosman
Guest
Posts: n/a
 
      01-31-2006


Ed Vogel wrote On 01/31/06 09:06,:
> "Jack Klein" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>>I don't agree with the statement that the "compiler and the library
>>are commonly separate". I don't know of a single other implementation
>>other than some gcc variants where this is so.
>>
>>Do you know of any others?
>>
>>--

>
> Jack,
>
> All HP C compiler implementations (HP-UX, Tru64 UNIX, and OpenVMS)
> ship separately from the libraries. The libraries ship with the O.S. as
> they
> are needed by many applications that do not require the compilers.


That's usually the case, but distribution and
integration are different things. The macros defined
by the compiler and headers must correctly describe
the library and the operating environment, or else
"the implementation" is non-conforming. The Standard
has no notion (in hosted systems) of separating the
compiler from the library, just as it has no notion
of separating the preprocessor from the rest of the
compiler. Real systems are often built from modules,
but the Standard speaks only of the integrated whole.

... which isn't to say that the compilers and
libraries are always properly integrated. As Ken
Thompson pointed out, a compiler that defines
__STDC_VERSION__ as 199901L might find itself deployed
with a library that doesn't conform to C99. That's a
bit like deploying tires of different sizes on the
left and right sides of your car; none of the tires
is "wrong" in and of itself, but the combination of
mismatched sizes is invalid anyhow.

From the programmer's perspective, I think you must
trust __STDC_VERSION__, just as you trust longjmp().
A C99 compiler mis-deployed with a C89 library will
deceive you; equally, a compiler that uses one flavor of
compiler magic in its setjmp() will produce code that
is likely to fail if deployed with a library whose
longjmp() expects a different sort of magic. Sometimes
it will turn out that your trust is misplaced; that's
the way things are in an imperfect world. But what's
the alternative? Run a complete conformance test suite
before starting each compilation? Trust the compiler,
I say, and realize that it may lie very occasionally.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-31-2006
Eric Sosman <(E-Mail Removed)> writes:
[...]
> ... which isn't to say that the compilers and
> libraries are always properly integrated. As Ken
> Thompson pointed out, a compiler that defines
> __STDC_VERSION__ as 199901L might find itself deployed
> with a library that doesn't conform to C99. That's a
> bit like deploying tires of different sizes on the
> left and right sides of your car; none of the tires
> is "wrong" in and of itself, but the combination of
> mismatched sizes is invalid anyhow.


I think you meant Keith Thompson, not Ken Thompson.

> From the programmer's perspective, I think you must
> trust __STDC_VERSION__, just as you trust longjmp().
> A C99 compiler mis-deployed with a C89 library will
> deceive you; equally, a compiler that uses one flavor of
> compiler magic in its setjmp() will produce code that
> is likely to fail if deployed with a library whose
> longjmp() expects a different sort of magic. Sometimes
> it will turn out that your trust is misplaced; that's
> the way things are in an imperfect world. But what's
> the alternative? Run a complete conformance test suite
> before starting each compilation? Trust the compiler,
> I say, and realize that it may lie very occasionally.


My concern is that this kind of compiler vs. library mismatch may be
quite common. gcc is one of the most widely used C compilers, and it
uses whatever C library happens to exist on the system where it's
installed.

I remember having a similar problem many years ago under SunOS 4.1.3.
The system-provided sprintf() function, if I recall correctly,
returned a char* rather than an int (this was a pre-ANSI
implementation), but gcc claimed to be C90-conforming (as the compiler
itself was, as far as I know). Ideally the gcc installation procedure
should have detected this and adjusted __STDC__ appropriately, but I
don't think it did.

If this is a common kind of bug, it's probably worth testing for, at
least for specific known cases of it.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Year Later, CHDK coming SOON for Canon Ultra-Zoom SX120. -Motion Detection, Remote Shutter, Time Lapse, etc ray Digital Photography 23 01-12-2011 01:10 AM
Re: PIL (etc etc etc) on OS X Kevin Walzer Python 4 08-13-2008 08:27 AM
compile time detection of multiple template class usage alexandru.nicau@gmail.com C++ 0 06-27-2007 05:02 PM
cant compile on linux system.cant compile on cant compile onlinux system. Nagaraj C++ 1 03-01-2007 11:18 AM
A technique for compile-time detection of erroneous bit-masks -opinionsrequested Gianni Mariani C++ 0 01-13-2005 07:24 AM



Advertisments