At 01:40 12.02.2003, Marcus Börger wrote:
At 00:17 12.02.2003, Stefan Esser wrote:
On Wed, Feb 12, 2003 at 08:13:49AM +0900, Moriyoshi Koizumi wrote:
> some clarification here so I can find snprintf related bugs elsewhere.
As long as snprintf must not truncate it will return the number of
writte
At 00:19 12.02.2003, Sascha Schumann wrote:
On Wed, 12 Feb 2003, Stefan Esser wrote:
> On Wed, Feb 12, 2003 at 08:13:49AM +0900, Moriyoshi Koizumi wrote:
> > some clarification here so I can find snprintf related bugs elsewhere.
>
> As long as snprintf must not truncate it will return the number
At 00:17 12.02.2003, Stefan Esser wrote:
On Wed, Feb 12, 2003 at 08:13:49AM +0900, Moriyoshi Koizumi wrote:
> some clarification here so I can find snprintf related bugs elsewhere.
As long as snprintf must not truncate it will return the number of
written bytes (excluding '\0'). If sprintf must t
> And that's the problem. snprintf usage should always look
> similar to this:
Forget that :-) I was thinking of strncpy.
- Sascha
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, 12 Feb 2003, Stefan Esser wrote:
> On Wed, Feb 12, 2003 at 08:13:49AM +0900, Moriyoshi Koizumi wrote:
> > some clarification here so I can find snprintf related bugs elsewhere.
>
> As long as snprintf must not truncate it will return the number of
> written bytes (excluding '\0'). If sprin
On Wed, Feb 12, 2003 at 08:13:49AM +0900, Moriyoshi Koizumi wrote:
> some clarification here so I can find snprintf related bugs elsewhere.
As long as snprintf must not truncate it will return the number of
written bytes (excluding '\0'). If sprintf must truncate it either
returns -1 or (if it is
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> > > And the "fix" broke the header code on systems with old style snprintf.
> >
> > Doesn't the same apply to sprintf() ?
>
> Nope, that's safe.
IIRC snprintf() of any implementations return the correct number of valid
bytes unless the length o
> > And the "fix" broke the header code on systems with old style snprintf.
>
> Doesn't the same apply to sprintf() ?
Nope, that's safe.
- Sascha
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
"Stefan Esser" <[EMAIL PROTECTED]> wrote:
> 8 + 20 + 1 + 1 = 30
My stupid calculation... Thanks.
64 * log(2) / log(10) > 19
> And the "fix" broke the header code on systems with old style snprintf.
Doesn't the same apply to sprintf() ?
> - result = emall
I don't know (haven't followed the thread -- what kind of fp
implementation does have 512 digits?).
There was a problem elsewhere with %f formatting of PHP's printf
function. Each printf implementation seems to have a maximum
allowed width for that. However i do not remeber the source of
On Mon, 10 Feb 2003, Marcus Börger wrote:
>
> >Have you looked at smart_strs? That's the way to go, if you
> > want to get rid of nasty size calculations/checks and ugly
> > memcpy calls.
>
> Basically spprintf was designed to be an easy replacement for
> all the other sprintf derivat
Have you looked at smart_strs? That's the way to go, if you
want to get rid of nasty size calculations/checks and ugly
memcpy calls.
Basically spprintf was designed to be an easy replacement for
all the other sprintf derivates. But perhaps i should have used
the smart strings inside
> Ah, Ok then. I see i should have made spprintf's interface to support
> an estimated sizebut then !! i see the real problem here, i overlooked
> it when rewriting the stuffyes it is really!! slowbut how about this
> change:
Have you looked at smart_strs? That's the way to go, if
At 21:40 10.02.2003, Moriyoshi Koizumi wrote:
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Why not use spprintf before you make it even more complex?
> Something like this:
>
> if(!strstr(lower_temp,"realm")) {
> efree(result);
> spprintf(&result, 0, "%s realm=\"%ld\"",ptr, myuid);
[EMAIL PROTECTED] (Marcus Börger) wrote:
> Why not use spprintf before you make it even more complex?
> Something like this:
>
> if(!strstr(lower_temp,"realm")) {
> efree(result);
> spprintf(&result, 0, "%s realm=\"%ld\"",ptr, myuid);
> }
Because spprintf is just considerably s.
At 21:18 10.02.2003, you wrote:
moriyoshi Mon Feb 10 15:18:08 2003 EDT
Modified files:
/php4/main SAPI.c
Log:
Fixed possible snprintf problem
# besides snprintf returns int value, not uint / size_t...
Why not use spprintf before you make it even more complex?
Someth
It'd probably be clearer to call the function sapi_force_http_1_0 (I just
added an underscore).
Andi
At 03:28 AM 12/1/2002 +, Sascha Schumann wrote:
sas Sat Nov 30 22:28:22 2002 EDT
Modified files:
/php4/main SAPI.c SAPI.h
/php4/sapi/apache mod_php4.c
Log:
add a
> > And what if we want to change the initialization? I think it's nice the way
> > it was and gives us a chance to change defaults. I don't see any good
> > reason for nuking this.
>
>
> struct {
> "apache",
> "Apache",
> php_apache_register_hooks
>
> And what if we want to change the initialization? I think it's nice the way
> it was and gives us a chance to change defaults. I don't see any good
> reason for nuking this.
A value of zero means "this field is uninitialized - do
whatever you think is the default". You can still change
At 08:07 PM 11/27/2002 +0100, Sascha Schumann wrote:
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> At 07:57 PM 11/27/2002 +0100, Sascha Schumann wrote:
> >On Wed, 27 Nov 2002, Andi Gutmans wrote:
> >
> > > Default initializations?
> >
> > The compiler does that just fine.
>
> Hmm, I'm either ver
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> At 07:57 PM 11/27/2002 +0100, Sascha Schumann wrote:
> >On Wed, 27 Nov 2002, Andi Gutmans wrote:
> >
> > > Default initializations?
> >
> > The compiler does that just fine.
>
> Hmm, I'm either very tired or I completely misunderstood something. Since
At 07:57 PM 11/27/2002 +0100, Sascha Schumann wrote:
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> Default initializations?
The compiler does that just fine.
Hmm, I'm either very tired or I completely misunderstood something. Since
when does the compiler initialize struct's? (I know it does
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> Default initializations?
The compiler does that just fine.
- Sascha
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Default initializations?
Andi
At 07:42 PM 11/27/2002 +0100, Sascha Schumann wrote:
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> I would have prefered you to leave STANDARD_SAPI_MODULE_PROPERTIES. Why
> didn't you put fd earlier? I don't think BC is much of an issue here. Or am
> I missing somethi
On Wed, 27 Nov 2002, Andi Gutmans wrote:
> I would have prefered you to leave STANDARD_SAPI_MODULE_PROPERTIES. Why
> didn't you put fd earlier? I don't think BC is much of an issue here. Or am
> I missing something?
Can you explain to me what rational purpose that macro serves?
- Sascha
I would have prefered you to leave STANDARD_SAPI_MODULE_PROPERTIES. Why
didn't you put fd earlier? I don't think BC is much of an issue here. Or am
I missing something?
Andi
At 05:15 AM 11/26/2002 +, Sascha Schumann wrote:
sas Tue Nov 26 00:15:55 2002 EDT
Modified files:
26 matches
Mail list logo
