From: ludovic.courtes@laas.fr (Ludovic Courtès)
Subject: Re: Text collation
Date: Tue, 12 Dec 2006 09:38:00 +0100 [thread overview]
Message-ID: <878xhd33x3.fsf@laas.fr> (raw)
In-Reply-To: <87ejr6hxm1.fsf@zip.com.au> (Kevin Ryde's message of "Tue, 12 Dec 2006 09:32:54 +1100")
Hi,
Kevin Ryde <user42@zip.com.au> 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.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
next prev parent reply other threads:[~2006-12-12 8:38 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-19 9:23 Text collation Ludovic Courtès
2006-09-19 22:38 ` Kevin Ryde
2006-10-22 18:33 ` Ludovic Courtès
2006-10-23 2:01 ` Rob Browning
2006-10-23 7:56 ` Ludovic Courtès
2006-10-24 8:37 ` Rob Browning
2006-10-25 8:16 ` Ludovic Courtès
2006-10-25 8:46 ` Rob Browning
2006-10-25 18:40 ` Neil Jerram
2006-10-25 19:55 ` Rob Browning
2006-10-26 8:47 ` Ludovic Courtès
2006-11-09 7:44 ` Ludovic Courtès
2006-11-09 17:43 ` Rob Browning
2006-11-10 13:39 ` Ludovic Courtès
2006-11-11 15:17 ` Neil Jerram
2006-11-20 13:24 ` Ludovic Courtès
2006-11-21 22:03 ` Neil Jerram
2006-11-22 13:38 ` Ludovic Courtès
2006-10-25 18:43 ` Neil Jerram
2006-10-25 19:31 ` Rob Browning
2006-10-25 18:33 ` Neil Jerram
2006-10-26 8:39 ` Ludovic Courtès
2006-11-29 23:08 ` Kevin Ryde
2006-11-30 15:19 ` Ludovic Courtès
2006-12-02 21:56 ` Kevin Ryde
2006-12-04 9:01 ` Ludovic Courtès
2006-12-05 0:20 ` Kevin Ryde
2006-12-05 18:42 ` Carl Witty
2006-12-05 20:41 ` Kevin Ryde
2006-12-05 22:29 ` Carl Witty
2006-12-05 0:38 ` Kevin Ryde
2006-12-02 22:02 ` Kevin Ryde
2006-12-10 12:30 ` Ludovic Courtès
2006-12-11 22:32 ` Kevin Ryde
2006-12-12 8:38 ` Ludovic Courtès [this message]
2006-12-12 20:04 ` Kevin Ryde
2006-12-13 9:41 ` Ludovic Courtès
2006-12-31 17:10 ` Neil Jerram
2006-12-15 20:52 ` Kevin Ryde
2006-12-12 19:05 ` Kevin Ryde
2006-12-13 9:14 ` Ludovic Courtès
2006-12-12 19:16 ` Kevin Ryde
2006-12-13 9:20 ` Ludovic Courtès
2006-12-12 21:37 ` Kevin Ryde
2006-12-13 9:28 ` Ludovic Courtès
2006-12-13 20:10 ` Kevin Ryde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=878xhd33x3.fsf@laas.fr \
--to=ludovic.courtes@laas.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).