Secure version of I/O functions

[Aaron Hsu]

Most of the *_s functions take an additional length or size parameter.

So, how is this different than the strlcat, strlcpy functions, which
take a size parameter as well? Are you saying that they take another
one more than what strlcpy accepts? What's the point in that?

 

[santosh]

So, how is this different than the strlcat, strlcpy functions, which
take a size parameter as well? Are you saying that they take another
one more than what strlcpy accepts? What's the point in that?

Strlcpy was designed as an improvement over strncpy of ISO C,
particularly to address the latter's "behaviour" of failing to
construct a proper string if the source happens to be longer than the
destination and the sometimes wasteful behaviour of padding the
destination with nulls if the source is small in comparison.

As such strlcpy, strlcat and friends are not in ISO C. Also their
behaviour is subtly different across some systems.

Strcpy_s and other *_s functions are a Microsoft proposal to be added to
ISO C (which is yet to happen). Their semantics are somewhat different
in detail from strlcpy or strncpy. The return values are different, and
they do not leave broken strings nor do they perform null padding. They
also perform argument checking.

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1146.pdf>
<http://www.gratisoft.us/todd/papers/strlcpy.html>

 

[vippstar]

and it *was* used improperly a million of times except by geniueses like
heathfield.

I think you argue to argue, and that you have completely no clue about
computer security.
I, personally have found one memory leak in a, what, 30 lines C
snippet you posted here?
I don't think you are in position to have a strong opinion on computer
security.

Take gets() for instance.

Which you'll find in snippets by starting programmers in C or 80s
code, it's 2008 now.
If you find a programmer using gets() in their code nowadays, you can
safely assume they have completely no clue of computer security.

The performance penalty in most cases will be of the order of a few
integer comparisons. This is a non-issue, since many of
the unsecure functions will be thousands or ten thousands of
instructions. Making a few checks and giving a reasonable and
defined outcome for error cases is just error handling.

I agree with that. I'm not sure what mr Heathfield ment.I *FULLY* agree with this. Total BS by Microsofts part.

They are surely insecure:

printf("%s\n",string);

there is NO WAY to limit output in this specific case.

sure there is, if you know how to use printf().
printf("%.Ns\n", string);
or;
printf("%.*s\n", n, string);

Not to speak about gets() or other goodies that the C standard
allowed.

Yeah, don't speak, we've already heard it and it's most likely that
you won't be adding anything to the subject.

Empty talk. If Mr Gates says

2+2 is 4

I will NOT say otherwise even if I risk being treated as a "traitor
that accepts Gates Law".

I would, 2+2 is relative.
It requires the semantics of +, what 2 is (or what '2+2' is, for
example in lisp it's a valid name), base we are working on et cetera.
2+2 could be 10 in base 4.

Heathfield misses all other specs from strcpy_s. His claims are
spurious.

strcpy_s() is unneeded, nor adds anything to computer security.
Perhaps you'd like to elaborate, but I'm sure you cannot do that;
because simply, strcpy_s *does* *not* add anything.

Yes, sure. But a little more difficult than with strcpy isn't it?

Heathfield logic

"Since a perfect world can't exist, a perfect copy function either,
let's keep all buffer overflows and all stupid functions like
strcpy"

Clearly, you are clueless.

As a side note:
I am not mr Heathfields "supporter" or whatever.
I do find mr Heathfields style of replying sometimes pompous and
needesly insulting;
But most of the times rather accurate, unlike your code or your
statements.

 

[CBFalconer]

.... snip ...

lcc-win implements most of this proposal.

Does the 'do standard C' flag reject it all?

 

[CBFalconer]

.... snip ...

Then , you agree that gets() can't be used properly and that a
function gets_s is OK since it makes gets() usable. I was
answering to heathfield's claim that the secure functions proposal

Why are you fussing with these non-standard awkward mechanisms? As
far as gets is concerned, you have ggets available. Public
domain. Pure standard C. Easily used by neophytes and others.
BTW, the standard has agreed to flag gets as 'going'.

 

[CBFalconer]

Wait, so, these functions are different than those such as strlcat()?
What "benefit" do they provide?

IMO, none. strlcat/cpy are not standard functions, unfortunately.
You can get my implementation and docs at:

<http://cbfalconer.home.att.net/download/>

 

[CBFalconer]

.... snip ...

Strcpy_s and other *_s functions are a Microsoft proposal to be
added to ISO C (which is yet to happen). Their semantics are
somewhat different in detail from strlcpy or strncpy. The return
values are different, and they do not leave broken strings nor do
they perform null padding. They also perform argument checking.

Nor do strlcpy/cat leave broken strings.

 

[jacob navia]

No, you have (again) attributed to me both less and more
than I wrote:

Less:
"you agree that gets() can't be used properly"
No, I wrote that there *is* a proper way to use gets(),
namely, "Don't Do That."

OK. You win Eric. Word games are not my specialty.

 

[Aaron Hsu]

As such strlcpy, strlcat and friends are not in ISO C.

Hrm, okay, then, when I read the mapages of these functions in my
system, and it says that it is part of the Standard C library, it
really does not mean anything, or does it mean something different than
that it is a part of ISO C?

 

[Randy Howard]

Hrm, okay, then, when I read the mapages of these functions in my
system, and it says that it is part of the Standard C library, it
really does not mean anything, or does it mean something different than
that it is a part of ISO C?

Yes, this is an aspect of man pages (and most UNIX systems libc
implementations) that can be confusing.

The "standard c library" at the top of the man page usually means no
more than "you don't have to include any extra libraries when you
compile your program to get this function linked properly." Some
systems make this a bit more clear by using this form:

LIBRARY
Standard C Library (libc, -lc)

This doesn't mean that ANSI, or ISO, or POSIX defines the function(s)
described on the man page in a standard.

Many systems will have a section, typically near the bottom of the man
page and often not read, called STANDARDS. This will point out
(usually correctly, but I have seen errors here on several platforms as
well) which standard(s) specified the function. You may also have a
HISTORY section that says "foo() first appeared in" some OS/version.

 

[Richard Heathfield]

Aaron Hsu said:

Hrm, okay, then, when I read the mapages of these functions in my
system, and it says that it is part of the Standard C library, it
really does not mean anything, or does it mean something different than
that it is a part of ISO C?

It means the man page is wrong (if that is truly what it says).

 

[Richard Tobin]

Hrm, okay, then, when I read the mapages of these functions in my
system, and it says that it is part of the Standard C library, it
really does not mean anything, or does it mean something different than
that it is a part of ISO C?

[/QUOTE]

It means the man page is wrong (if that is truly what it says).

"Standard C Library" doesn't necessarily mean "library specified by
the C standard". Sometimes it means "the C library that comes as
standard" rather than some extra one. Unix's libc was referred to
as the "standard C library" long before C was standardised.

I thought the use of the phrase in the unix manual pages themselves
might be historical, but in fact it seems to have been introduced
relatively recently in the BSD man pages.

Fortunately the confusion is usually reduced by the manual page
listing the standards to which the function conforms, though
apparently that wasn't enough in this case.

-- Richard

 

[Keith Thompson]

Strlcpy was designed as an improvement over strncpy of ISO C,
particularly to address the latter's "behaviour" of failing to
construct a proper string if the source happens to be longer than the
destination and the sometimes wasteful behaviour of padding the
destination with nulls if the source is small in comparison.

I don't know the history of strlcpy, but I would intend that it was
intended as an improvement over strcpy, not strncpy. The strncpy
function is a strange thing; what it writes is not necessarily a
string (a sequence of characters terminated by and including a
terminating '\0') but a different data structure consisting of a
character array padded with zero or more '\0's. There's nothing wrong
with such a data structure, except that it's too easy to treat it
incorrectly as if it were a string.

[snip]

 

[santosh]

I don't know the history of strlcpy, but I would intend that it was
intended as an improvement over strcpy, not strncpy.

Yes. You're probably right. I said strncpy because I remember reading
that somewhere, but the Net is unfortunately full of misleading
information.

The strncpy
function is a strange thing; what it writes is not necessarily a
string (a sequence of characters terminated by and including a
terminating '\0') but a different data structure consisting of a
character array padded with zero or more '\0's. There's nothing wrong
with such a data structure, except that it's too easy to treat it
incorrectly as if it were a string.

Yes. Someone in c.s.c mentioned the other day that it was originally
used in UNIX V for constructing fields in system data structures, but
it is surprising that a function with such a "specialised" usage has
been incorporated into ISO C, but not a more general one like strlcpy,
though admittedly it's easy enough to write your own when needed.

 

[santosh]

Nor do strlcpy/cat leave broken strings.

I meant strncpy of course.

 

[CBFalconer]

.... snip ...

I don't know the history of strlcpy, but I would intend that it was
intended as an improvement over strcpy, not strncpy. The strncpy

You can find appropriate references etc in strlcpy.zip, on my page.