[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: parse_duration()
From: |
Bruce Korb |
Subject: |
Re: parse_duration() |
Date: |
Wed, 5 Nov 2008 10:42:27 -0800 |
Hi Bruno,
On Wed, Nov 5, 2008 at 3:06 AM, Bruno Haible <address@hidden> wrote:
> Bruce Korb wrote:
>> > But it should be documented.
>>
>> In the new .h file.
>
> Good!
>
> The documentation should also mention the return value convention of the
> function: how does the caller distinguish
> - a successful parse,
errno == 0. "errno" always gets set.
> - an out-of-range time_t result,
errno == ERANGE
> - a syntactically invalid input?
errno == EINVAL
I'll add that to the header for now.
> Can you also write the module description, or do you want me to do it for you?
Depends on how impatient you are. I confess I don't consistently have
the time it necessarily takes. (There was a big party last night and I'm
working a later-than-normal shift, so I'll not do anything today. :)
>> I'm not an internationalization expert. I'll take a look when I have some
>> time.
>
> The background is: Some characters, such as U+00A0, are single-byte in
> some locales on some systems (0xA0 in ISO-8859-1 on Linux libc5) but
> multi-byte in other locales:
> $ LC_ALL=de_DE.UTF-8 `which printf` '\u00A0' | od -t x1
> 0000000 c2 a0
> 0000002
> <ctype.h> functions operate on a single byte. In the ISO-8859-1 locale:
> isspace (0xA0) -> true
> In the UTF-8 locale:
> isspace (0xC2) -> false
> isspace (0xA0) -> false
>
> The workaround: Decide whether you want locale dependent or locale independent
> parsing.
> - If locale dependent, use the mbiter & mbchar modules to handle byte
> sequences such as 0xC2 0xA0 as a single multibyte character.
> - If locale independent, use "c-ctype.h" instead of <ctype.h>.
Ah. This certainly sounds easiest. I suspect there is some ``next_char''
function to use instead of ``pz++'', yes? Again, I've never had any
of my stuff go through a real i18n process ....
> Huh? You don't need a cast to convert from 'char *' to 'char const *'. The
> prototype of strchr was defined by ANSI C to be
It's when the ``char const *'' thingeys have to get passed to ``char
*'' arguments
where the function does not actually modify the pointed to data.
Understand, I'm a bit of a lazy programmer. Once some coding clarification
that I like and think is good starts to become a nuisance of greater bother
than the benefit, I start thinking, "Why bother?" So, yes, I think it right and
proper to declare const thost things you aren't going to modify.
> Really, marking pointers as pointing to 'const' not only helps the reader
> to understand that no dirty tricks are being played to the string, but
> also helps avoiding bugs through typos when someone writes (*ps = 'x')
> when he means (*ps == 'x').
Yep -- we're agreed. It's a Good Thing.
Is it worth the bother in this context? Maybe.
The answer, to me, is not completely obvious.
Certainly, the entry point to parse_duration() needs to be ``char const *''.
Cheers - Bruce
- parse_time(), Bruce Korb, 2008/11/01
- Re: parse_time(), Bruno Haible, 2008/11/02
- Re: parse_time(), Bruce Korb, 2008/11/02
- Re: parse_time(), Bruno Haible, 2008/11/02
- Re: parse_duration(), Bruce Korb, 2008/11/02
- Re: parse_duration(), Bruno Haible, 2008/11/03
- Re: parse_duration(), Bruce Korb, 2008/11/04
- Re: parse_duration(), Bruno Haible, 2008/11/05
- Re: parse_duration(),
Bruce Korb <=
- Re: parse_duration(), Bruce Korb, 2008/11/16
- Re: parse_duration(), Bruno Haible, 2008/11/17
Re: parse_time(), Bruce Korb, 2008/11/02