guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Text collation


From: Ludovic Courtès
Subject: Re: Text collation
Date: Tue, 12 Dec 2006 09:38:00 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Hi,

Kevin Ryde <address@hidden> writes:

>> strto{dl}
>
> The reason those funcs are hardly used is that they're not very good.
> Traditionally strtol had no overflow checking, and even now c99
> doesn't guarantee localized forms for either.  Also strtod may or may
> not have the helpful "p" format, and its rounding isn't guaranteed
> (only "recommended practice").

Ok, I wasn't aware of this.

> There's no particular virtue in the C library.  If you want to hook
> onto it then name functions accordingly, so everyone knows what to
> expect.  If you want better semantics, hopefully more scheme-like,
> then use names reflecting that betterness.

That makes sense, but OTOH, we want to avoid silly names I guess.  ;-)

So, do you think we should rename them to `strto{d,l}' or documenting
this dependence is enough?

>> The former `i18n.c' (which contained only `gettext'-related code) was
>> renamed to `gettext.c' which seems more appropriate.
>
> Please try to resist the temptation to make non-changes.

I couldn't think of any other option that would retain consistency.

> If you say you're concerned about speed of startup and size of
> modules :-), then you don't want to create a new mutex.  The common one
> is specifically there for miscellaneous uses.

The mutex is statically initialized, how can it impact startup time?

More importantly: what's the semantics of a "misc" mutex?  Suppose
function `foo' invokes `bar', which in turn invokes `string-locale<?'.
What if both `foo' and `string-locale<?' turn out to lock the "misc"
mutex upon entry?

>> I really meant "unresolved", in the sense that the test cannot be run
>> when `fr_FR' isn't available.
>
> "unresolved" is for bugs not yet addressed, or long-standing
> misfeatures not easily fixed.  I'm pretty sure "unsupported" is
> intended for things not available on account of the system
> environment.

Hmm, I thought `unresolved' was for cases where a test cannot be run for
some reason.  See, e.g., `guardians.test', `socket.test'.  OTOH,
`unsupported' seems to be used when a feature cannot be tested because
it wasn't compiled in (e.g., `alist.test').  Well, there's admittedly
not a huge difference.

Thanks,
Ludovic.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]