[Cfp-interest 2236] Re: contradiction about the INFINITY macro
Jim Thomas
jaswthomas at sbcglobal.net
Mon Oct 11 10:36:49 PDT 2021
> On Oct 11, 2021, at 7:01 AM, Vincent Lefevre <vincent at vinc17.net> wrote:
>
> On 2021-10-10 17:06:54 -0700, Jim Thomas wrote:
>> It is allowed for a wider standard floating type to have infinity
>> (or NaN) but not a narrower type. C doesn’t have infinity and NaN
>> macros for that. Is this an issue for some implementation?
>
> Programs that use INFINITY with double would be incorrect with such
> hypothetical implementations.
Right. What I meant to ask was if any implementations have infinity in double but not float, or in long double but not double..
For the example below, where apparently HUGE_VAL would be acceptable, the code could have just used HUGE_VAL instead of INFINITY. (There are float and long double analogs of double HUGE_VAL.) Annex F requires the HUGE_VAL macros to expand to a positive infinity of the indicated type.
Requiring INFINITY to be defined if and only if infinity is supported does seem simpler and less error prone. It would be a substantive change, coming late in the process. Breakage resulting from the change would be seen at translation time (which would be better than later). At the CFP meeting this week we can talk about adding that option to our proposal to WG14.
- Jim Thomas
> For instance, cairo does that in src/cairo-default-context.c:
>
> static cairo_status_t
> _cairo_default_context_clip_extents (void *abstract_cr,
> double *x1, double *y1, double *x2, double *y2)
> {
> cairo_default_context_t *cr = abstract_cr;
>
> if (! _cairo_gstate_clip_extents (cr->gstate, x1, y1, x2, y2)) {
> *x1 = -INFINITY;
> *y1 = -INFINITY;
> *x2 = +INFINITY;
> *y2 = +INFINITY;
> }
>
> return CAIRO_STATUS_SUCCESS;
> }
>
> BTW, cairo already assumes that INFINITY is not necessarily defined:
>
> #if !defined(INFINITY)
> #define INFINITY HUGE_VAL
> #endif
>
> (thus among the C implementations with no float infinity, it would
> behave better when INFINITY is not defined than when it is defined).
> Said otherwise, a change of the standard would be a benefit for
> software like cairo.
>
> --
> Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
More information about the Cfp-interest
mailing list