Re: csc (C# Compiler) bug

From: Daniel Pratt (kolREMOVETHISkata_is_at_hotmail.com)
Date: 06/03/04 

Date: Thu, 3 Jun 2004 13:26:16 -0400

Hi Paul,

"Paul Reeder" <paul@reeder.ws> wrote in message
news:52D3A0D0-C1A7-45EA-8555-F4C597F827D5@microsoft.com...
> I hope that MS watches this newsgroup.
>
> I seem to have found a bug in csc. I am compiling from VS.NET 2003. The
csc version information (from command line) is:
> Microsoft (R) Visual C# .NET Compiler version 7.10.3052.4
> for Microsoft (R) .NET Framework version 1.1.4322
> Copyright (C) Microsoft Corporation 2001-2002. All rights reserved.
>
> In my application, I am using some custom display options that use
non-standard characters as special icons, and often have strings which have
characters >0x80. When used as a constant, these do not compile properly.
Here is some source that does not compile properly:
> private const string DELETE = " \x84DELETE";
>
> Using ildasm to view the MSIL, I see:
> .field private static literal string DELETE = bytearray (20 00 DE 84 4C 00
45 00 54 00 45 00 ) // ...L.E.T.E.
>
> Definitely not what is expected! This does not happen with all strings
which contain '\x84' followed by other characters. In fact, I have only
seen it twice, with the example above and with " \x84Acknowledge".
<snip>
> Any information would be appreciated.

    This isn't a bug so much as a bit of ambiguity. The sequence "\x" in a
literal string begins a hexadecimal escape sequence. Because D and E are
both hexadecimal digits the entire sequence of "\x84DE" is interpreted as
one escape sequence. If you declared it like this:

    private const string DELETE = " \x84" + "DELETE";

then the compiler would know what you mean. Note that the above does not
result in the two string literals being concatenated at run-time. The
compiler is smart enough to merge them at compile time.

Regards,
Daniel

Relevant Pages

  • Re: Why leave the error handling to the caller?
    ... I didn't even mention the fact that it didn't compile. ... If the intended behavior of the program is to simply output all the strings with no further processing there would never be any reason for storing them and whatever is in the error recovery part of the program would better be the *entire* program. ... I assume the purpose of allocating the strings in some structure to begin with is that there really is some further processing to be done before outputting them. ... That would make the error handling function output data that would be wrong. ...
    (comp.lang.c)
  • Re: [Bugme-new] [Bug 11446] New: Automate "to compile as module" strings
    ... Automate "to compile as module" strings ... Component: Configuration ... tristate "BMAC support" ...
    (Linux-Kernel)
  • Re: csc (C# Compiler) bug
    ... > I seem to have found a bug in csc. ... Here is some source that does not compile properly: ... This does not happen with all strings ... Its not a bug, its actually correct. ...
    (microsoft.public.dotnet.languages.csharp)
  • 50 years of progress in the language
    ... almost every program would compile and run correctly using ... Smaller length alphabetic test onstant strings were treated as ... Conversion between integer variabless and equivalent digit strings ... the character array and the character string. ...
    (comp.lang.fortran)
  • Re: STL::list trouble in VC6
    ... > | not compile, as sizeofcould be used in the definition ... // Provides some storage for small strings... ... template ... struct basic_string_helper ...
    (alt.comp.lang.learn.c-cpp)