Re: security enhacement to C runtime library (XXX_s)
- From: "Douglas A. Gwyn" <DAGwyn@xxxxxxxx>
- Date: Thu, 5 Apr 2007 23:54:49 GMT
Zeppe wrote:
... 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.
The simple answer is that it wouldn't work. Some implementations
are simply not capable of checking whether the boundsless interfaces
are properly used. In principle, one could change the C compiler
and run-time system to perform *most* boundary checks, but there
would be a stiff performance penalty to pay for that feature. There
is nothing to prevent a compiler from detecting *some* boundary
errors at compile time, and I believe that some do that already.
A guiding principle behind the recent "safer interfaces" TR was not
that the functions have identical interfaces to the traditional ones,
but rather that they have similar interfaces with the bounds added
in a consistent way, making it relatively easy to edit existing code
to use the new functions in place of the traditional ones.
.
- Follow-Ups:
- References:
- security enhacement to C runtime library (XXX_s)
- From: artun
- Re: security enhacement to C runtime library (XXX_s)
- From: Zeppe
- Re: security enhacement to C runtime library (XXX_s)
- From: jacob navia
- Re: security enhacement to C runtime library (XXX_s)
- From: Zeppe
- security enhacement to C runtime library (XXX_s)
- Prev by Date: Re: id behavior triggered by access to volatile object
- Next by Date: Re: compression in floating point arithmetic
- Previous by thread: Re: security enhacement to C runtime library (XXX_s)
- Next by thread: Re: security enhacement to C runtime library (XXX_s)
- Index(es):
Relevant Pages
|
|
