Re: Floating point comparison inconsistencies of the geometric types - Mailing list pgsql-hackers

From Emre Hasegeli
Subject Re: Floating point comparison inconsistencies of the geometric types
Date
Msg-id CAE2gYzyLaf-g6PB40Pjy=1xT4-5NaP_Am2x6F=fDA0ZNoHwsvw@mail.gmail.com
Whole thread Raw
In response to Re: Floating point comparison inconsistencies of the geometric types  (Kevin Grittner <kgrittn@gmail.com>)
Responses Re: Floating point comparison inconsistencies of the geometric types  (Kevin Grittner <kgrittn@gmail.com>)
List pgsql-hackers
> The first patch fails to apply due to bit-rot.  That's easy enough
> to correct, but then it runs into warnings on make:

Rebased and fixed.

> Something to consider before posting new version -- should we
> change some of those macros to static inline (in the .h files) to
> avoid double-evaluation hazards?  They might perform as well or
> even better that way, and remove a subtle programmer foot-gun.

One reason to keep them as macros is that they are currently
supporting both float4 and float8.  Currently they look like this:

FLOAT_EQ(val1, val2)
FLOAT_PL(result, val1, val2)

I guess if we would use inline functions, they would look like:

FLOAT8_EQ(val1, val2)
result = FLOAT8_PL(val1, val2)

Result would need to be defined again in the function to be checked
for overflow.  I think this way would be more developer-friendly.  I
have gone some trouble to allocate the result to be able to use the
macros.  Do you know if the performance of both would be the same?

I am not much experienced in C.  If you think that inline functions
are better suited, I can rework the patches.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Transactional enum additions - was Re: Alter or rename enum value
Next
From: Tom Lane
Date:
Subject: Re: Better locale-specific-character-class handling for regexps