Re: New Defects reported by Coverity Scan for PostgreSQL - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: New Defects reported by Coverity Scan for PostgreSQL
Date
Msg-id 5fece6c5-6a80-9694-1a24-3ae245ae2cba@2ndquadrant.com
Whole thread Raw
In response to Re: New Defects reported by Coverity Scan for PostgreSQL  (Emre Hasegeli <emre@hasegeli.com>)
Responses Re: New Defects reported by Coverity Scan for PostgreSQL
List pgsql-hackers

On 08/01/2018 11:55 AM, Emre Hasegeli wrote:
>> Or perhaps I have it backwards and "l1" and "l2" need to be swapped in
>> that description.  But the mere fact that there is any question about
>> that means that the function is poorly documented and perhaps poorly
>> named as well.  For that matter, is there a good reason why l1/l2
>> have those roles and not the reverse?
> 
> Consistency.  I organized all xxx_closept_yyy(Point *result, xxx *l1,
> yyy *l2) functions in a way that they find the find the point on "l1".
> 

IMHO the main issue here is that the rule is not obvious / documented 
anywhere. I think the best way to do that is by making it clear in a 
comment for each such such function.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: partition tree inspection functions
Next
From: "Daniel Verite"
Date:
Subject: Re: [HACKERS] Can ICU be used for a database's default sort order?