bug-gnulib
[Top][All Lists]
Advanced

[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




reply via email to

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