Re: VS2005 major development bug

Edward Diener wrote:
Andre Kaufmann wrote:

I simply compiled your sample you've attached to a post in this thread and it crashed.

If you had used the project which was in the .zip file you would have seen that it was compiled with Managed C++ and not C++/CLI, and that it compiles fine.

The DEBUG configuration compiles fine and then crashs after it is started. Where did I wrote something about C++/CLI ? Crashing during compilation would mean then compiler to throw an ICE, but that's surely not the case.


Exactly. I haven't debugged the sample into depth, but as I would interpret it the .NET runtime checks if the embedded class has access to the outer class, ValidationEdit and as it's forbidden to access private members from another class (friend declaration don't work also), it simply throws a security exception.

No in Managed C++.

Yes in managed C++ it compiles rewritten in C++/CLI it compiles not. That is the main problem. When the managed version is run and the native object tries to access a private method of the managed object the runtime throws an System.FieldAccessException.




In normal C++ programming a pimpl class does not have to be a nested

No problem with that.

class because one can use the 'friend' declaration to allow the pimpl class to access all of the members of the other class if necessary.

I just wondered why you defined the class members in the header. Pimpl, is commonly used or is designed to decouple objects.
Therefore the class is only declared in the header.

public __gc class ValidationEdit : ......
{
..........
__nogc class ValidationEditPimpl;
};

And defined in the CPP unit. But I don't want to be pedantic and this has nothing to do with the problem / bug we are discussing in this thread about.

Because C++ .NET does not allow 'friend', the solution to this in Managed C++ was to make the pimpl class a nested class of the ref class and pass a pointer of the ref class to the pimpl class. However even the ability to have a pimpl nested native class of a ref class has been taken away in C++/CLI.

And it has been taken away for managed C++ too. Except that it compiles, but throws a runtime error. While in C++/CLI the compiler, as you wrote, will throw an error at compilation time.

That is not progress but regress.

It seems that this has nothing to do with C++/CLI itself. But rather with the code generation / runtime itself. There must have been some security reasons for this change.

See my other post and the only solution I have found for this.



While I appreciate your workarounds, my actual code is far more complicated than my simple sample and the point of posting my bug was to have someone else ascertain that the bug actually exists on their machine also. This you did not do because you did not use the solutions/projects in my zip file.

I did.

Instead you created your own solutions/projects, added my source file, then told me what you found. That is not the way to test someone else's bug.

I have not, why should I do so ? You are making assumptions, which you have in another discussion accused me (always) to do so.

So:

Take your example posted in this newsgroup. Make all private variables in class ValidationEdit public, as I already wrote, by changing a single line of code:

File: ValidationEdit.h
Line: 32

private:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container* components;

into:

public:
/// <summary>
/// Required designer variable.
/// </summary>
System::ComponentModel::Container* components;


Then recompile your control and test it. I did no >>>> other <<<< changes to your project and I used your project configuration.


I am using Managed C++ because I had a ton of mixed-mode code I developed for VS2003 in C++, but never ran because of the loader-lock bug, and I first wanted to move that code to VS2005 and try to build and run it.

However because of this bug, and the assumption that MS will not be too interested in fixing bugs in Managed C++ code generation,

IMHO they cannot fix it, because it's a runtime restriction. They could however throw an error at compilation time.

I am forced to change my code to use C++/CLI immediately.

IMHO it would be the same in managed C++ if you change your code. But anyways directly porting to C++/CLI is the better way to go.

Changing my sample to use C++/CLI I see that everything works perfectly.

For me this bug is the final chapter of the Managed C++ fiasco, including the destructive loader-lock bug in VS2003, other bugs I reported to MS regarding Managed C++ and VS2003, and now this horrendous bug with Managed C++ and VS2005.

The bug is, that the compiler doesn't throw an error at compilation time. A nested class seems not to be allowed anymore to access private members of a managed class. This is true for C++/CLI as it's true for managed C++.

[...]

Andre
.

Relevant Pages

  • Re: statically compiled files left over after a make world
    ... The bug did ... bootstrap the compilation of the various loadable modules. ... would gain the attacker nothing more than he could gain by simply ...
    (FreeBSD-Security)
  • Re: Signed zeros: is this a bug?
    ... Looks to me like you've found a bug with the parser/compiler: ... appear within the same "unit of compilation" (expression, function, ... errant "peephole optimizer" pass which tries to roll multiple ...
    (comp.lang.python)
  • Re: Warning on migrating to ATMega8515 - eeprom problem
    ... >> Yes, probably a bug, but it is questionable if it is serious. ... >> It is generally a good practice to avoid relying on reset values. ... Conditional compilation is one way. ... You can thus run the compiled result of the same source code on both CPUs ...
    (comp.arch.embedded)
  • IBM/Absoft bug on Mac OS-X
    ... I have run across a bug using the IBM and Absoft compilers (the latest ... 1501-510 Compilation successful for file test_mod.f. ...
    (comp.lang.fortran)