Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: GCC vs Clang Date: Wed, 27 Jul 2016 09:36:03 -0700 Organization: None to speak of Lines: 70 Message-ID: References: <5798ceed.3489562@news.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="27109"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19W7aThvjs1Gt94kUXhcUsC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Nz+HgVICB0+zWy8BXy3dBHx8G+0= sha1:n0lmC5x81mVGFOoe14kJEXtmJWI= Xref: csiph.com comp.lang.c:91156 raltbos@xs4all.nl (Richard Bos) writes: > Keith Thompson wrote: >> jacobnavia writes: >> > Le 26/07/2016 à 01:31, supercat@casperkitty.com a écrit : >> >> Separating the library from the compiler makes it unclear what a compiler >> >> is or is not allowed to assume about the way the library is used. >> > >> > To give a popular example: The gcc compiler under the "mingw" version >> > (windows) recognizes long double and generates code for 80 bits longs >> > double. But mingw uses the Microsoft C library, and that printf doesn't >> > recognize long doubles, since Microsoft doesn't support them. We have >> > answered MANY times questions here from people that ask why their printf >> > "wasn't working". >> > >> > Separating the library from the compiler is just NONSENSE! >> >> Separating the library from the compiler is what made MinGW possible in >> the first place. > > Well, that explains why there were no ports of GCC to Microsoft > platforms before MinGW. Good thing DJ Delorie never gave up his day job > as a shrimp fisherman, then. > > Sorry, Keith, but in this case, supercat and jacob are mostly(!) right > and you are mostly(!) wrong. Ok, I concede the point. But I believe it made MinGW much easier to implement. As I understand it, the MinGW developers were able to take an existing compiler and an existing runtime library and combine them into a C implementation with far less effort than would have been required if they had had to write their own runtime library. Disclaimer: I am not very familiar with MinGW, and I welcome any corrections on the above. It is unfortunate that the compiler and the runtime library did not agree on the representation of long double. There is a workaround: defining the macro "__USE_MINGW_ANSI_STDIO" as 1 before including causes it to use a different implementation of stdio. (I don't know whether this applies to the long double functions declared in and .) > There _are_ reasons for separating the > compiler from the library, and a few of them are good, but the main one > does appear to be the ability to pass the buck around when the two don't > work together. I don't believe that's the actual reason. It might be an unintended effect in some cases. > The reasons for keeping the development of the implementation in one > hand are more important to me. I prefer a complete implementation, not a > bunch of parts sourced from incestuous-but-legally-separate parties. I > don't buy my car as a DIY kit, either. I'll assemble my own furniture, > because that only has to stay up, but as soon as something has to do > work, like a car or a C implementation, I want it built by the vendor, > not by me. Your preference is certainly a valid one. However, I'm content to let someone else do the work of integrating a compiler and a runtime library, perhaps developed separately, into a working implementation. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"