Safe C library

[jacob navia]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

jacob

 

[Christopher Layne]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

jacob

"My team owns the Visual C++ Libraries, which includes some of the newest code
in the developer division (such as ATL Server) as well as some of the oldest
code in the product (such as the CRT). When we looked at the code, we saw
some large differences in coding standards as common practice has improved in
the last 20 years. One thing that stood out was that some of the older code
was written at a time when every extra byte of code was precious, and thus
lacked full validation of all parameters.

The newer code is littered with assertions and checks, and we've found that
these really help debugging. Increasingly, we've focused on making sure that
the retail code is just as robust as our debug code in the face of unexpected
conditions. These checks aren't just for debugging any more—they also make
the library code safer. A key part of the Safe Libraries initiative has been
to add validation code to most of the library functions that has impact on
both debug and retail code. For example, if you pass the libraries invalid
flags, they will now assert and tell you about your bug."

Otherwise known as:

The new libraries will be slower.

 

[Ben Bacarisse]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

This is one the most preposterous documents I've seen[1]. It would
make an interesting tutorial if it was as an essay from and
undergraduate, but as a serious proposal from a major software
company? Might it actually get in?

They start from the point of view that it is safer to pass the
destination size around than to subtract and use the "strn*"
functions. It may be one operation shorter (in some cases), but
safer? And so much safer that a whole new set of functions should be
added to standard C?

It references code fragments to show how much better this stuff is.
For example:

// Original
wchar_t dest[20];
wcscpy(dest, src); // compiler warning
wcscat(dest, L"..."); // compiler warning

can be improved with their shiny new _s functions. Duh! They could
show how some correct code can be made a little shorter, but it seems
disingenuous to start with such incorrect nonsense and "improve" it.

But the oddest part of all is that none of the things suggested (in
the part I read, at least) is at all hard to do in standard C.
I.e. any programmer who prefers that style will already have these
functions a library. For example, strnlen_s is a one-liner: testing
that is not passed NULL and then calling memchr. And, of course, if
you don't like that style it is perfectly possible to write safe code
without these extras.

I may have missed the real "meat" of the proposal, so I should say
that it is only the cited rationale that is daft. But if there is
meat to this, they miss a trick by not making it clear up front.

[1] It includes C++ stuff that I did not look into and, yes, it is
probably troll-bait, but it is Sunday and I don't have to walk the dog
for a bit.

 

[Christopher Layne]

This is one the most preposterous documents I've seen[1]. It would
make an interesting tutorial if it was as an essay from and
undergraduate, but as a serious proposal from a major software
company? Might it actually get in?

Microsoft.

 

[Malcolm McLean]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

I've just shelled out over 500 pounds on a nice new dual core machine with
Windows Vista. I installed my version of Visual Studio and, guess what, the
C library is the safest imaginable. The compiler won't link in any code at
all or produce an executable. Such heights of security could not be achieved
by any other company.

 

[Cesar Rabak]

Ben Bacarisse escreveu:

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

This is one the most preposterous documents I've seen[1]. It would
make an interesting tutorial if it was as an essay from and
undergraduate, but as a serious proposal from a major software
company? Might it actually get in?

They start from the point of view that it is safer to pass the
destination size around than to subtract and use the "strn*"
functions. It may be one operation shorter (in some cases), but
safer? And so much safer that a whole new set of functions should be
added to standard C?

It references code fragments to show how much better this stuff is.
For example:

// Original
wchar_t dest[20];
wcscpy(dest, src); // compiler warning
wcscat(dest, L"..."); // compiler warning

can be improved with their shiny new _s functions. Duh! They could
show how some correct code can be made a little shorter, but it seems
disingenuous to start with such incorrect nonsense and "improve" it.

But the oddest part of all is that none of the things suggested (in
the part I read, at least) is at all hard to do in standard C.
I.e. any programmer who prefers that style will already have these
functions a library. For example, strnlen_s is a one-liner: testing
that is not passed NULL and then calling memchr. And, of course, if
you don't like that style it is perfectly possible to write safe code
without these extras.

I may have missed the real "meat" of the proposal, so I should say
that it is only the cited rationale that is daft. But if there is
meat to this, they miss a trick by not making it clear up front.

The "meat" is in the Title: "Repel Attacks on Your Code with the Visual
Studio 2005 Safe C and C++ Libraries"

[1] It includes C++ stuff that I did not look into and, yes, it is
probably troll-bait, but it is Sunday and I don't have to walk the dog
for a bit.

No, it is a consequence that for a lot of hosted implementations, the
compiler industry made a choice to sell a "C/C++" compiler as a bundle
of a C compiler plus a C++ compiler.

 

[Cesar Rabak]

jacob navia escreveu:

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

Let's add then:
http://www.research.avayalabs.com/g...er=LabsProjectDetails&View=LabsProjectDetails
http://directory.fsf.org/libsafe.html

 

[Chris Hills]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

This is one the most preposterous documents I've seen[1]. It would
make an interesting tutorial if it was as an essay from and
undergraduate, but as a serious proposal from a major software
company? Might it actually get in?

Unfortunately yes.

I argued against it from the fist time I saw it in 2004.
BTW it covers all 2000 functions in the C library.....

 

[Chris Hills]

We have discussed often the proposition from Microsoft
for a safer C library.

It is NOT the "safer C" library.

This is for 2 reasons.
1 The library is not safer
2 the name "safer C" belongs to some one else.

BTW they are actually calling it the "Safe C Library"

 

[Cesar Rabak]

Malcolm McLean escreveu:

I've just shelled out over 500 pounds on a nice new dual core machine with
Windows Vista. I installed my version of Visual Studio and, guess what, the
C library is the safest imaginable. The compiler won't link in any code at
all or produce an executable. Such heights of security could not be achieved
by any other company.

Code that never gets compiled is the safest of all!?

 

[Richard Heathfield]

Chris Hills said:

It is NOT the "safer C" library.

This is for 2 reasons.
1 The library is not safer
2 the name "safer C" belongs to some one else.

BTW they are actually calling it the "Safe C Library"

They're borrowing a trick from HM Government - getting rid of the difficult
bit by putting it in the title. It does less harm there.

 

[artifact.one]

1 The library is not safer

Perhaps it's some cynical marketing scheme whereby Microsoft
come out and say "Look, even with a safe library, it's no safer.
Why don't you convert all your legacy code to C#?"

MC

 

[jacob navia]

jacob navia a écrit :

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

jacob

None of the answers addresses any of the problems that this software
tries to fix.

Just the usual:

"We are the greatest" "It will be slower", "I dislike Microsoft"
and similar.

Christopher Layne says:

"The new libraries will be slower".

He doesn't explain what measurements he did to arrive at this
conclusion.

Ben Becaisse says:
But the oddest part of all is that none of the things suggested (in
the part I read, at least) is at all hard to do in standard C.

Obvious. But precisely, it is the first time somebody takes the
time to make a proposal for a STANDARD set of those functions, so
users do not have to reinvent the wheel.

Malcolm McLean complains that his compiler doesn't work. What this
has to do with the proposal is impossible to know. He doesn't explain
anything.

Cesar Rabak has the only substantive contribution to this
thread by pointing that gnu has a library that tries to address
the memory overflow problem.

This is an interesting contribution. I looked
at the library and it tries to figure if the stack return address will
be touched by functions like printf... It is nice, and I think I could
add some of that code to the printf implementation of lcc-win32 and
lcc-win64.

The other "contributions" (heathfield et al) are best ignored.

I am not for this proposal, even if lcc-win32 has implemented
Microsoft's proposal. The solution is to get rid of zero terminated
strings, but it is surely a step in the right direction.

jacob

 

[artifact.one]

The other "contributions" (heathfield et al) are best ignored.

Grow a sense of humour please.

MC

 

[Kenny McCormack]

Grow a sense of humour please.

He does. It is heathfield (and others, but heathfield is the archetype)
who has none.

 

[artifact.one]

He does. It is heathfield (and others, but heathfield is the archetype)
who has none.

Well I can't discount that, I don't know either of them. But the only
thing I ever see from Jacob Navia is a monologue to an omnipresent
third party as soon as anybody brings up a contrary point of view
(even in jest).

Frankly I'm not in the slightest bit interested in a discussion of
a 'safe C library' and even less interested in a discussion about
the merits and problems of zero terminated strings (that's
where this discussion is inevitably heading, after all). I doubt
I'll comment on this thread again.

MC

 

[Default User]

On Feb 4, 6:45 pm, (e-mail address removed) (Kenny McCormack)
wrote:

Well I can't discount that

Go ahead. Kenny is one of the resident trolls. He supports Navia only
to cause trouble in the group. It's best to ignore him.




Brian

 

[Mark McIntyre]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

This is one the most preposterous documents I've seen[1].

Bear in mind that many vendors are reknowned for wanting to persuade
you to use their proprietary extensions, in the hopes of locking you
in.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Code that never gets compiled is the safest of all!?

Of course - if you can't compile it, you can't run it...

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Joe Wright]

We have discussed often the proposition from Microsoft
for a safer C library.

A rationale document is published here by one of the members of
the design team at microsoft:
http://msdn.microsoft.com/msdnmag/issues/05/05/SafeCandC/default.aspx

This is one the most preposterous documents I've seen[1]. It would
make an interesting tutorial if it was as an essay from and
undergraduate, but as a serious proposal from a major software
company? Might it actually get in?

Unfortunately yes.

I argued against it from the fist time I saw it in 2004.
BTW it covers all 2000 functions in the C library.....

There are 2,000 functions ?