Re: proposal: scm_c_public_ref et al

[Andy Wingo]

On Sun 06 Mar 2011 17:24, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>>     SCM scm_c_public_lookup (const char *module_name, const char *name);
>>     SCM scm_c_private_lookup (const char *module_name, const char *name);
>>     SCM scm_c_public_ref (const char *module_name, const char *name);
>>     SCM scm_c_private_ref (const char *module_name, const char *name);
>>
>>     Like the above, but with locale-encoded C strings, for convenience.
>>     Module names are encoded as for `scm_c_resolve_module'.
>
> Given that the C strings passed to these functions will more often than
> not be embedded in the source code, it seems to me that it's a mistake
> assume that they are encoded in the current locale.  The current locale
> is normally the locale of the user, which may be different from the
> locale that the source code is written in.
>
> Maybe utf8 is a better choice?

I thought about this, yes, and you're probably right.  However the other
scm_c_ functions in modules.h (and other files) use locale encoding.
That's probably not something we can change in 2.0.x, and it seemed at
the time that consistency was best.  (Or can we change them?  Does it
matter?)

If we were to choose a particular encoding to make convenient, I would
prefer latin1, because it is common, particularly efficient for Guile
(e.g. scm_from_latin1_symbol), and does not raise runtime errors.  That
does not sacrifice generality, as one can always use
scm_from_utf8_symbol or others, and use the SCM-accepting interface.

Humm.  What do you think about having these procedures take latin1?  We
can probably cast it as a compatibility-preserving change, with regards
to 1.8, which would always treat incoming strings as one byte per char.

Andy
-- 
http://wingolog.org/