DotGNU Portable.NET - Bugs: bug #11464, cscc chokes on unicode byte mark
You are not allowed to post comments on this tracker with your current authentication level.
bug #11464: cscc chokes on unicode byte mark
Submitter: | James Michael DuPont <mdupont> | ||
Submitted: | Fri 31 Dec 2004 03:40:29 PM UTC | ||
Category: | None | Severity: | 2 - Minor |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | None |
Open/Closed: | Open |
Sat 05 Mar 2005 06:26:20 AM UTC, comment #2: |
Carl-Adam Brengesjo <ptah> |
Fri 31 Dec 2004 03:54:41 PM UTC, comment #1: It turns out that this is UTF-8 encoded source file.
|
James Michael DuPont <mdupont> |
Fri 31 Dec 2004 03:40:29 PM UTC, original submission:
I have reported this bug to mono,
|
James Michael DuPont <mdupont> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2005-03-05 | ptah | Severity | 3 - Normal | 2 - Minor | |
Summary | Cscc chokes on garbage that mono ignores | cscc chokes on unicode byte mark |
Powered by Savane 3.13-4448.
Corresponding source code
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.
:)