You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In typical PMDA flow, instance IDs are first assigned to the PCP's pmdaInstid::i_inst (via the pmdaIndom table) as int.
However, PCP's pmdaFetchCallBack signature uses unsigned int to supply those same instance IDs back to the PMDA.
So it appears that there's no technically-right signedness to use for instance IDs. Instead, we should choose a signedness that provides the PMDA++ users the most intuitive behaviour.
Of course, testing the high-bit cases would be the right way to start.
The text was updated successfully, but these errors were encountered:
Pretty much as expected... all positive i_inst survive the trip through to pmdaFetchCallback, however negatives wrap, and become greater than or equal to 1<<31 (two's compliment).
In the end, there's no "right" or "wrong" approach here, since PCP's API is unconsistent, not PMDA++. But, I think it's pretty clear that unsigned int provides the most intuitive behaviour, because:
PMDA++ hides the pmdaInstid::i_inst type anyway, so if we cast that internally to int for PCP's sake, the PMDA++ user does not need to know about it.
If we stick with int, then the negative values (if someone chose to use them) would have the unintuitive behaviour of -2, -3, -4 ... etc all being valid / fine to use, but -1 being invalid / resulting in unexpected behavior as -1 is the same as PM_INDOM_NULL on many (most?) systems.
Currently
pcp::instance_id_type
isint
.In typical PMDA flow, instance IDs are first assigned to the PCP's
pmdaInstid::i_inst
(via thepmdaIndom
table) asint
.However, PCP's
pmdaFetchCallBack
signature usesunsigned int
to supply those same instance IDs back to the PMDA.So it appears that there's no technically-right signedness to use for instance IDs. Instead, we should choose a signedness that provides the PMDA++ users the most intuitive behaviour.
Of course, testing the high-bit cases would be the right way to start.
The text was updated successfully, but these errors were encountered: