K
Kelsey Bjarnason
[snips]
No, I'm not talking conditional compilation, I'm talking two entirely
separate sets of library functions.
Conditional compilation allows me to create a debug versus release version
of, say, strcpy, or to build my app using the "safe" versus "non-safe"
version. This is not an acceptable approach to deal with the stuff you're
talking about: if you want a "safe" strcpy, fine - but leave *my* strcpy,
the one with the decent performance, alone.
To do this, you're going to have to actually create a function other than
strcpy - call it safe_strcpy if you want. Fine by me, I don't care, make
your safe_strcpy as slow an bloated as you want, I don't care. I might
even use it, in a few places. Where I want efficiency, though, I've got
my original, unmodified version, the one without all the bloat and checks
and other crap I don't need or want.
Who said *any* coders are perfect, let alone all of 'em?
The problem is, generally, bad coding practises. You think telling
someone "You don't have to worry about security, because these functions
will do it for you" is going to magically turn bad coders into good ones?
You do grasp the concept of "input", right? You understand what it means?
Obviously not, so I'll explain it.
Input is data coming into your program. It can come from a whole variety
of sources - users typing on keyboards, files read from disk, you name it,
but it's stuff that comes in from the outside.
Since it comes in from the outside, its size and format and other
characteristics are unpredictable and need to be analysed. You need to
tell how much data is involved. You need to remove or escape or otherwise
cope with unwanted characters or strings. You may need to add things to
the data to make it manageable.
Once it's been processed into something usable to the code, however... it
is *absolutely* fixed. It's size is known. Its characteristics are
known. It doesn't magically grow or shrink or add stuff or delete stuff,
it is size X, with properties A, B and C, and will remain so for all time,
unless and until your code - *YOUR CODE* - does something to change that.
Which means that unless you, the coder, are such an incompetent nitwit you
can't tell what your code does with the data, there is absolutely no
reason whatsoever to dick around with "safe" string copies and the like
from that point on, as you know, absolutely, how large the buffers are,
how large the data is.
Deal with the inconsistencies at input, obviously. This is a requirement,
and creating a second-tier library to manage that sort of thing is fine.
Just do *not* screw around with the existing efficient functions,
especially if the only reason you can come up with to justify such an act
is your own incompetence to determine what your own damn code is doing.
No, I'm not talking conditional compilation, I'm talking two entirely
separate sets of library functions.
Conditional compilation allows me to create a debug versus release version
of, say, strcpy, or to build my app using the "safe" versus "non-safe"
version. This is not an acceptable approach to deal with the stuff you're
talking about: if you want a "safe" strcpy, fine - but leave *my* strcpy,
the one with the decent performance, alone.
To do this, you're going to have to actually create a function other than
strcpy - call it safe_strcpy if you want. Fine by me, I don't care, make
your safe_strcpy as slow an bloated as you want, I don't care. I might
even use it, in a few places. Where I want efficiency, though, I've got
my original, unmodified version, the one without all the bloat and checks
and other crap I don't need or want.
Who said *any* coders are perfect, let alone all of 'em?
The problem is, generally, bad coding practises. You think telling
someone "You don't have to worry about security, because these functions
will do it for you" is going to magically turn bad coders into good ones?
You do grasp the concept of "input", right? You understand what it means?
Obviously not, so I'll explain it.
Input is data coming into your program. It can come from a whole variety
of sources - users typing on keyboards, files read from disk, you name it,
but it's stuff that comes in from the outside.
Since it comes in from the outside, its size and format and other
characteristics are unpredictable and need to be analysed. You need to
tell how much data is involved. You need to remove or escape or otherwise
cope with unwanted characters or strings. You may need to add things to
the data to make it manageable.
Once it's been processed into something usable to the code, however... it
is *absolutely* fixed. It's size is known. Its characteristics are
known. It doesn't magically grow or shrink or add stuff or delete stuff,
it is size X, with properties A, B and C, and will remain so for all time,
unless and until your code - *YOUR CODE* - does something to change that.
Which means that unless you, the coder, are such an incompetent nitwit you
can't tell what your code does with the data, there is absolutely no
reason whatsoever to dick around with "safe" string copies and the like
from that point on, as you know, absolutely, how large the buffers are,
how large the data is.
Deal with the inconsistencies at input, obviously. This is a requirement,
and creating a second-tier library to manage that sort of thing is fine.
Just do *not* screw around with the existing efficient functions,
especially if the only reason you can come up with to justify such an act
is your own incompetence to determine what your own damn code is doing.
