Bounds checking functions

[Micah Cowan]

Yes it is different. strcpy and strcat will write to unowned
memory, and blow something else up.

If you abuse it. Which has nothing to do with what I said was not
different (the ability to remove a leading part of the output string),
and yet, is _still_ not different, anyway, as strlcpy() is also quite
capable of the same thing.

Not if you use strlcpy/cat. Then you find out things didn't fit,
and the size needed to allow them to fit.

And that I wasted plenty of valuable time. And: whoa! strlen() already
does that, without the useless copy.

Nobody is insisting on anything.

If your statement were correct, this thread would not have been started.
Please go back to the OP and read it. That _is_ the basis of this thread
(perhaps you're confusing it with the *_s() one?).

Your posts indicate that you have
missed some of the advantages available. I am trying to fill in
those gaps.

Since you have still failed to name a single advantage over
strlen()+strcpy() (and seem to be deliberately ignoring several
disadvantages), I'd say you haven't done that.

 

[William Ahern]

And that I wasted plenty of valuable time. And: whoa! strlen() already
does that, without the useless copy.

Not entirely true. realloc() might preserve the block, and its copy might be
faster (in cache) than copying to a new block. In any event, this cost would
can be amoritized. As opposed to a pattern which necessitates _two_
iterations over the string, always, without any potential to reduce work.

If you just wanted to use strlen(), then use strlen()+memcpy().
strlen()+strcpy() is superfluous.

If your statement were correct, this thread would not have been started.
Please go back to the OP and read it. That _is_ the basis of this thread
(perhaps you're confusing it with the *_s() one?).

I sort of figured this had evolved into a sub-thread.

Since you have still failed to name a single advantage over
strlen()+strcpy() (and seem to be deliberately ignoring several
disadvantages), I'd say you haven't done that.

The extra N conditionals. With strlen()+strcpy(), you're still checking for
NUL every character. If you _already_ know the length, why not use memcpy()?

Only place I can imagine using strcpy() is when I know the source buffer is
less than or equal to the destination buffer, and I'm happy to _discard_ the
length which is derived in the process of copying the string. But a standard
function which _discards_ information has a flaw, IMO. A user should be free
to ignore it, but its a poor tool that makes it impossible without
duplicating work.

 

[William Ahern]

Not entirely true. realloc() might preserve the block, and its copy might be
faster (in cache) than copying to a new block. In any event, this cost would

That doesn't really make any sense. Please ignore.

 

[James Antill]

And what is the better result? If you want to remove the leading part
of the output string, you can do that. If you want to provide a larger
buffer, you can do that. If you want to truncate, you already did that.

If you want a real string library, you can do that. There are a couple
of usable ones to choose from[1]. If you want to write a string API, you
can do that too ... and if you are lucky, and have quite a bit of spare
time, you might get something useful out of it.
But don't pretend that strlcpy/strlcat constitute a usable alternative.

See:

http://www.and.org/vstr/security#stringapi


[1] http://www.and.org/vstr/comparison

 

[Flash Gordon]

CBFalconer wrote, On 27/02/08 22:18:

My release has documentation mentioning that problem, and what to
do to comply.

The biggest release is as part of a full implementation where it is, I
believe, documented as being an extension. As they are documented as
being an extension in the main release giving them names starting with
str is appropriate. Personally I would like it if they were in the
standard because the library writers might be able to use a few tricks
to make their versions faster than any implementation I might provide
and sometimes they are the right tool for the job. Similarly I would
like it if strdup was in the standard. However I have my own
implementations (with different names) for where I need them.

 

[David Thompson]

s/all/most/

Pascal and Ada.

Smiley notwithstanding, those languages do nothing to prevent logic
errors, and don't prevent poor testing, although they can reduce
somewhat the amount of testing needed and thus make it easier.They do
prevent _some_ interface misuses (I hate calling everything an API)
that can be expressed by a relatively rich type system. Eiffel goes
further by allowing arbitrary constraints, but even that has limits:
if the conditions get too complicated, they not only hurt performance,
but become confusing, errorprone, and unreliable themselves.

The one thing robust (aka S&M) languages do (or at least can) that I
consider valuable is enforce high-level semantics. IME&O the most
troublesome bugs in C (and now-few similar languages) is what I call
'low to high leakage'. If you just have a wrong computation, or
condition, or value, it's easy enough to see in the source
(preprocessed if necessary) once you know what to look for/at.
But if you store through a wild pointer (including stale, and
subscript out of range) it can cause failures in a part of the program
that looks and is correct on its own and according to the defined
semantics should be completely separate. A robust language can force
the fault into a part of the source that is relevant. That's a real
benefit, not to be sneezed at in my book; but it is not the solution
to everything. <offtopic> 42 is, of course. </>

- formerly david.thompson1 || achar(64) || worldnet.att.net