Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!1.eu.feeder.erje.net!newsfeed.fsmpi.rwth-aachen.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Handling numeric types in interpreter Date: Tue, 28 Jul 2015 11:52:21 -0700 Organization: None to speak of Lines: 51 Message-ID: References: <19c290ad-3e83-45bc-9ecd-71b19bc2632d@googlegroups.com> <91ee1672-182a-4968-8d22-610a21495452@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="378"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Lr+YL8v1rVrL2ABTy1lMz" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:ebkWWkTbNLNtx8fyf6zuNeRe74U= sha1:4HEA6jnpPZ1lgVG7pPlTJbI0QDA= Xref: csiph.com comp.lang.c:66504 ais523 writes: > Keith Thompson wrote: >> I have no problem with you conclusion (that double is good enough for >> your purposes). I disagree with your rationale (that long double is >> potentially non-portable). > > long double is actually one of the least portable C89 features. > > The problem is that both the C standard, and comp.lang.c, tend to > consider a C implementation to be a single, monolithic object. In > practice, C implementations are normally provided as multiple parts: a > linker, a compiler, a standard library, header files, perhaps others. > > If all the parts of an implementation cooperate with each other, then > (by now) the result can nearly always be used as a conforming C89 > compiler (although often you'll have to use a command line option to > request C89 conformance). However, it's not that uncommon to have > situations where some of the parts are mismatched; perhaps the library > you're using was designed for a different compiler than the compiler > you're using. This sort of mismatch, unsurprisingly, is capable of > introducing problems that cause the combined implementation to fall > short of C89. > > One of the most common mismatched combinations seen in practice occurs > on Windows, with mingw (compiler + linker + headers) + msvcrt (library); > this combination is commonly used as a result of licensing issues. > msvcrt is not designed for use with mingw, and in particular, the two > components disagree on the value of sizeof(long double). The upshot is > that when using this combination, arguments of long double type cannot > be used reliably in standard library calls (most commonly seen in the > case of printf, for which the header files cannot work around the > problem because printf is variadic). MinGW is the only implementation I've heard of that has this problem with long double (which doesn't imply that there aren't others). And as it happens there's an easy workaround: define the macro __USE_MINGW_ANSI_STDIO as 1, which you can do by compiling with gcc -D__USE_MINGW_ANSI_STDIO=1 If I recall correctly, Microsoft's compiler and runtime library give double and long double the same size and representation (which is perfectly legal, though it does miss out on the opportunity to use floating-point with a greater range and precision), whereas gcc makes long double bigger than double. -- 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"