Re: security enhacement to C runtime library (XXX_s)

jacob navia wrote:

has been introduced in vc8.0. Your post is OT in this group, because
it's not related to the standard C.

No, it is not. Microsoft has proposed in a technical report a
standardization
of the safer c library

really?!? looking in the internet, I see that it's handled by the WG14,
the same of the ISO C, that's interesting :)

can lead to buffer overflows and stuff like that. Microsoft just
implemented a version of the standard C library that performs some
checks in order to avoid that.


And that is a good idea. The problem is that the current standard
never specifies error handling in a detailed way. This is a big hole
in the standard. The errno mechanism and the other error constructs are
inadequate, specially if the standard doesn't define the error handling
in a precise way.

Great idea, I would rather say! The error handling of the M$ debug C++
library saved my life SO many times...


Yes, because, instead of making the standard function calls safe,
microsoft made a different safe library, so that you have to use
standard names in order to use it. In C++ you can still use
_CRT_SECURE_CPP_OVERLOAD_SECURE_NAMES.


In their technical report they explain their decisions. It is impossible
to make some library functions safe, for instance gets() and others.

I trust them, and I would have expected it (even if I don't have enough
info to understand what kind of safety can be reached without change the
functions declaration: for example, the safety in the format string in
printf seems a kind of magic :)). But I wonder if it could have been
possible, and a good idea, to make the user choose whether to use a safe
implementation, with the same names, of at least these functions that
don't need any change in the function declaration. That would have
allowed a lot of code to become safe without any modification and
without losing portability. It seems to me (but I haven't checked) that
the most problematic functions are those that are inherently unsafe,
maybe because they don't accept bound, and are unlikely to be found in a
code that has got basic error protection.

Something similar to the macro for C++, but more static (change of the
headers/libraries with secure ones).

Probably link error with libraries that use different implementations?
It shouldn't be the case...

What do you think?

Cheers,

Zeppe
.

Relevant Pages

  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... If you are claiming there is a reason to avoid the mechanisms the standard provides to allow portability then it is up to *you* to prove your point, not up to others to disprove it. ... but you can hardly blame the consequences on the Standard headers. ...
    (comp.lang.c)
  • Re: C89, size_t, and long
    ... libraries which have useful stuff). ... So because others here can't think of a good reason to use long instead of size_t and you can't prove there is never such a reason, we must all assume there could be a good reason to not use the mechanisms provided by the standard to deal with a problem? ... want to have standard headers included in their own headers which ...
    (comp.lang.c)
  • Re: Any Clojure users here?
    ... ABCL and I've been contributing to it for a while (though since some ... from the CL standard or from the Java API, ... You can use CFFI-based libraries in ABCL without ... Yes, but without a Clojure standard, it's hard to know what the "core" ...
    (comp.lang.lisp)
  • Re: comparing doubles for equality
    ... AFAIK there is no ANSI/ISO standard for it. ... Fortran 95 seem to have some built-in operators but it's not clear ... LIA,GIA,ICE libraries for interval methods in C++ from Delisoft ... Actually I've been for quite some months proposing getting together ...
    (comp.programming)
  • Re: "Criticism of the C programming language ??????"
    ... "that's not in the standard, ... rewrites of the compiler. ... PH> They got all the compiler vendors to agree to a common ... or graphics libraries or threading libraries, ...
    (comp.lang.c)