At 08:17 AM 6/30/2004, Jeff Trawick wrote:
>I like Joe's suggestion of catching it in the test suite. If the API is ever
>changed so that the caller specifies the length of their buffer, then there
>will be an interesting case which apr_snprintf() could catch.
Unfortunately, you would need to t
Jim Jagielski wrote:
apr_snprintf(buf, 5, "%3d ", (int) size);
if (buf[3] != ' ') { /* catch overflow */
return strcpy(buf, "");
}
If I understand the problem correctly, doesn't snprintf() return
the number of bytes that would have been printed if there had been
no limit. Thus, can't we che
> >
> > apr_snprintf(buf, 5, "%3d ", (int) size);
> > if (buf[3] != ' ') { /* catch overflow */
> > return strcpy(buf, "");
> > }
> >
>
> If I understand the problem correctly, doesn't snprintf() return
> the number of bytes that would have been printed if there had been
> no limit. Thu
Jeff Trawick wrote:
>
> >>reviewed but not approved ;)
> >>
> >>it still has the same bug (apr_snprintf() doesn't return < 0 either)
> >
> >
> > Care to supply a fixed version?
>
> IMHO the original version is sufficient for now. In fact, the new version
> isn't going to misbehave; it just in
Joe Orton wrote:
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote:
IMHO the original version is sufficient for now.
Agreed.
Adding tests seems like the best way to protect against someone screwing
up in the future...
yes, that makes perfect sense to me
On Wed, Jun 30, 2004 at 06:00:29AM -0400, Jeff Trawick wrote:
> IMHO the original version is sufficient for now.
Agreed.
..
> Note that libc has to have broken sprintf() or somebody has to introduce a
> new bug into the apr_strfsize() function in order to have such an overflow
> anyway. Due to
David Reid wrote:
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when
[EMAIL PROTECTED] wrote:
wrowe 2004/06/28 11:09:16
Modified:strings Tag: APR_0_9_BRANCH apr_strings.c
Log:
Avoid any edge case or clib bug that might result in a string
overflow of the fixed 5-byte buffer for our size function.
Returns the '' string when the buffer wo
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= wrote:
>
> Aaron Bannert wrote:
>
> >> +if ( (any < 0) || (neg && (val > acc || (val -= c) > acc))
> >>
> >>
> >
> >Isn't that one of those short-circuits that causes bad side-effects
> >under different circumstances? I have a feeling that it is not
>
Aaron Bannert wrote:
+if ( (any < 0) || (neg && (val > acc || (val -= c) > acc))
Isn't that one of those short-circuits that causes bad side-effects
under different circumstances? I have a feeling that it is not
well defined if the -= operation is always performed or not, but
I could
> +if ( (any < 0) || (neg && (val > acc || (val -= c) > acc))
Isn't that one of those short-circuits that causes bad side-effects
under different circumstances? I have a feeling that it is not
well defined if the -= operation is always performed or not, but
I could be wrong. Assuming I c
[EMAIL PROTECTED] wrote:
wsanchez2002/07/24 13:29:38
Modified:.CHANGES configure.in
include apr.h.in apr_strings.h
strings apr_strings.c
Log:
Added apr_strtoll() and apr_atoll() to strings lib.
Submitted by: Shantonu Sen <[EMAIL PROTECTED]>
You shou
This just broke the Windows build.
"error C2632: 'long' followed by 'long' is illegal"
Shane
[EMAIL PROTECTED] wrote:
wsanchez2002/07/24 13:29:38
Modified:.CHANGES configure.in
include apr.h.in apr_strings.h
strings apr_strings.c
Log:
Added apr_
[EMAIL PROTECTED] writes:
> wsanchez2002/07/24 13:29:38
>
> Modified:.CHANGES configure.in
>include apr.h.in apr_strings.h
>strings apr_strings.c
> Log:
> Added apr_strtoll() and apr_atoll() to strings lib.
> Submitted by: Shantonu Sen <[E
On 28 Sep 2001 [EMAIL PROTECTED] wrote:
> +nargs = 0;
>while ((argp = va_arg(adummy, char *)) != NULL) {
>len = strlen(argp);
Urm, didnjya mean to remove that last line?
> +if (nargs < MAX_SAVED_LENGTHS) {
> +len = saved_lengths[nargs++];
> +
Yup. Done and checked in.
[ I'm checking usage right now to ensure people don't depend on that... ]
Cheers,
-g
On Sun, Feb 11, 2001 at 04:32:19PM +, Ben Laurie wrote:
> Hmmm. Actually, this could improve its efficiency by only allocating
> len+1 bytes if len < n. Should we do that?
>
> Chee
On Sun, Feb 11, 2001 at 09:40:04AM -0800, Cliff Woolley wrote:
>
> --- [EMAIL PROTECTED] wrote:
> > +APR_DECLARE(void *) apr_memdup(apr_pool_t *a, const void *m, apr_size_t
> > n)
> > +{
> > +void *res;
> > +
> > +if(m == NULL)
> > + return NULL;
> > +res = apr_palloc(a,
--- [EMAIL PROTECTED] wrote:
> +APR_DECLARE(void *) apr_memdup(apr_pool_t *a, const void *m, apr_size_t n)
> +{
> +void *res;
> +
> +if(m == NULL)
> + return NULL;
> +res = apr_palloc(a, n);
> +memcpy(res, m, n);
> +return res;
> +}
> +
Nice. Minor que
Hmmm. Actually, this could improve its efficiency by only allocating
len+1 bytes if len < n. Should we do that?
Cheers,
Ben.
[EMAIL PROTECTED] wrote:
>
> ben 01/02/11 08:25:08
>
> Modified:strings apr_strings.c
> Log:
> ap_pstrndup could have caused out-of-bounds memory acce
19 matches
Mail list logo
