Sat 05 Mar 2005 06:26:20 AM UTC, comment #2:
Renamed.
As Microsoft's tools handles the bytemark, it's a bug in pnet if pnet doesn't.
But to argue against supporting bytemarks (just for the fun of it):
cscc always treats source files as UTF-8 (can also use latin1, if specified), but it does not support the bytemark used in unicode streams. Why? UTF-8 is the encoding used by all .NET technologies, unless otherwise specified.
"A conforming implementation of C# shall interpret characters in conformance with the Unicode Standard[...]." - ECMA-334
And if all the files is treated as UTF-8 by default, there is no need to tell the compiler that the file is UTF-8.
"A protocol SHOULD forbid use of U+FEFF as a signature for those textual protocol elements that the protocol mandates to be always UTF-8, the signature function being totally useless in those cases." - RFC 3629
So if it was the reverse, the sourcefiles being latin1 by default and we'd have to use a commandline switch (or simlar) to determine the encoding to be UTF-8, a bytemark would be great. But now that's not the case, and a bytemark is totally useless, the commandline switch should in any case still override the bytemark.
:)
|