Safe C library

[Christopher Layne]

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]

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]

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]

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:

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.

 

[Christopher Layne]

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:

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.

 

[Ben Pfaff]

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.

 

[Richard Heathfield]

Ben Pfaff said:

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.

 

[Chris Hills]

Chris Hills said:



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.

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.

That's their problem, not mine.

Too true.

 

[Richard Tobin]

C89 thrives.

[/QUOTE]

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

Since the two are the same, that's just pedantry.

-- Richard

 

[Chris Hills]

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

Since the two are the same, that's just pedantry.

-- Richard[/QUOTE]

No the two are different.
On is a local US standard the other is an International Standard.
As this is an international group why refer to the local US standard
rather than the International one?

 

[Chris Hills]

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

No I was referring to C99

[...]

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

The Safe C lib has about 2K functions in it. ISO C has 483? SO you work
out what the other 1500 are for.

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

You are VERY narrow in your view. There are very many embedded systems
that have an RTOS ie hosted, Also there are a lot of other computer
systems that are not Wintel or embedded.... There is more to life than
embedded or PC's

 

[Keith Thompson]

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

C89 and C90 are two standards that describe exactly the same language.

Most users are on C95(ish)

I suspect most users don't use the stuff that was added by the 1995
amendment (digraphs and additional support for wide and multibyte
characters). But I think most compilers do support it.

 

[Christopher Layne]

You are VERY narrow in your view. There are very many embedded systems
that have an RTOS ie hosted, Also there are a lot of other computer
systems that are not Wintel or embedded.... There is more to life than
embedded or PC's

I'm pretty sure of all people out there, Keith Thompson is more than aware of
that. You'll notice he's quite sensitive about the portability of code to
other lifeforms than x86 - as are a lot of other regulars around here.

 

[Richard Tobin]

Since the two are the same, that's just pedantry.

[/QUOTE]

No the two are different.
On is a local US standard the other is an International Standard.
As this is an international group why refer to the local US standard
rather than the International one?

The content is the same. Compilers behave the same here as in
America.

-- Richard

 

[Keith Thompson]

No the two are different.
On is a local US standard the other is an International Standard.
As this is an international group why refer to the local US standard
rather than the International one?

Actually, C89 *was* a local US standard, issued by ANSI. ISO adopted
it, with some editorial changes, as C90, then ANSI officially adopted
the ISO version. But the fact remains that C89 and C90 describe
exactly the same language.

 

[Keith Thompson]

No I was referring to C99

Just to be clear, you're saying that Microsoft's C library has good
(but presumably not quite complete) support for C99? That's
pleasantly surprising. The impression I've gotten here is that
Microsoft hasn't been particularly interested in C99 conformance.

[...]

The Safe C lib has about 2K functions in it. ISO C has 483? SO you
work out what the other 1500 are for.

I don't know what the other 1500 are for. Are you saying they're
Windows-specific?

You are VERY narrow in your view. There are very many embedded
systems that have an RTOS ie hosted, Also there are a lot of other
computer systems that are not Wintel or embedded.... There is more to
life than embedded or PC's

I assumed that embedded systems tend to be freestanding
implementations; if that's not correct, it's simply something I didn't
know, not narrow-mindedness.

Yes, there's more to life than embedded systems and PCs; that was
exactly my point. *If* this so-called "Safe C" library's primary
purpose is to provide safer versions of the existing standard C
library, then it should be equally useful on any hosted system. PCs
are just a subset of hosted systems, so I didn't understand why you
mentioned them. (I was thinking in particular of Unix systems, since
those are what I work on.) If, on the other hand, it contains a lot
of Windows-specific functionality, then offering it for
standardization doesn't make any sense -- nor does discussing it here,
really.

So, what are those other 1500 functions for?

 

[William Ahern]

On Mon, 05 Feb 2007 13:33:33 +0000, Chris Hills wrote:

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

Have these people _used_ MSVC or the included C library?

As of December 2006, MSVC supported zero of the C99 language features I
tried, including named array and structure initializers and compound
literals. stdint.h? None. stdbool.h? Negative.

As for the C library, arguably one of the only widely used and widely
desired added C function was snprintf(), and theirs is wholly
non-conforming, returning negative when output exceeded the buffer,
instead of the logical resulting length. The majority of code I've seen
[erroneously] assumes that snprintf() cannot fail at all. While not to
excuse such code, such practice shows what developers expect out of the
function. (In their defense, it's tidier to deal w/ the return type of
snprintf() as an unsigned integral for comparisons with (size_t).)

I think it's safe to say that Microsoft has basically given the finger to
the C99 specification. An attitude which, by some of the opinions in this
group, is not entirely out of the ordinary. As for me, I find the features
described above to eminently improve the readability and maintainability
of my code. So, I switched to MinGW (GCC port) for Windows development.

 

[Richard Heathfield]

Chris Hills said:

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

As others have pointed out, the languages the two documents describe are
identical.

Most users are on C95(ish)

Most users are on <implementor's name> C + extensions, and neither know
nor care whether the implementation supports C89, C90, C95, C99, C0x or
CO2.

We agree.

Stop that! Stop it at once! ;-)