On Thu, 15 Jul 1999 18:40:17 CST, Warner Losh wrote:
> I can see your point. I don't know if I'll like your man pages better
> or not, but I'd be willing to give them a spin.
Bring on the humble pie. It really isn't practical to try to have these
pages match the approach of the existing pages.
On Thu, 15 Jul 1999 18:40:17 CST, Warner Losh wrote:
> I can see your point. I don't know if I'll like your man pages better
> or not, but I'd be willing to give them a spin.
Bring on the humble pie. It really isn't practical to try to have these
pages match the approach of the existing pages
On Thu, Jul 15, 1999 at 04:18:08PM -0700, Mike Smith wrote:
>
> The only addition I'd want to make to
> asprintf() is reasprintf() which reallocs and appends to the end of
> an already existing string.
And don't forget reasprintff() (a-la reallocf()).
Ugh.
--
This is
On Thu, Jul 15, 1999 at 06:28:52PM -0600, Warner Losh wrote:
>
> : Looking at OpenBSD's actual definition of strlcat() which returns the
> : number of chars that would have been in the final string is
> : potentially non-useful, but not really too terrible.
>
> No. It is useful. If you look
On Thu, Jul 15, 1999 at 11:20:04PM -0400, Bakul Shah wrote:
>
> That is, the returned ptr points in `dst' _just_ past the
> copied data. Note that `dst_end' points to the _last_ char
> of `dst'.
This sounds a lot like the GNU stpcpy() except that stpcpy() doesn't
take the middle argument dst_end
On Thu, Jul 15, 1999 at 04:18:08PM -0700, Mike Smith wrote:
>
> The only addition I'd want to make to
> asprintf() is reasprintf() which reallocs and appends to the end of
> an already existing string.
And don't forget reasprintff() (a-la reallocf()).
Ugh.
--
This i
On Thu, Jul 15, 1999 at 06:28:52PM -0600, Warner Losh wrote:
>
> : Looking at OpenBSD's actual definition of strlcat() which returns the
> : number of chars that would have been in the final string is
> : potentially non-useful, but not really too terrible.
>
> No. It is useful. If you look
On Thu, Jul 15, 1999 at 11:20:04PM -0400, Bakul Shah wrote:
>
> That is, the returned ptr points in `dst' _just_ past the
> copied data. Note that `dst_end' points to the _last_ char
> of `dst'.
This sounds a lot like the GNU stpcpy() except that stpcpy() doesn't
take the middle argument dst_end
Mike Smith wrote:
> pw = getpwuid(getuid());
> strlcpy(buf, pw->dir, sizeof(buf));
> strlcat(buf, "/.appname/", sizeof(buf));
> strlcat(buf, conffilename, sizeof(buf));
> if (strlen(buf) >= sizeof(buf))
> return(error);
> fp = fopen(buf, "r");
> ...
>
> That works, as long as M
Mike Smith wrote:
> pw = getpwuid(getuid());
> strlcpy(buf, pw->dir, sizeof(buf));
> strlcat(buf, "/.appname/", sizeof(buf));
> strlcat(buf, conffilename, sizeof(buf));
> if (strlen(buf) >= sizeof(buf))
> return(error);
> fp = fopen(buf, "r");
> ...
>
> That works, as long as
On Fri, Jul 16, 1999 at 09:15:19AM +0100, Dominic Mitchell wrote:
> On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote:
> > I just can't resist mentioning Dan Bernstein's implementation of a similar
> > idea: stralloc - dynamically allocated strings.
>
> Has he actually LICENSEd any of his
On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote:
> I just can't resist mentioning Dan Bernstein's implementation of a similar
> idea: stralloc - dynamically allocated strings.
Has he actually LICENSEd any of his code yet?
--
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Admini
I just can't resist mentioning Dan Bernstein's implementation of a similar
idea: stralloc - dynamically allocated strings.
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
On Fri, Jul 16, 1999 at 09:15:19AM +0100, Dominic Mitchell wrote:
> On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote:
> > I just can't resist mentioning Dan Bernstein's implementation of a similar
> > idea: stralloc - dynamically allocated strings.
>
> Has he actually LICENSEd any of hi
On Fri, Jul 16, 1999 at 10:12:29AM +0200, Jos Backus wrote:
> I just can't resist mentioning Dan Bernstein's implementation of a similar
> idea: stralloc - dynamically allocated strings.
Has he actually LICENSEd any of his code yet?
--
Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Admin
I just can't resist mentioning Dan Bernstein's implementation of a similar
idea: stralloc - dynamically allocated strings.
--
Jos Backus _/ _/_/_/ "Reliability means never
_/ _/ _/ having to say you're sorry."
Any use of str{,n}cat makes me gag. In the past I have used
a composable function that may be of interest. Composable in
the sense that the result can be immediately used as an arg
to another call and it doesn't have the O(N^2) behavior of
strcat. Such a function can be totally safe. Something
Any use of str{,n}cat makes me gag. In the past I have used
a composable function that may be of interest. Composable in
the sense that the result can be immediately used as an arg
to another call and it doesn't have the O(N^2) behavior of
strcat. Such a function can be totally safe. Something
> > but what about
> >
> > While ( more data items)
> > {
> > copy data items onto end of buffer
> > if full{
> > write out buffer
> > clear buffer, copy in rest of last item.
> > }
> > }
> >
> >
> > I'd certainly not want to use xxprintf() for that
>
> This is what stdio does,
In message <81768.932085...@axl.noc.iafrica.com> Sheldon Hearn writes:
: If you see my point, let me know and I'll send you an alternative
: strlcpy.3 .
I can see your point. I don't know if I'll like your man pages better
or not, but I'd be willing to give them a spin.
Warner
To Unsubscribe:
> In message <199907160023.raa02...@dingo.cdrom.com> Mike Smith writes:
> : I still think this is the wrong way to deal with the problem. 8)
>
> We mildly disagree here. The strl* functions are the end all, be all
> of security. They are just designed to make the existing code that
> uses static
On Thu, 15 Jul 1999 18:28:52 CST, Warner Losh wrote:
> I'm planning on committing their man page. I don't see problems with
> it, purhaps people could point them out to me so that both our man
> pages and theirs could be better.
As I've said already, there's too much in DESCRIPTION that should
In message <199907160032.saa01...@harmony.village.org> Warner Losh writes:
: We mildly disagree here. The strl* functions are the end all, be all
: of security.
NOTE: This should have read:
We mildly disagree here. The strl* functions are NOT the end all, be
all of security.
which changes its
In message <199907160023.raa02...@dingo.cdrom.com> Mike Smith writes:
: I still think this is the wrong way to deal with the problem. 8)
We mildly disagree here. The strl* functions are the end all, be all
of security. They are just designed to make the existing code that
uses static buffers eas
In message <19990715194203.a54...@mad> Tim Vanderhoek writes:
: Looking at OpenBSD's actual definition of strlcat() which returns the
: number of chars that would have been in the final string is
: potentially non-useful, but not really too terrible.
No. It is useful. If you look at the retu
> In message <199907152358.qaa01...@dingo.cdrom.com> Mike Smith writes:
> : if (strlen(buf) >= sizeof(buf))
> : return(error);
>
> This can never be true with the strl functions They don't run off
> the end, so strlen(buf) is always going to be < sizeof(buf) since it
> doesn't
In message <199907152329.qaa01...@dingo.cdrom.com> Mike Smith writes:
: Ugh. Take the first example in the paper; it rewrites as
:
: len = asprintf(&path, "%s/.foorc");
:
: as opposed to
:
: strlcat(path, homedir, sizeof(path));
: strlcat(path, "/", sizeof(path));
: strl
In message <199907152244.paa01...@dingo.cdrom.com> Mike Smith writes:
: What's really stupid is that most of the time you're trying to use
: these functions to fix code that looks like:
: strcpy(buf, str1);
: strcat(buf, str2);
: strcat(buf, str3);
: without overflowing buf. Thi
In message <199907152358.qaa01...@dingo.cdrom.com> Mike Smith writes:
: if (strlen(buf) >= sizeof(buf))
: return(error);
This can never be true with the strl functions They don't run off
the end, so strlen(buf) is always going to be < sizeof(buf) since it
doesn't include t
> but what about
>
> While ( more data items)
> {
> copy data items onto end of buffer
> if full{
> write out buffer
> clear buffer, copy in rest of last item.
> }
> }
>
>
> I'd certainly not want to use xxprintf() for that
This is what stdio does, funnily enough. See fwrite()
but what about
While ( more data items)
{
copy data items onto end of buffer
if full{
write out buffer
clear buffer, copy in rest of last item.
}
}
I'd certainly not want to use xxprintf() for that
On Thu, 15 Jul 1999, Mike Smith wrote:
> > On Thu, 15 Jul 1999, Mike Smith wrot
> On Thu, 15 Jul 1999, Mike Smith wrote:
>
> > Ugh. Take the first example in the paper; it rewrites as
> >
> > len = asprintf(&path, "%s/.foorc");
> >
> > as opposed to
> >
> > strlcat(path, homedir, sizeof(path));
> > strlcat(path, "/", sizeof(path));
> > strlcat(path, ".foor
> > but what about
> >
> > While ( more data items)
> > {
> > copy data items onto end of buffer
> > if full{
> > write out buffer
> > clear buffer, copy in rest of last item.
> > }
> > }
> >
> >
> > I'd certainly not want to use xxprintf() for that
>
> This is what stdio does,
In message <[EMAIL PROTECTED]> Sheldon Hearn writes:
: If you see my point, let me know and I'll send you an alternative
: strlcpy.3 .
I can see your point. I don't know if I'll like your man pages better
or not, but I'd be willing to give them a spin.
Warner
To Unsubscribe: send mail to [EMA
At 12:15 AM +0200 7/16/99, Sheldon Hearn wrote:
>[Hijacked from freebsd-security]
For those who missed the original article, here's the initial
topic (from Paul Hart, but truncated a bit):
I was just reviewing the proceedings from the USENIX 1999
Annual Technical Conference where Todd Mil
On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote:
>
> If all you're saying is that you want an API that doesn't require a test
> against the known length of src (append in your example), then you won't
> like strl*. :-)
Well, if I read your message correctly, the difference between f
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : I still think this is the wrong way to deal with the problem. 8)
>
> We mildly disagree here. The strl* functions are the end all, be all
> of security. They are just designed to make the existing code that
> uses static buffers easy to ma
On Thu, 15 Jul 1999 18:28:52 CST, Warner Losh wrote:
> I'm planning on committing their man page. I don't see problems with
> it, purhaps people could point them out to me so that both our man
> pages and theirs could be better.
As I've said already, there's too much in DESCRIPTION that shoul
On Thu, 15 Jul 1999, Mike Smith wrote:
> Ugh. Take the first example in the paper; it rewrites as
>
> len = asprintf(&path, "%s/.foorc");
>
> as opposed to
>
> strlcat(path, homedir, sizeof(path));
> strlcat(path, "/", sizeof(path));
> strlcat(path, ".foord", sizeof(pat
In message <[EMAIL PROTECTED]> Warner Losh writes:
: We mildly disagree here. The strl* functions are the end all, be all
: of security.
NOTE: This should have read:
We mildly disagree here. The strl* functions are NOT the end all, be
all of security.
which changes its meaning quite a bit...
> Ugh. Take the first example in the paper; it rewrites as
>
> len = asprintf(&path, "%s/.foorc");
^ , homedir
Whoops.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ msm...@freebsd.org
\\-- Joseph Mer
In message <[EMAIL PROTECTED]> Mike Smith writes:
: I still think this is the wrong way to deal with the problem. 8)
We mildly disagree here. The strl* functions are the end all, be all
of security. They are just designed to make the existing code that
uses static buffers easy to make more robu
In message <19990715194203.A54146@mad> Tim Vanderhoek writes:
: Looking at OpenBSD's actual definition of strlcat() which returns the
: number of chars that would have been in the final string is
: potentially non-useful, but not really too terrible.
No. It is useful. If you look at the ret
> On Thu, 15 Jul 1999, Julian Elischer wrote:
>
> > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX.
> > The logic as to their design was presented and I agree totally with
> > the way that the logic was played out into the functions.
> >
> > They are described in the FreeNIX pro
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : if (strlen(buf) >= sizeof(buf))
> : return(error);
>
> This can never be true with the strl functions They don't run off
> the end, so strlen(buf) is always going to be < sizeof(buf) since it
> doesn't include the tralin
In message <[EMAIL PROTECTED]> Mike Smith writes:
: Ugh. Take the first example in the paper; it rewrites as
:
: len = asprintf(&path, "%s/.foorc");
:
: as opposed to
:
: strlcat(path, homedir, sizeof(path));
: strlcat(path, "/", sizeof(path));
: strlcat(path, ".foord",
In message <[EMAIL PROTECTED]> Mike Smith writes:
: What's really stupid is that most of the time you're trying to use
: these functions to fix code that looks like:
: strcpy(buf, str1);
: strcat(buf, str2);
: strcat(buf, str3);
: without overflowing buf. This is dumb! Use asp
>
> > What's really stupid is that most of the time you're trying to use
> > these functions to fix code that looks like:
> >
> > strcpy(buf, str1);
> > strcat(buf, str2);
> > strcat(buf, str3);
> > without overflowing buf. This is dumb! Use asprintf instead:
>
> There was a talk
In message <[EMAIL PROTECTED]> Mike Smith writes:
: if (strlen(buf) >= sizeof(buf))
: return(error);
This can never be true with the strl functions They don't run off
the end, so strlen(buf) is always going to be < sizeof(buf) since it
doesn't include the traling null.
W
> but what about
>
> While ( more data items)
> {
> copy data items onto end of buffer
> if full{
> write out buffer
> clear buffer, copy in rest of last item.
> }
> }
>
>
> I'd certainly not want to use xxprintf() for that
This is what stdio does, funnily enough. See fwrite()
On Thu, 15 Jul 1999, Julian Elischer wrote:
> There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX.
> The logic as to their design was presented and I agree totally with
> the way that the logic was played out into the functions.
>
> They are described in the FreeNIX proceedings on pa
but what about
While ( more data items)
{
copy data items onto end of buffer
if full{
write out buffer
clear buffer, copy in rest of last item.
}
}
I'd certainly not want to use xxprintf() for that
On Thu, 15 Jul 1999, Mike Smith wrote:
> > On Thu, 15 Jul 1999, Mike Smith wro
> On Thu, 15 Jul 1999, Mike Smith wrote:
>
> > Ugh. Take the first example in the paper; it rewrites as
> >
> > len = asprintf(&path, "%s/.foorc");
> >
> > as opposed to
> >
> > strlcat(path, homedir, sizeof(path));
> > strlcat(path, "/", sizeof(path));
> > strlcat(path, ".foo
On Thu, 15 Jul 1999, Mike Smith wrote:
>
> What's really stupid is that most of the time you're trying to use
> these functions to fix code that looks like:
>
> strcpy(buf, str1);
> strcat(buf, str2);
> strcat(buf, str3);
> without overflowing buf. This is dumb! Use asprin
On Thu, 15 Jul 1999 18:34:42 -0400, Tim Vanderhoek wrote:
> if (fooncat(string, append, sizeof(string)) != strlen(append))
>...
>
> which is rather evil, given that the second strlen(append) would be
> completely gratuitous if it weren't for the interface you're
> suggesting.
Tim, you're d
> On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
> >
> > As I understand it, the goal here is to return to the caller the number
> > of bytes copied (however you represent it), so that the caller can
> > easily determine whether or not dst is safe for operations demanding a
> > nul
At 12:15 AM +0200 7/16/99, Sheldon Hearn wrote:
>[Hijacked from freebsd-security]
For those who missed the original article, here's the initial
topic (from Paul Hart, but truncated a bit):
I was just reviewing the proceedings from the USENIX 1999
Annual Technical Conference where Todd Mi
On Fri, Jul 16, 1999 at 12:53:13AM +0200, Sheldon Hearn wrote:
>
> If all you're saying is that you want an API that doesn't require a test
> against the known length of src (append in your example), then you won't
> like strl*. :-)
Well, if I read your message correctly, the difference between
On Thu, 15 Jul 1999, Mike Smith wrote:
> Ugh. Take the first example in the paper; it rewrites as
>
> len = asprintf(&path, "%s/.foorc");
>
> as opposed to
>
> strlcat(path, homedir, sizeof(path));
> strlcat(path, "/", sizeof(path));
> strlcat(path, ".foord", sizeof(pa
> Ugh. Take the first example in the paper; it rewrites as
>
> len = asprintf(&path, "%s/.foorc");
^ , homedir
Whoops.
--
\\ The mind's the standard \\ Mike Smith
\\ of the man. \\ [EMAIL PROTECTED]
\\-- Joseph Mer
> On Thu, 15 Jul 1999, Julian Elischer wrote:
>
> > There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX.
> > The logic as to their design was presented and I agree totally with
> > the way that the logic was played out into the functions.
> >
> > They are described in the FreeNIX pr
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
>
> As I understand it, the goal here is to return to the caller the number
> of bytes copied (however you represent it), so that the caller can
> easily determine whether or not dst is safe for operations demanding a
> null-terminated
>
> > What's really stupid is that most of the time you're trying to use
> > these functions to fix code that looks like:
> >
> > strcpy(buf, str1);
> > strcat(buf, str2);
> > strcat(buf, str3);
> > without overflowing buf. This is dumb! Use asprintf instead:
>
> There was a talk
On Thu, 15 Jul 1999, Julian Elischer wrote:
> There was a talk on these (strlcpy(3) and strlcat(3)) at USENIX.
> The logic as to their design was presented and I agree totally with
> the way that the logic was played out into the functions.
>
> They are described in the FreeNIX proceedings on p
[Hijacked from freebsd-security]
On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote:
> What I wanted to do was have "estr" routines, where the destination
> is specified as the starting point and the ending point of the area
> available for the string (as two parameters). The routines
On Thu, 15 Jul 1999, Mike Smith wrote:
>
> What's really stupid is that most of the time you're trying to use
> these functions to fix code that looks like:
>
> strcpy(buf, str1);
> strcat(buf, str2);
> strcat(buf, str3);
> without overflowing buf. This is dumb! Use aspri
On Thu, 15 Jul 1999 18:34:42 -0400, Tim Vanderhoek wrote:
> if (fooncat(string, append, sizeof(string)) != strlen(append))
>...
>
> which is rather evil, given that the second strlen(append) would be
> completely gratuitous if it weren't for the interface you're
> suggesting.
Tim, you're
> On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
> >
> > As I understand it, the goal here is to return to the caller the number
> > of bytes copied (however you represent it), so that the caller can
> > easily determine whether or not dst is safe for operations demanding a
> > nu
On Fri, Jul 16, 1999 at 12:15:31AM +0200, Sheldon Hearn wrote:
>
> As I understand it, the goal here is to return to the caller the number
> of bytes copied (however you represent it), so that the caller can
> easily determine whether or not dst is safe for operations demanding a
> null-terminate
[Hijacked from freebsd-security]
On Thu, 15 Jul 1999 17:33:29 -0400, Garance A Drosihn wrote:
> What I wanted to do was have "estr" routines, where the destination
> is specified as the starting point and the ending point of the area
> available for the string (as two parameters). The routines
70 matches
Mail list logo
