<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Andreas Davour wrote:
<blockquote
cite="midPine.LNX.4.64.0712162322510.25158@Psilocybe.Update.UU.SE"
type="cite">
<pre wrap="">On Sun, 16 Dec 2007, dave porter wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Then a couple of days ago I ran across a comment on the microsoft site that
the
fopen instruction had been deprecated - and that one should use the fopen_s
instruction instead - unless one wanted to share the file...
</pre>
</blockquote>
<pre wrap="">Forget it. Microsoft thinks you shouldn't use that function, but that
doesn't mean you shouldn't use the function.
MS has correctly observed that some C RTL functions (say, strcpy) are
unsafe in the hands of idiots. MS has therefore introduced functions
with better behaviour and thinks everyone should use those instead.
Sure, but you no longer have portable code. And there's no gain if
you weren't using the original function idiotically in the first place.
Apparently, the 'security' angle of fopen_s is that if you feed
it incorrect arguments, it calls an invalid parameter handler rather
than immediately letting the MMU execption loose.
</pre>
</blockquote>
<pre wrap=""><!---->
I wouldn't say it is such a bad idea after all. The intention with this
is obvious, MS lock in. But, considering the track record we have with
buffer overflow errors and the like I think the idea is a great one and
long over due. It should have been done with the last C standard, and
not as a way by MS to force lock in, though.
If we should start calling people idiots we migth never stop, but I then
point the finger towards Richie. Whatever you might think, Dave, C *has*
a security problem.
/Andreas</pre>
</blockquote>
While it doesn't matter much what I think on the subject, I think:<br>
<ul>
<li>There are flaws in the C RTL spec. Don't get me started on
additional signals not being queued while a signal handler is
executing. fopen() probably doesn't allow for passing enough
information between the program and the underlying environment. I can't
really get too worked up about the shared access issue, however. If you
are in an environment where misbehaving programs running in the same
user context are a problem you've already lost the security battle.</li>
<li>Microsoft probably has little motivation to maintain source-level
compatibility with competing systems. Some would say that they have a
motivation to actively break source compatibility. I'm not so sure.
Maintaining compatibility requires effort. Incompatibility can result
just as easily from lack of trying as from trying to be incompatibility.<br>
</li>
<li>Microsoft made design choices in their implementation of the
standard C RTL. Some of these seem to have unfortunate performance
consequences for SIMH in some circumstances. Some of these may have
security consequences, I really don't know. In any event Microsoft has
decided to mitigate these consequences with a non-standard API, rather
than correcting the problems with the standard API.</li>
</ul>
Given all that, which we can't do anything about, we should concentrate
on what we can do something about. I'll go back to saying that if using
the non-standard API provides sufficient benefits for Windows users
than a little conditional compilation or two versions of a small module
are a reasonable course to take.<br>
</body>
</html>