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/is...C/default.aspx

jacob

[Christopher Layne]

jacob navia wrote:

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/is...C/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]

jacob navia <ja***@jacob.remcomp.frwrites:

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/is...C/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.

--
Ben.

[Christopher Layne]

Ben Bacarisse wrote:

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]

"jacob navia" <ja***@jacob.remcomp.frwrote in message

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/is...C/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:

jacob navia <ja***@jacob.remcomp.frwrites:

>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/is...C/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/is...C/default.aspx

Let's add then:
http://www.research.avayalabs.com/gc...ProjectDetails
http://directory.fsf.org/libsafe.html

[Chris Hills]

In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites

>jacob navia <ja***@jacob.remcomp.frwrites:

>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/is...C/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 Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Cesar Rabak]

Malcolm McLean escreveu:

"jacob navia" <ja***@jacob.remcomp.frwrote in message

>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/is...C/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.

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

[Chris Hills]

In article <45**********************@news.orange.fr>, jacob navia
<ja***@jacob.remcomp.frwrites

>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"
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

In article <45**********************@news.orange.fr>, jacob navia
<ja***@jacob.remcomp.frwrites

>>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"

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[artifact.one]

On Feb 4, 5:48 pm, Chris Hills <[e-mail]:

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/is...C/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]

On Feb 4, 6:32 pm, jacob navia <[e-mail]:

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

Grow a sense of humour please.

MC

[Kenny McCormack]

In article <11**********************@m58g2000cwm.googlegroups .com>,
<ar**********@googlemail.comwrote:

>On Feb 4, 6:32 pm, jacob navia <[e-mail]:

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

Grow a sense of humour please.

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

[artifact.one]

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

In article <[e-mail] .com>,

<[e-mail]:

On Feb 4, 6:32 pm, jacob navia <[e-mail]:

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

Grow a sense of humour please.

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]

ar**********@googlemail.com wrote:

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

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

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]

On Sun, 04 Feb 2007 14:14:43 +0000, in comp.lang.c , Ben Bacarisse
<be********@bsb.me.ukwrote:

>jacob navia <ja***@jacob.remcomp.frwrites:

>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/is...C/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]

On Sun, 04 Feb 2007 16:01:14 -0200, in comp.lang.c , Cesar Rabak
<cs*****@yahoo.com.brwrote:

>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]

Chris Hills wrote:

In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites

>jacob navia <ja***@jacob.remcomp.frwrites:

>>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/is...C/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 ?

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[websnarf]

On Feb 4, 10:32 am, jacob navia <[e-mail]:

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/is...C/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.

Every per-character inner loop now checks for both a '\0' terminator
and a length count down. Because of the extra code size, many of
these library functions will fail heuristics for inlining (or
otherwise increase L1 I-Cache pressure if it inlines aggressively.)

This shows pure design incompetence on Microsoft's part. It is ok to
sacrifice inlinability if you accomplish far more functionality (such
as Bstrlib does) so that ultimately fewer calls are made and your
inner loops that need to be called into are doing more work per
cycle. Instead MS chose to make exact analogues to the ridiculously
poorly designed std library functions. So on the performance issue
they do nothing but incurr extra overhead that is unrecoverable.

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.

Except that this misrepresents the real issue from the user's point of
view. Whether you are using TR 24731 or just the standard functions,
the programmer is in exactly the same boat -- they can do extra work
for each string operation to ensure the buffer lengths are correct
(and do this calculation potentially incorrectly) and write code
accordingly or they can just be lazy and do some default thing that
works (like stuffing RSIZE_MAX as the parameter for the length in TR
24731.) Actually, quite ironically, you could actually argue that the
library would be safer if only RSIZE_MAX was *NOT* defined.

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.

Hmmm ... so long as they mischaracterize the real problem, it just
looks like a misdirected effort. And its going to make people sour to
the whole thing. I mean people are going to be decieved into thinking
TR 24731 is useful for reducing security problems, so they waste time
porting to it, and of course, will see absolutely no change in the
frequency of security problems (which doesn't matter to MS, who will
claim victory by the process of PR no matter what) and will conclude
that C has to be tossed because "the best effort" did not save the
poor C language.

Remember, my big issue, is that these functions do not actually do
anything to promote safety. This is further revealed by the fact that
they put "restrict" all over the parameters indicating that they don't
give a rats ass about the aliasing problem. When users use
"restrict", they are expecting performance, but when a *LIBRARY
VENDOR* uses "restrict" they are just absolving themselves of blame.
But for a general library pretending to be secure? You solve the
aliasing problem, otherwise you don't call yourself a security
solution. Its just continuing to propogate the problem.

The C standard committee has demonstrated that its just plain too
stupid to see any of this. I can only hope that the C++ committee is
smarter and simply rejects the whole proposal out of hand. Someone
has to slap the faces of these idiots.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Richard Heathfield]

Joe Wright said:

Chris Hills wrote:

<snip>

>BTW it covers all 2000 functions in the C library..... :-)

There are 2,000 functions ?

No, its claim is ludicrous - hence Chris's smiley.

C89 requires hosted implementations to provide the assert, setjmp, va_arg,
va_end, and va_start macros, which could be regarded as function-like if you
don't look too closely, and, by my count, 140 functions:

abort abs acos asctime asin atan atan2 atexit atof atoi
atol bsearch calloc ceil clearerr clock cos cosh ctime difftime
div exit exp fabs fclose feof ferror fflush fgetc fgetpos
fgets floor fmod fopen fprintf fputc fputs fread free freopen
frexp fscanf fseek fsetpos ftell fwrite getc getchar getenv gets
gmtime isalnum isalpha iscntrl isdigit isgraph islower isprint ispunct isspace
isupper isxdigit labs ldexp ldiv localeconv localtime log log10 longjmp
malloc mblen mbstowcs mbtowc memchr memcmp memcpy memmove memset mktime
modf perror pow printf putc putchar puts qsort raise rand
realloc remove rename rewind scanf setbuf setlocale setvbuf signal sin
sinh sprintf sqrt srand sscanf strcat strchr strcmp strcoll strcpy
strcspn strerror strftime strlen strncat strncmp strncpy strpbrk strrchr strspn
strstr strtod strtok strtol strtoul strxfrm system tan tanh time
tmpfile tmpnam tolower toupper ungetc vfprintf vprintf vsprintf wcstombs wctomb

I know C99 went a bit loopy, but I cannot believe it added another 1860
functions to the standard library.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <_J******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>I know C99 went a bit loopy, but I cannot believe it added another 1860
functions to the standard library.

Franz Lisp (the implementation of Lisp that came with Berkeley Unix)
had an infinite number of built-in functions.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Ben Bacarisse]

Mark McIntyre <ma**********@spamcop.netwrites:

On Sun, 04 Feb 2007 14:14:43 +0000, in comp.lang.c , Ben Bacarisse
<be********@bsb.me.ukwrote:

>>jacob navia <ja***@jacob.remcomp.frwrites:

>>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/is...C/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.

True enough, but from what I saw of the C stuff (there may have been
more) the shackles would be paper ones, since nothing seemed to be
more than a few hours work to write in portable C. Maybe the printf_s
stuff is harder -- I did not look at it all.

--
Ben.

[CBFalconer]

Chris Hills wrote:

Ben Bacarisse <be********@bsb.me.ukwrites

>jacob navia <ja***@jacob.remcomp.frwrites:

>>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/is...C/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..... :-)

This is a landmark. One of the few times you and I agree :-)

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[CBFalconer]

jacob navia wrote:

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/is...C/default.aspx

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.

All of which seem to be accurate, with the only possible exception
being the first. That is reserved for Mohammed Ali and myself. I
think the proposal is so stupid that it doesn't even include
strlcpy/cat, which is a well thought out improvement.

Microsoft would have been better advised to spend their time
implementing C99, but I suppose that was beyond them or didn't fit
their alter and destroy philosophy.

Finally, who wants to squander their typing time reaching for the
shift and '_' keys? The latter is not in the normal repetoire of
touch-typists, where even numerals are a nuisance. This is
probably part of the MS campaign to foist gooey rodentia upon us.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Chris Hills]

In article <BK******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

>Chris Hills wrote:

>In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites

>>jacob navia <ja***@jacob.remcomp.frwrites:

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/is...C/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 ?

AFAIR there are 483 in the ISO standard library... The remainder are
in the MS library.

What *will* happen is MS will say that "their" SAFE-C library is ISO
approved. Also the only people who can support the full ISO-C SAFE.
Library is MS "everyone else is non-standard"

This is why I was not happy when I first saw it in 2004.

It will mean by implication and marketing that MS has a standards
conforming SAFE library and everyone else has an unsafe non conforming
library....

The response from some of the panel members was they were only concerned
with the functions in the standard library and if MS wanted to do more
that was up to them,

How many MS programmers does it take to change a light bulb?
NONE.
MS just declares darkness the new standard.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

In article <BK******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

>>Chris Hills wrote:

<snip>

>>BTW it covers all 2000 functions in the C library..... :-)

There are 2,000 functions ?

AFAIR there are 483 in the ISO standard library...

If that is true and my count of 140 in C89 is correct (and if it isn't,
it's at least approximately right), C99 must have added well over 300
functions, more than trebling the size of the library. I found that
hard to believe, so I went and had a look. I didn't actually count
them, but it looks about right, yes. I still find it hard to believe,
but it does appear to be true.

Blech.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[santosh]

Chris Hills wrote:

In article <BK******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

Chris Hills wrote:

In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites
jacob navia <ja***@jacob.remcomp.frwrites:

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/is...C/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 ?

AFAIR there are 483 in the ISO standard library... The remainder are
in the MS library.

What *will* happen is MS will say that "their" SAFE-C library is ISO
approved. Also the only people who can support the full ISO-C SAFE.
Library is MS "everyone else is non-standard"

This is why I was not happy when I first saw it in 2004.

It will mean by implication and marketing that MS has a standards
conforming SAFE library and everyone else has an unsafe non conforming
library....

How can Microsoft's C library be conforming if it doesn't yet support
all of C99's requirements? Also, if the "Safe C" functions do get
approved by ISO, (touch wood), doesn't it mean that other implementors
would add them to their libraries too? How then will MS's library
alone be a "Safe" C library, let alone a conforming one?

Forgive my ignorance of ISO methodologies, if any.

[Bryan]

On 4 Feb, 18:51, [e-mail] wrote:

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

In article <[e-mail] .com>,

<[e-mail]:

>On Feb 4, 6:32 pm, jacob navia <[e-mail]:
>The other "contributions" (heathfield et al) are best ignored.

>Grow a sense of humour please.

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.

<snip>

I know Rich, and he does have a sense of humour, he's just not a big
fan of idiots.
The "difficult bit in the title" post should make it obvious to anyone
who knows the reference.

P.S. Hi Rich, how's stuff ?

[jacob navia]

Bryan a écrit :

<snip>

I know Rich, and he does have a sense of humour, he's just not a big
fan of idiots.

P.S. Hi Rich, how's stuff ?

If he doesn't like idiots, as you say, why do you
expect an answer?

:-)

[Bryan]

On 5 Feb, 12:33, jacob navia <[e-mail]:

Bryan a écrit :

<snip>

I know Rich, and he does have a sense of humour, he's just not a big
fan of idiots.

P.S. Hi Rich, how's stuff ?

If he doesn't like idiots, as you say, why do you
expect an answer?

:-)

What makes you think I expect an answer ?

;-)

[Richard Heathfield]

[attribs abbrev'd]
Bryan said:

artifact wrote:

>Kenny McCormack wrote:

artifact wrote:

<snip>

>Grow a sense of humour please.

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.

<snip>

I know Rich, and he does have a sense of humour,

Oh no I don't!

he's just not a big fan of idiots.

Actually, I don't have a problem with idiots per se. I just don't think
they should try to write computer programs. But that doesn't seem to
stop them, alas.

The "difficult bit in the title" post should make it obvious to anyone
who knows the reference.

Indeed - but so few people nowadays have the benefit of a classical
education. I blame the Government.

P.S. Hi Rich, how's stuff ?

At this point, I think we'd better take it to email. This is hardly the
place to share even a virtual beer. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Hills]

In article <W-******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

>In article <BK******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

>>>Chris Hills wrote:

<snip>

>>>BTW it covers all 2000 functions in the C library..... :-)

There are 2,000 functions ?

AFAIR there are 483 in the ISO standard library...

If that is true and my count of 140 in C89 is correct (and if it isn't,
it's at least approximately right), C99 must have added well over 300
functions, more than trebling the size of the library. I found that
hard to believe, so I went and had a look. I didn't actually count
them, but it looks about right, yes. I still find it hard to believe,
but it does appear to be true.

Now you know why I get pissed of when people here piously say we only
do "Standard" C here but include K&R1, K&R2, ANSI 89 ISO C90,
93,95,96, 99 all and any National versions and any committee draft (of
any vintage) as "Standard C"

Then scream at any one who mentions anything that is "not standard C"
when 95% of the real programming community use C as per a subset of
some of the standards above with extensions.

Well, when MS get their "safe c" though you will find that all the MS
programmers will KNOW that the MS library is "Standard C" (because of
the TR). They will also know that by definition anyone not using the MS
C library will not be standard or safe....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Hills]

In article <11*********************@p10g2000cwp.googlegroups. com>,
santosh <sa*********@gmail.comwrites

>Chris Hills wrote:

>In article <BK******************************@comcast.com>, Joe Wright
<jo********@comcast.netwrites

>Chris Hills wrote:
In article <87************@bsb.me.uk>, Ben Bacarisse
<be********@bsb.me.ukwrites
jacob navia <ja***@jacob.remcomp.frwrites:

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/is...C/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 ?

AFAIR there are 483 in the ISO standard library... The remainder are
in the MS library.

What *will* happen is MS will say that "their" SAFE-C library is ISO
approved. Also the only people who can support the full ISO-C SAFE.
Library is MS "everyone else is non-standard"

This is why I was not happy when I first saw it in 2004.

It will mean by implication and marketing that MS has a standards
conforming SAFE library and everyone else has an unsafe non conforming
library....

How can Microsoft's C library be conforming if it doesn't yet support
all of C99's requirements?

It is as good as most and better than quite a few I have been told by
people who should know.

>Also, if the "Safe C" functions do get
approved by ISO, (touch wood)

I hope not as they are not really "safe" as such

>, doesn't it mean that other implementors
would add them to their libraries too?

Yes... So you add them to an 8051 library.... The 8051 is an 8 bit micro
that makes you about 30% of the MCU our in the world today...

The point is apart from the fairly narrow PC programming circles no one
wants or needs the MS library. There are many 8 and 16 bit systems put
there where this library is pointless.

How then will MS's library
alone be a "Safe" C library, let alone a conforming one?

Very good question

>Forgive my ignorance of ISO methodologies, if any.

Actually this will be a TR or ISO Technical Report. This is NOT part of
the standard but as MS people will tell you most TR's eventually become
part of the standard. However whilst most do get in some do not.

I had reports of MS people suggesting that "it will be in the next
standard" However this is her-say I have not seen that in print or had
it said to me personally. Though they have crossed that line on the
C++ C++/CLI bun fight AFAIK

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

<snip>

>
Well, when MS get their "safe c" though you will find that all the MS
programmers will KNOW that the MS library is "Standard C" (because of
the TR). They will also know that by definition anyone not using the
MS C library will not be standard or safe....

Sure, but then many MS programmers KNOW that main returns void, that
fflush(stdin) clears to newline, that gets is a perfectly acceptable
input technique, and so on and so forth. I'm not overly impressed by
the "knowledge" of such MS programmers.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Hills]

In article <nf******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

<snip>

>>
Well, when MS get their "safe c" though you will find that all the MS
programmers will KNOW that the MS library is "Standard C" (because of
the TR). They will also know that by definition anyone not using the
MS C library will not be standard or safe....

Sure, but then many MS programmers KNOW that main returns void, that
fflush(stdin) clears to newline, that gets is a perfectly acceptable
input technique, and so on and so forth. I'm not overly impressed by
the "knowledge" of such MS programmers.

Me neither but if enough of them believe it is the standard and MS
behave like it is we have the same situation as BASIC.

ISO Obsoleted the ISO BASIC standard a few years ago because the whole
world ignored it and uses VB instead.

ISO C is hardly alive and well now. Few C99 implications. No one really
that bothered or since 1999 they would have fully implemented it.

The other problem is that globally these days most cs students learn MS
languages
..


--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Richard Heathfield]

Chris Hills said:

<snip>

ISO C is hardly alive and well now.

C89 thrives. C99 is dead in the water.

Few C99 implications. No one
really that bothered or since 1999 they would have fully implemented
it.

Yes, because C99 was a fairly pointless exercise. C89 remains an
excellent, high-performance, extensible, widely-used language. Yes,
there are things that could be done to improve it, but C99 included
almost none of them, and put a load of extraneous stuff in instead. One
can hardly blame implementors for ignoring it.

The other problem is that globally these days most cs students learn
MS languages

That's their problem, not mine. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Chris Hills <ch***@phaedsys.orgwrites:

In article <11*********************@p10g2000cwp.googlegroups. com>,
santosh <sa*********@gmail.comwrites

[...]

How can Microsoft's C library be conforming if it doesn't yet support
all of C99's requirements?

It is as good as most and better than quite a few I have been told by
people who should know.

The point, I presume, is that it conforms to C90 but not to C99 (as
many libraries do, at least to a first approximation).

[...]

, doesn't it mean that other implementors
would add them to their libraries too?

Yes... So you add them to an 8051 library.... The 8051 is an 8 bit
micro that makes you about 30% of the MCU our in the world today...

The point is apart from the fairly narrow PC programming circles no
one wants or needs the MS library. There are many 8 and 16 bit systems
put there where this library is pointless.

If this library, as advertised, provides "safer" versions of standard
library functions, it should be useful on any hosted implementation,
not just in "fairly narrow PC programming circles". It might not be
useful on embedded (freestanding) implementations -- but the same is
true of most of the standard library, and nobody complains about the
fact that the standard library is part of the standard. (People
certainly complain about the standard library, but not usually about
its existence.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Dave Vandervies]

In article <_P*********************@bt.com>,
Malcolm McLean <re*******@btinternet.comwrote:

>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.

Perhaps it's just enforcing the EULA, which apparently prohibits working
around any technical limitations in the software.
If it doesn't do whatever it is your program does when it's shipped,
that's Obviously a technical limitation, so you're not allowed to do
anything about it.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
Don't worry. All my mistakes are strictly necessary. (And I didn't make the
unnecessary mistake of which you are thinking.)
--Richard Heathfield in comp.programming

[Christopher Layne]

Chris Hills wrote:

AFAIR there are 483 in the ISO standard library... The remainder are
in the MS library.

What *will* happen is MS will say that "their" SAFE-C library is ISO
approved. Also the only people who can support the full ISO-C SAFE.
Library is MS "everyone else is non-standard"

Just like Microsoft and POSIX compliance. They've really followed up on that
one (i.e. they haven't done a damn thing). If they payed attention to the
Cygwin effort - they'd see that having POSIX compliant interfaces would
*increase* their userbase.

[Christopher Layne]

Richard Heathfield wrote:

Yes, because C99 was a fairly pointless exercise. C89 remains an
excellent, high-performance, extensible, widely-used language. Yes,
there are things that could be done to improve it, but C99 included
almost none of them, and put a load of extraneous stuff in instead. One
can hardly blame implementors for ignoring it.

Out of curiosity, and not asked in a rhetorical way, how did they allow this
to happen?

[Malcolm McLean]

"Chris Hills" <ch***@phaedsys.orgwrote in message

The point is apart from the fairly narrow PC programming circles no one
wants or needs the MS library. There are many 8 and 16 bit systems put
there where this library is pointless.

As far as I can tell it boils down to a committee report, consulatation and
liasion exercise with leading edge partners, saying that strcpy() should
take an extra parameter.
With the wisdom of 30 years' experience, they are right. It would have been
better to insist on a destination length parameter. On most embedded system
it would be harmless; if memory is really squeezed then you can write an
ad-hoc solution, and it offers a psychological benefit to the programmer.It
won't stop all buffer overruns, however, and unless the brave step is taken
of terminating violators with an error message, you risk replacing undefined
behaviour, almost certainly a crash unless it is an exploit, with controlled
wrong behaviour. Controlled flight into terrain is the cause of most air
accidents.

[Christopher Layne]

Malcolm McLean wrote:

With the wisdom of 30 years' experience, they are right. It would have been
better to insist on a destination length parameter. On most embedded system
it would be harmless; if memory is really squeezed then you can write an
ad-hoc solution, and it offers a psychological benefit to the programmer.It
won't stop all buffer overruns, however, and unless the brave step is taken
of terminating violators with an error message, you risk replacing undefined
behaviour, almost certainly a crash unless it is an exploit, with controlled
wrong behaviour. Controlled flight into terrain is the cause of most air
accidents.

I don't need the library being the equivalent of a test case for me. I want it
to do what it says. If I don't take defensive measures on my own or use
improper logic, I *want it to crash*.

[Richard Heathfield]

Christopher Layne said:

Richard Heathfield wrote:

>Yes, because C99 was a fairly pointless exercise. C89 remains an
excellent, high-performance, extensible, widely-used language. Yes,
there are things that could be done to improve it, but C99 included
almost none of them, and put a load of extraneous stuff in instead.
One can hardly blame implementors for ignoring it.

Out of curiosity, and not asked in a rhetorical way, how did they
allow this to happen?

If you let a committee standardise a horse, you get a camel. In this
case, we were fortunate in that C89 was a fast camel, with a fine hump
and not too much in the way of extra knees. It was also capable of
going just about anywhere. Unfortunately, the committee then tried to
standardise the camel - and produced C99.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Christopher Layne]

Richard Heathfield wrote:

If you let a committee standardise a horse, you get a camel. In this
case, we were fortunate in that C89 was a fast camel, with a fine hump
and not too much in the way of extra knees. It was also capable of
going just about anywhere. Unfortunately, the committee then tried to
standardise the camel - and produced C99.

I believe that. But where were the sanity checks and safety sides of the
committee? Were there not people within the committee trying to limit the
scope and/or refocus the scope to things which mattered most importantly or
was it a free for all of "I've always wanted this feature" w/ emphasis on
features rather than improving what needed improvement?

[Richard Heathfield]

Christopher Layne said:

Richard Heathfield wrote:

>If you let a committee standardise a horse, you get a camel. In this
case, we were fortunate in that C89 was a fast camel, with a fine
hump and not too much in the way of extra knees. It was also capable
of going just about anywhere. Unfortunately, the committee then tried
to standardise the camel - and produced C99.

I believe that. But where were the sanity checks and safety sides of
the committee? Were there not people within the committee trying to
limit the scope and/or refocus the scope to things which mattered most
importantly or was it a free for all of "I've always wanted this
feature" w/ emphasis on features rather than improving what needed
improvement?

I have no idea. I'm not on the committee.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ben Pfaff]

Christopher Layne <cl****@com.anodizedwrites:

Richard Heathfield wrote:

>Yes, because C99 was a fairly pointless exercise. C89 remains an
excellent, high-performance, extensible, widely-used language. Yes,
there are things that could be done to improve it, but C99 included
almost none of them, and put a load of extraneous stuff in instead. One
can hardly blame implementors for ignoring it.

Out of curiosity, and not asked in a rhetorical way, how did they allow this
to happen?

I think you'll find that Richard Heathfield has a dimmer view of
C99 than do many other people on this newsgroup. I'm pretty
happy with many of the extensions that C99 provided, and as the
implementations get better I'm starting to use more of them in my
programming, especially those that can be adequately simulated
without compiler or library help.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[Richard Heathfield]

Ben Pfaff said:

<snip>

I think you'll find that Richard Heathfield has a dimmer view of
C99 than do many other people on this newsgroup.

Ben is right. You'd be hard pressed to find anyone with a dimmer view of
C99 than me. In fact, it's so far away that I can hardly see it at all.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Chris Hills]

In article <4v******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites

>Chris Hills said:

<snip>

>ISO C is hardly alive and well now.

C89 thrives.

C89 has been dead a long time. (Ever since the international C90)

Most users are on C95(ish)

>C99 is dead in the water.

Not quite but it is hardly thriving.

>Few C99 implications. No one
really that bothered or since 1999 they would have fully implemented
it.

Yes, because C99 was a fairly pointless exercise. C89 remains an
excellent, high-performance, extensible, widely-used language. Yes,
there are things that could be done to improve it, but C99 included
almost none of them, and put a load of extraneous stuff in instead. One
can hardly blame implementors for ignoring it.

We agree.

>The other problem is that globally these days most cs students learn
MS languages

That's their problem, not mine. :-)

Too true.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/