pcp
[Top] [All Lists]

Re: [pcp] RFC pcp update: pmParseUnitsStr() function

To: Dave Brolley <brolley@xxxxxxxxxx>
Subject: Re: [pcp] RFC pcp update: pmParseUnitsStr() function
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Fri, 12 Dec 2014 16:20:48 -0500
Cc: pcp developers <pcp@xxxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <548B491B.1030705@xxxxxxxxxx>
References: <20141201154517.GK5088@xxxxxxxxxx> <548B491B.1030705@xxxxxxxxxx>
User-agent: Mutt/1.4.2.2i
Hi, Dave -


> Sorry to be so long in looking at this. I've had a look now and here are 
> my notes:

No problem, thanks!

> [...]
>  * Are // style comments accepted by the C compilers on all the
>    platforms we support?

Evidently yes, they're all over the code base.

>  * For the case of the non-existent divisor, why not just clear
>    'divisor' and set 'divisor_mult' to 1.0 as described by the comment?

Changed.

>  * For the bitfield overflow checks, could that perhaps be automated,
>    and the hard coded limits removed by assigning to the field in 'out'
>    and then checking that they are still equal?

I was worried that a Smart (tm) compiler might nuke the effectiveness
of such a test, but testing shows gcc is fine, so changed.

>  * In __pmParseUnitsStrPart(), why continue to loop over the various
>    keywords once it is known that 'dimension' is no longer 'd_none' or
>    that the appropriate 'dimXXX' is not longer zero? [...]

Changed.

>  * Strange -- I see the new files [...]

Changed. :-)

>  * Style nit -- PCP coding style does not use a space between a
>    function/macro name and the left paren in function/macro calls.

Changed.

- FChE

<Prev in Thread] Current Thread [Next in Thread>