Re: U+FFFF

"Richard A. O'Keefe" <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 30/07/2013, at 7:29 PM, Jan Wielemaker wrote:
> 
> I don't really recall this thread to reach a conclusion.

Two things were clear:
 (a) The Unicode standard is QUITE explicit about this.
 (b) There is no consensus yet about what WE should do about it.
> 
>> for a program to generate such a thing to begin with.
>> 
>> So how did that U+FFFF get there?
> 
> As you've seen yourself, there are plenty of languages that to not care
> whether the code is a valid Unicode codepoint or not.

That's not actually an answer.  The question is how did *THIS*
U+FFFF get there in *THIS* case and what *SHOULD* it have been?
>> 
> 
> We need an executive summary :-) As far as I'm converned, SWI-Prolog
> basically reads, stores and writes Unicode and should be as little as
> possible involved in understanding how to deal with Unicode characters.
> Of course, in some places this cannot be avoided (e.g., read/1, case
> conversion, etc).

This is certainly a defensible and useful position.
> 
> 
> The only problem I have at the moment is that internal wide character
> handling uses the system's wchar_t*,

When I started processing Unicode, I had to deal with systems in
which wchar_t could be 4 bytes, 2 bytes, or 1 byte.  Some of them
were the same system.  The lesson I drew from this was *NEVER* to
use wchar_t except at the very last step of interfacing with
someone else's code that wanted it.
> 
>  - Change the internal representation to UCS-32 on all
>    platforms.  Then we need conversions (and may have
>    errors) in the C API functions that talk wchar_t*
>    on Windows.

This is definitely the way to go.  As far as I know, it is
still legal for wchar_t to be implemented as 1 byte.  Doing this in
my own C code meant that a world of pain just disappeared.

> I'm tempted to choose the second solution.

That's the painful hard work bug-fountain solution.
Cut the Gordian knot.  Use something you _control_.

> 
> And that is not the only case.  I've been (on the side)
> involved in the W3C standards for SPARQL and the various
> RDF languages and I have not seen any restrictions for
> \uFFFF being proposed.  I want SWI-Prolog to be able to
> process such documents.

Well, does anyone on those committees actually understand
Unicode?  Like have their own copy of the book with the
edges brown from use?  Is there any way to get someone from
the actual Unicode group seconded to those committees?

In the mean time, you have to interoperate with what you
have to interoperate with.

The question remains for someone trying to *interpret* this
stuff, "what on earth was THIS occurrence of U+FFFF supposed
to mean? how did the originator INTEND it to be processed?"
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.