Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkgmX-0006QM-Ep for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Aug 2018 02:22:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fkgmU-0001m9-SM for pgsql-hackers@arkaria.postgresql.org; Wed, 01 Aug 2018 02:22:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkgmU-0001m2-L4 for pgsql-hackers@lists.postgresql.org; Wed, 01 Aug 2018 02:22:30 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fkgmQ-0007rd-UE for pgsql-hackers@postgresql.org; Wed, 01 Aug 2018 02:22:29 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w712MGxT026770; Tue, 31 Jul 2018 22:22:16 -0400 From: Tom Lane To: Ning Yu cc: Alvaro Herrera , Tomas Vondra , Emre Hasegeli , Pg Hackers Subject: Re: New Defects reported by Coverity Scan for PostgreSQL In-reply-to: References: <20180731172149.kdjl3xdjjtwxaj4s@alvherre.pgsql> Comments: In-reply-to Ning Yu message dated "Wed, 01 Aug 2018 08:08:13 +0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26768.1533090136.1@sss.pgh.pa.us> Date: Tue, 31 Jul 2018 22:22:16 -0400 Message-ID: <26769.1533090136@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Ning Yu writes: > From my point of view it's better to also put some comments for humans to > understand why we are passing l1 and l2 in reverse order. The header comment for lseg_closept_lseg() is pretty far from adequate as well. After studying it for awhile I think I've puzzled out the indeterminacies, but I shouldn't have had to. I think it probably should have read * Closest point on line segment l2 to line segment l1 * * This returns the minimum distance from l1 to the closest point on l2. * If result is not NULL, the closest point on l2 is stored at *result. 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? While Coverity is surely operating from a shaky heuristic here, it's got a point. The fact that it makes a difference which argument is given first means that you've got to be really careful about which is which, and this API spec is giving no help in that regard at all. regards, tom lane