Re: multibyte C locale

[David-Sarah Hopwood <david-sarah@xxxxxxxxxxxxx>]

shwaresyst@aol.com wrote:
> I don't believe so. This would still force all applications doing
> lexical analysis to use routines that need to include extra logic to
> test whether a given byte is or isn't a state-changing code that it
> might need to account for, even if just to throw that code and the next
> byte or bytes away from lexical consideration before continuing
> processing, and not simply a non-state -changing code that isn't part of
> the PCS which can be disregarded. For applications like the C compiler,
> when doing a rebuild of a million or more lines of code, this could
> noticeably add to the processing time required to complete the task, I'd
> think.

That argument makes no sense:

If an application uses single-byte character APIs, then it incurs no
additional overhead when the locale uses a multi-byte encoding.

If an application uses multi-byte character APIs, then that is
presumably because it was intended to work correctly on input in
multi-byte encodings. So complaining that it might incur some
additional overhead is beside the point, since that overhead is
necessary for the app to work as intended.

Note that the app's behaviour will fall into one of these classes
regardless of whether it uses the libc character APIs, or rolls its
own, as most compilers do.

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com