OK, so this is merely putting those in the header? Basically
:%s/PROCPS_PIDS_CMD/PROCPS_PIDS_CMD_str/g and you're done?
I think there needs to be some sort of hint somewhere.
the s?.. oh for signed. Yeah that might work. It makes the names a little
odd.
- Craig
On Sat, May 14, 2016 at 7:42 AM Jim Warner <james.warner@xxxxxxxxxxx> wrote:
On 05/13/2016 07:16 AM, Craig Small wrote:Craig Small (@smallsees) http://enc.com.au/ csmall at : dropbear.xyz
Made me think is there a way of somehow encoding this? Can't be done by
the program itself, its just an array of unions.
Hi Craig,
In addition to working on the <pids> API (nearly done), I've been toying
with possible solutions to your 'type' dilemma.
The first step is to reduce the sheer number of types in pids.h. Now
that we've proven it works, we have complete control over the proc_t
used behind the scenes. So reducing the number of types and normalizing
others shouldn't be a problem.
Rather than trying to encode types and offering an extractor (if even
possible), there might be another way. What about a truly KISS approach
like the following:
PROCPS_PIDS_CMD_str
PROCPS_PIDS_STATE_ch
PROCPS_PIDS_ID_PID_int
PROCPS_PIDS_ID_EUID_u_int
PROCPS_PIDS_ENVIRON_V_strv
PROCPS_PIDS_TICS_ALL_ull_int
This would force users to think in advance about types. We could drop
the 's' prefix on such suffixes to reduce the clutter. And that would
follow the normal C approach. Then we could remove the type comments
from the header since they'll be encoded in the identifier.
Is that something worth pursuing?
Regards,
Jim
--