On Friday, 18 June 2010, at 21:09:24 (-0400),
Jeff Johnson wrote:
> Any idea how "portably" POSIX dlsym() is in 2010?
According to the Open Group website, dlsym() and dlopen() are at
*least* in POSIX.1 2004 if not earlier. And they came from SunOS, so
Solaris portability won't be an issue. MacO
On Jun 18, 2010, at 9:03 PM, Michael Jennings wrote:
>
> Ah, okay. I guess I was envisioning for runtime checks:
>
> void *f = dlopen(NULL, RTLD_LAZY);
> if (dlsym(f, "popt_something")) {
>...
> }
>
Any idea how "portably" POSIX dlsym() is in 2010?
There's the GNUish dlvsym() that nee
On Friday, 18 June 2010, at 20:31:28 (-0400),
Jeff Johnson wrote:
> But note run-time, where its not always possible to do the test,
> particularly if popt was built by vendors differently, or different
> versions or feature sets.
>
> What I was envisioning is merely a Bloom filter with an API li
On Jun 18, 2010, at 8:13 PM, Michael Jennings wrote:
> On Friday, 18 June 2010, at 14:01:05 (-0400),
> Jeff Johnson wrote:
>
>> Should I go to the effort of a run-time "features" acquisition API?
>
> IMHO, no. Any time you add fluff, you get further away from the meat,
> and there's room for e
On Friday, 18 June 2010, at 14:01:05 (-0400),
Jeff Johnson wrote:
> Should I go to the effort of a run-time "features" acquisition API?
IMHO, no. Any time you add fluff, you get further away from the meat,
and there's room for error. The least error-prone approach is to
check for X when you use
On Jun 18, 2010, at 1:45 PM, Michael Jennings wrote:
> On Friday, 18 June 2010, at 10:52:22 (-0400),
> Jeff Johnson wrote:
>
>> (aside)
>> Instead of a #define version, I typically us a "de facto" check
>> for POPT in compatibilities. E.g. in order to use POPT 2.0
>> in rpm-5.3.2 I'll likely do
On Friday, 18 June 2010, at 10:52:22 (-0400),
Jeff Johnson wrote:
> (aside)
> Instead of a #define version, I typically us a "de facto" check
> for POPT in compatibilities. E.g. in order to use POPT 2.0
> in rpm-5.3.2 I'll likely do
> #if defined(POPT_ARGFLAG_CALCULATOR)
> ...
On Jun 18, 2010, at 12:26 PM, Wayne Davison wrote:
> On Thu, Jun 17, 2010 at 9:21 AM, Jeff Johnson wrote:
> Meanwhile in the future, if you could send a patch against some POPT release
> that I can find
>
> Sorry about that. I sent you a patch for the rsync popt by mistake. Here's
> one I j
On Thu, Jun 17, 2010 at 9:21 AM, Jeff Johnson wrote:
> Meanwhile in the future, if you could send a patch against some POPT
> release that I can find
>
Sorry about that. I sent you a patch for the rsync popt by mistake. Here's
one I just made against 1.16 that now includes a couple tests for t
Related to the issue of throwing exceptions to
C++ and other modern application environments on
errors is providing some sort of restart handling
within POPT itself.
In C this is usually done using setjmp(3)/longjmp(3).
Note that POPT has always had a rather primitive method
to restart implemente
More administrivia related to "incompatibilities"
There is no current means (because I've always thought versioning is a crock)
to detect what POPT API version is being used.
(aside)
Instead of versioning, I've always been ultra-careful not to
introduce any incompatibilities into POPT's API/ABI.
I use many automated tools to guide my hacking.
1) LCOV/GCOV coverage tests
I've run lcov on POPT head yesterday, the results are here:
http://jbj.org/files/popt/lcov-1.17/
Note that function coverage at 100% is an immediate benefit
of doing ISPRAS "shallow"
12 matches
Mail list logo
