There is a way to allocate "typed" memory through Boehm. If you always use the "right" allocation
routines, no memory will be scanned which doesn't need to be.
That statement is false. The Boehm collector always scans the stack conservatively; it is neither type-accurate nor liveness-accurate. So memory which is pointed to from the stack can be scanned unnecessarily.
> If your code is entirely managed, you code is 'safe' AFAICT.
No, that's wrong. Managed code is not necessarily safe. To be safe, the code must also be "verifiable". See my other article in this thread.
AFAIK, for source code written in C++ with Microsoft's managed extensions, the IL code generated by the MSVC compiler will not be verifiable in general, so although you can write code which is managed, it won't be safe.
I'm one of the Mercury developers who was involved
in porting Mercury to.net. "Chokolad" is basically correct on this point.
There's two separate concepts involved here:
managed code
safe (verified) code
"Managed code" provides information to the run-time system that lets the run-time system trace the stack. Managed code is required for garbage collection, but managed code is not necessarily safe.
Verified code is code which is managed and which in addition passes the runtime loader's verification checks. Verified code is safe.
Microsoft's.net supports
both of these: you can have code which is
managed but not verifiable, or you can have
code which is managed and verifiable.
Code which is only managed but not verifiable
is not safe, and so can't be run unless trusted.
So for unverifiable code the security model is
like the security model for Active-X controls
(with all that that implies...).
Code which is verifiable can be run in a sandbox
like Java applets, and so it can be safe to run
untrusted code in a sandbox as long as it is
verifiable.
AFAIK you are correct that Microsoft's managed C++ code will not be verifiable, and hence not safe. If you want to write code which is safe, then AFAIK you will need to use a different language, e.g. C# or Mercury.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically TERMINATE your rights under this License.
So RMS is not "inventing special rules after the fact just to bash KDE", as the KDE authors wrote.
That rule has been around as long as the GPL
has existed. The KDE authors would do better to
read the GPL rather than flaming RMS.
Only one of the developers of C-- is at Microsoft Research. The others are at Harvard (Norman Ramsey), Glasgow (Fermin Reig), Oregon Graduate Institute (Thomas Nordin), and other universities. The only C-- implementation comes from OGI, not MS.
1.using the services of anelectronic mail service provider in contravention of the authority granted by or in violation of the policies set by the electronic mail service provider; 2.falsifying e-mail transmission information in connection with the transmission of unsolicited bulk e-mail; 3.selling or distributing software which makes possible the transmission of false e-mail with the intent to facilitate the transmission of false e-mail.
That is not exactly what is made illegal. That is just the summary. What is in fact made illegal is more precise than that. For example, the new wording which disallows point 1 above is restricted to the case when you are sending unsolicited bulk email.
That statement is false. The Boehm collector always scans the stack conservatively; it is neither type-accurate nor liveness-accurate. So memory which is pointed to from the stack can be scanned unnecessarily.
Doug forgot to enable the Mercury compiler's optimizations! He's fixed that now, so we now do a lot better than before.
Nonetheless, I think the Mercury folks took a prize last year though, didn't they?
We came fourth, which was good enough to rate a mention, but not good enough for a prize.
No, that's wrong. Managed code is not necessarily safe. To be safe, the code must also be "verifiable". See my other article in this thread.
AFAIK, for source code written in C++ with Microsoft's managed extensions, the IL code generated by the MSVC compiler will not be verifiable in general, so although you can write code which is managed, it won't be safe.
There's two separate concepts involved here:
"Managed code" provides information to the run-time system that lets the run-time system trace the stack. Managed code is required for garbage collection, but managed code is not necessarily safe.
Verified code is code which is managed and which in addition passes the runtime loader's verification checks. Verified code is safe.
Microsoft's .net supports
both of these: you can have code which is
managed but not verifiable, or you can have
code which is managed and verifiable.
Code which is only managed but not verifiable
is not safe, and so can't be run unless trusted.
So for unverifiable code the security model is
like the security model for Active-X controls
(with all that that implies...).
Code which is verifiable can be run in a sandbox
like Java applets, and so it can be safe to run
untrusted code in a sandbox as long as it is
verifiable.
AFAIK you are correct that Microsoft's managed C++ code will not be verifiable, and hence not safe. If you want to write code which is safe, then AFAIK you will need to use a different language, e.g. C# or Mercury.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically TERMINATE your rights under this License.
So RMS is not "inventing special rules after the fact just to bash KDE", as the KDE authors wrote.
That rule has been around as long as the GPL
has existed. The KDE authors would do better to
read the GPL rather than flaming RMS.
- Lisp
- Scheme
- ML
- Eiffel
- Sather
- Smalltalk
- Ada
- Pascal
- Oberon
- Python
- COBOL
just to mention some of the more well known ones, and in addition compilers to Java/JVM for the following languages- Haskell
- Mercury
are under development. All in all there are more than 130 different tools that compile to Java and/or the JVM. See the full list.Only one of the developers of C-- is at Microsoft Research. The others are at Harvard (Norman Ramsey), Glasgow (Fermin Reig), Oregon Graduate Institute (Thomas Nordin), and other universities. The only C-- implementation comes from OGI, not MS.
Under the GPL, they don't have to release
source code unless they distribute it.
No, even copying the WHOLE of a copyrighted work
for purposes OTHER than commentary can sometimes
be "fair use".
You should read the judgement in the Sega vs Accolade
case that was linked to in the article,
in particular paragraphs 29 onwards
(the second half).