On 30/04/15 04:55, Martins Innus wrote:
Hi,
I looked throughout the source and couldn't find this anywhere. Is
there a rough POSIX version that PCP tries to adhere to? I'd love to use
open_memstream in my hotproc cleanups:
http://linux.die.net/man/3/open_memstream
It would simplify the config parsing logic, but it's part of
POSIX.1-2008. This would be in linux_proc, so would only affect Linux,
but then would make the procpmda depend on this functionality.
In the interest of not losing support for older systems that
currently work, I assume this would break too many older builds, but
figured I'd check anyway. I can't find a reference on where this would
not be supported.
Alternatively, any thoughts on pulling such functionality into the
pcp codebase?
If not, no worries, just would be a handy thing to have available.
We don't really have a formal position on a POSIX version that the code
is expected to comply with, other than the (old) -D_GNU_SOURCE in the
build which sort of means we can never be POSIX compliant (sigh).
This is in part because the POSIX story is confusing across all the
platforms we're trying to support, or at least was so at points of time
over the last 20+ years.
Rather we've gone down the path of isolating source code that is not
necessarily portable across all the platforms using HAVE_FOO macros ...
in this case it would be HAVE_OPEN_MEMSTREAM. This works fine in cases
where the feature provides isolated functionality and the #else path can
either do nothing or return a relevant error such as PM_ERR_APPVERSION.
But in this case I think you'd either have to
(a) assert that open_memstream() is available on any Linux platform
where PCP is expected to compile and just do it, or
(b) keep the existing implementation for the #else part and use
open_memstream() for an alternative (new and default) implementation
behind the #ifdef HAVE_OPEN_MEMSTREAM
(b) does not make much sense in terms of simplifying the code (just the
opposite!), so I think it is a value call on (a) ...
I've never used open_memstream() so I can't offer any advice I'm afraid.
|