Re: Interpretation of extensions different from Unix/Linux?

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:b3995dcd-11bd-4101-94b7-0d154c0ad47d@l35g2000pra.googlegroups.com...
On Aug 18, 1:48 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote:
...
>> Well, the problem here is that it *always* makes sense to use a string
>> literal. That's how you specify what you want in storage in Ada.
>
>We might be talking about two different things.  If I had a type whose
>purpose was to represent the storage of a string in Huffman code, it
>wouldn't make sense to specify its value with a string literal,
>because the octets in that storage wouldn't have any direct
>relationship with any meaningful graphic characters.  So specifying
>the value of such a type with a string literal wouldn't make sense,
>except via a conversion routine of some sort.

IMHO, there is *always* a conversion routine of some sort. Surely "ABC" has 
no direct relationship to the three bytes that are actually stored in memory 
for type String. Similarly for numeric literals. It is just a shorthand for 
a a number of encodings (keep in mind that the form of a string literal is 
the same for String, Wide_String, and for Wide_Wide_String). I don't see any 
reason that it can't be a shorthand for some other encoding as well.
>... OK, after a bit of research, it looks as though the use of BOM to
>distinguish UTF-8 from other encodings isn't part of an official
>"standard", but it's widely used by Windows applications.
...
> Anyway, perhaps this means that the UTF_Encoding package shouldn't
> assume the use of BOM to distinguish UTF-8-encoded strings, but perhaps
> the routines there should provide an optional parameter to specify what
> "protocol" (if any) is used to distinguish between encodings (a protocol 
> of
> None would mean that we assume the calling program knows
> by some other means what kind of encoding is being used, and the
> UTF_Encoding package just converts single characters according to the
> standard without worrying about any kind of header sequence).

Or you could have just read AI05-0137-1 and/or clause A.4.11 in the latest 
RM draft to see what is proposed and why. ;-) [Modulo the stupid missing 
"not" in A.4.11(20/3), which will be fixed next time, of course.] All of the 
issues with the BOM already have been considered and dealt with.

My comment was specifically in relation to using UTF-8 in file names in the 
standard I/O packages, and is not related to anything else (as that is 
already covered by the proposal and by common practice).

                                        Randy.