Hi Bruno, On Wed, Nov 5, 2008 at 3:06 AM, Bruno Haible <[EMAIL PROTECTED]> 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
