On 2018-Nov-06, Emre Hasegeli wrote:
> > Surely the comment in line 3839 deserves an update :-)
>
> Done.
>
> > This seems good material. I would put the detailed conventions comment
> > separately from the head of the file, like this (where I also changed
> > "Type1 *type1" into "Type1 *obj1",
> Surely the comment in line 3839 deserves an update :-)
Done.
> This seems good material. I would put the detailed conventions comment
> separately from the head of the file, like this (where I also changed
> "Type1 *type1" into "Type1 *obj1", and a few "has" to "have")
Looks better to me. I
On 2018-Nov-06, Emre Hasegeli wrote:
> The patch is attached to improve the comments and variable names. I
> explained the functions with the same signature on the file header. I
> can duplicate those on the function headers if you find that better.
Surely the comment in line 3839 deserves an u
> Good idea. I haven't though about that, but now such names makes more
> sense to me. I will prepare another patch to improve the naming and
> comments to be applied on top of my current patches.
The patch is attached to improve the comments and variable names. I
explained the functions with t
On 08/01/2018 04:07 PM, Emre Hasegeli wrote:
I think there are three different things that need to be addressed:
* Underspecified comments.
I agree. My patch added comments, the next one with actual fixes adds
more. I just didn't want to invest even more time on them while the
code is its
> I think there are three different things that need to be addressed:
>
> * Underspecified comments.
I agree. My patch added comments, the next one with actual fixes adds
more. I just didn't want to invest even more time on them while the
code is its current shape.
> * The function names and ar
Tomas Vondra writes:
> On 08/01/2018 11:55 AM, Emre Hasegeli wrote:
>> 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
> anywher
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 the
> 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 ro
On 08/01/2018 04:22 AM, Tom Lane wrote:
> 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
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
indete
To make coverity happy we might be able to suppress this false alarm by
adding a line like below:
```
/* coverity[SWAPPED_ARGUMENTS] */
lseg_closept_lseg(result, l2, l1);
```
>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 reve
Hello guys. Coverity complained about this patch as below. What, if
anything, should be done about it? One solution is to mark it as a
false-positive in Coverity, of course.
On 2018-Jul-29, scan-ad...@coverity.com wrote:
> ** CID 1438146: API usage errors (SWAPPED_ARGUMENTS)
>
>
>
13 matches
Mail list logo
