On Tue, Nov 20, 2012 at 7:45 AM, Nick Wellnhofer <[email protected]> wrote:
> On 20/11/2012 03:16, Marvin Humphrey wrote:
>> From the perspective of Charmonizer as a component in isolation (which has
>> the potential to spin off from Lucy one day) I wonder whether it wouldn't
>> be advantageous to leave intrusions into the standard namespace up to the
>> consumer:
>>
>> #ifndef CHY_HAS_STDINT_H
>> #define int32_t chy_i32_t
>> ...
>> #endif
>
>
> We could keep the old Integers module, and rename the new version to
> C99_Integers or so. But I think Charmonizer users should either use
> (chy_)i32_t or int32_t. I can see no value in using both names at the same
> time.
+1
Regardless, there's no hurry to muck with all the good efforts you just put in
getting C99 working for Lucy.
Charmonizer's interface for specifying which symbols you need it to define is
insufficiently granular for a general-purpose tool. What we have works fine
for Lucy and Clownfish today because Charmonizer's modules happen to produce
exactly what we require, but that changes as soon as Charmonizer starts
needing to support other projects. (A fun exercise would be to try to replace
arbitrary configuration scripts.)
If and when Charmonizer gets its own independent public API, we'll probably
want to provide functions which support either C99 names, chy_ names, or names
with arbitrary prefixes like "lucy_" or "apr_". But we can cross that bridge
when we come to it.
In the meantime, as of Lucy 0.4.0 anyone who wants to use Charmonizer will be
able to grab the amalgamated charmonizer.c file and either use it as-is or
hack it to meet their needs. IMO that's a "good enough" informal, provisional
API for a long time to come -- allowing us to either focus on accumulating
and testing probes (the hard, important work for a configuration prober like
Charmonizer), or just rest on our laurels since Charmonizer already does
pretty much what we need it to.
> Maybe Charmonizer should also provide two separate modules for booleans.
People can always do stuff like this:
#ifdef __cplusplus
typedef my_bool bool;
#elif defined(CHY_HAS_STDBOOL_H)
#include <stdbool.h>
typedef my_bool bool;
#else
typedef my_bool char;
#endif
Sorting out that kind of logic in your header is not nearly as annoying as
figuring out how to discover CHY_HAS_STDBOOL_H in the first place on every
modern compilation platform.
But sure, we could offer a feature to define `bool` one way or another --
documented with appropriate caveats. :)
>> The workaround doesn't seem any sketchier to me than the fact that Perl
>> defines its own `bool` in the first place.
>>
>> After your changes, our `bool` is either a macro defined in stdbool.h or a
>> C++ builtin. It's not a careless hack.
>
> Right, but compiling with HAS_BOOL might break with certain Perl versions.
> After all, we use a different definition of 'bool' than what Perl was
> compiled with.
OK, so that means that e.g. if the stdbool.h _Bool is typedef'd to char but
Perl's `bool` is typedef'd to an int or an enum, then invoking a function from
Perl's XS api which takes a `bool` argument would break. Hrmm.... hopefully
that never happens.
> I'm not sure whether HAS_BOOL is really meant to be used for C++
> compatibility. I'd really like to see whether the bool changes work with
> oldest Perl we officially support.
We officially support back to Perl 5.8.3 (with some build-time requirements
like Module::Build and Devel::PPPort needing to be at the state they were for
5.10.0).
The logic in handy.h for 5.8.3 looks like it will still work with -DHAS_BOOL.
http://perl5.git.perl.org/perl.git/blob/f0095d0783d416c5b117e7b415e301cfea24ac44:/handy.h
FWIW, everything seems OK with the c99-types branch on a custom-compiled Perl
5.10.0 on CentOS 5.
Marvin Humphrey
