Path: csiph.com!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.std.c Subject: Re: contradiction about the INFINITY macro Date: Mon, 04 Oct 2021 10:34:18 -0700 Organization: None to speak of Lines: 32 Message-ID: <87r1d0g0dh.fsf@nosuchdomain.example.com> References: <20210930012112$48d9@zira.vinc17.org> <87pmsqizrh.fsf@nosuchdomain.example.com> <20210930105413$d6e8@zira.vinc17.org> <87lf3ehy4v.fsf@nosuchdomain.example.com> <20211001083755$efb3@zira.vinc17.org> <877dewimc9.fsf@nosuchdomain.example.com> <20211004092110$b3e8@zira.vinc17.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="f039da7ec9ded39f2ed1a75f27d21830"; logging-data="21882"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+DAN+fFPRsyh8eeP018s17" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:il36EtCYZqTseOrcASECUzcgijs= sha1:L2M4ZkYxoDRSycPk8o/Udht0ClU= Xref: csiph.com comp.std.c:6331 Vincent Lefevre writes: > In article <877dewimc9.fsf@nosuchdomain.example.com>, > Keith Thompson wrote: > >> Vincent Lefevre writes: >> > In article <87lf3ehy4v.fsf@nosuchdomain.example.com>, >> > Even if FP_INFINITE could be defined conditionally, this would not >> > imply that INFINITY is usable, since for instance, long double may >> > have an infinity but not float. > >> The standard only defines INFINITY and NAN for type float. I think the >> implication is that it assumes either all floating types have NaNs >> and/or infinities, or none do. That might be a valid assumption. > > But the standard doesn't say that explicitly. It even just says > "if and only if the implementation supports quiet NaNs for the > float type". If the intent were to have NaN support for all the > FP types or none, why doesn't it say "... for the floating types" > instead of "... for the float type"? Since the NAN macro is of type float (if it's define), it only makes sense to define it that way. Presumably if an implementation had NaN for float but not for double, it would define NAN. IMHO it would have been better if the assumption that all floating types behave similarly had been stated explicitly, and perhaps if there were three NAN macros for the three floating-point types. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips void Void(void) { Void(); } /* The recursive call of the void */