Re: [AD] MSVC 8 cl flags

[Chris <chris.kcat@xxxxxxxxxx>]

On Friday 19 August 2005 05:23 pm, Michal Molhanec wrote:
> Chris wrote:
> > As I understand it, only Microsoft's implementation of libc is unsafe.
> > From what I've heard, other systems do not have this problem.
>
> How can be gets() implemented safely?

I'm talking about the ones that don't have any known problems. Yes, certain 
functions are inherently unsafe. But memcpy? fopen? printf? As long as you 
use them properly, how are they unsafe? You can make anything unsafe if you 
don't use it right. Watch, I can crash snprintf:

char buf[100];
const char *str = "%s copies a string from va_args into your string when 
printing it\n";
snprintf(buf, sizeof(buf), str); // Crash

> > As well, the "old"
> > functions and the new ones that replace them have the same prototype,
> > just with a different name
>
> Often they have different prototype.

The ones I looked up didn't. Which ones do? I'm not talking about things like 
deprecating sprintf in favor of snprintf. But deprecating memcpy in favor of 
memcpy_s, fopen in favor of fopen_s. Things like that.

> > (so they could've just easilly fixed the problems in
> > the "unsafe" functions, and not have to make new functions for it).
>
> As their behaviour is different from standard's one its much better to
> change their name, isn't it?

True. But even though Microsoft doesn't say what the new incompatiblities are, 
I'd still say there was no reason to deprecate the original functions. You 
deprecate things that are ultimately going to be removed, or at the very 
least things that aren't going to be actively supported. So, if Microsoft is 
planning on removing (or removing support for) a major part of standard libc, 
where would that leave us? Why continue supporting something that has no 
intention of supporting us?

Who knows, maybe if enough people don't fall into this trap of using the new 
"secure" functions, Microsoft will rethink this idea, un-deprecate these 
functions, and we could then continue working with MSVC.

> > I haven't
> > been able to find any info on what the problem is, other than MSDN
> > claiming they're "unsafe" and should use other functions isntead.
>
> http://msdn2.microsoft.com/library/8ef0s5kh(en-us,vs.80).asp

The page was an invalid link. However, I was able to follow the links to find 
the information. It seems the problem could potentially be worse than I 
originally thought.

"Many existing functions now set errno where they did not before."

Does this mean functions could be setting errno where the standard doesn't 
specify such? Or that they're now properly setting errno where they weren't 
before? The page doesn't explain.

"The typedef errno_t with type integer was added. errno_t is used whenever a 
function return type or parameter deals with error codes from errno. errno_t 
replaces errcode."

Sounds nice. Now functions that are supposed to return an int-type errno-code, 
are going to return a errno_t-type, instead. Although errno_t is typedef'd to 
an int, it can still cause problems with compilers since they don't have the 
same type name (especially applicable to C++).


And I still find the idea of these functions a bit questionable. According to 
this page, they were made because "These functions handle errors in a better 
way and enforce stricter controls on buffers to help avoid common security 
flaws." Besides not defining what "a better way" is, or the kinds of 
"security flaws" they're addressing, don't you think if someone was going to 
write malicious code they'd just use the old functions, which are still 
there? And for code that works with external data, you just need to take 
caution that you're properly handling the data. If anything, I can see this 
causing people to become lazy about safety and security checks ("oh, don't 
worry, the system will take care of it for me"), and leave people with older 
systems (or non-Windows system for those who're gracious enough to write 
simple wrappers) vulnerable, and forcing them to upgrade.. instead of 
encouraging people to write secure code in the first place.

If you wanted, you could still completely ignore the intent. This is going to 
cause otherwise standard code to be inhernetly incompatible with non-Windows 
systems. Now, someone new to programming who's introduced via MSVC 8+, won't 
even write a command-line-based Hello World program without using Windows 
code. They'll be taught to use:

#include <stdio.h>
int main()
{
   printf_s("Hello World!\n");
   return 0;
}

..and suddenly, they write Windows-specific code.

And someone mentioned why C99 didn't deprecate these functions that Microsoft 
is taking it upon themselves to. Regardless of safety, it wouldn't have 
mattered what C99 did, since Microsoft has no plans on giving it any real 
support.