Re: backtrace

On Fri, 1 Sep 2000, Sascha Schumann wrote: > > That's silly (c). > > > > "A pointer cannot be freed multiple times." > > > > Would you consider this sentence incorrect? Incomplete? > > That depends on the context. > > We were talking about the behaviour of something under very > specific circumstances. The part you omitted was an essential > part of these circumstances. No it isn't. As there's nothing magical about va_list, like every other thing in C, it can be reused forever if you initialize it over again. Stating the obvious is dumb. > > > Please refer to my other email on why assignments don't work > > > well in this context. > > > > Can you forward me your Email? My understanding is that if it compiles, > > it should work. > > Well, it works under some conditions, as does Win2000. It works if it compiles, sarcasm aside. > > (the older code worked, even though it didn't compile well > > for some very odd reason, probably a compiler bug; > > The type of va_list is implementation-dependent. Not > supporting GCC's copy-struct-by-assignment C extension is > hardly a bug. Copying a struct is a feature of ANSI C, not gcc. Copying arrays isn't, and I guess that's what happened in implementations that used arrays. Not a compiler bug indeed, though. > > > @@ -366,7 +366,6 @@ > > /* get include file name */ > > if (PG(log_errors) || PG(display_errors) || (!module_initialized > )) { > > size = vsnprintf(buffer, sizeof(buffer) - 1, format, ori > g_args); > > - va_end(orig_args); > > > > buffer[sizeof(buffer) - 1] = 0; > > > > @@ -442,7 +441,6 @@ > > pval *tmp; > > > > size = vsnprintf(buffer, sizeof(buffer) - 1, format, orig_args); > > - va_end(orig_args); > > > > buffer[sizeof(buffer) - 1] = 0; > > While this change might fix things on some platforms, it is > incorrect. > > If we are going to use orig_args twice, we need (*1) to > reinitialize it. Since this is not possible in a portable > way (*2), I suggest to use it only once. I.e. set a flag > after vsnprintf'ing buffer for the first time. > > 1.: "The object ap may be passed as an argument to another > function; if that function invokes the va_arg macro > with parameter ap, the value of ap in the calling > function is indeterminate and shall be passed to the > va_end macro prior to any further reference to ap. Where are you reading this? It sounds very odd and I assume it would be wrong (or otherwise useless to do) on every implementation. > 2.: There are two ways to reinitialize a va_list. Old > implementations don't support va_copy. va_start cannot > be used in a function with a fixed number of arguments. Essentially, it means that a function that receives a va_list argument, cannot use it more than once (unless it uses the non portable va_copy()). Sounds weird to me. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/