> And, consider my position on your calloc change in this patch as a > veto. If you want to remove calloc, then you should do so throughout > the code rather than in sporadic places that may make maintaining the > code a nightmare if we were to fix calloc. But, that is an issue > that is now open in APR's STATUS.
What exactly are you vetoing? My use of apr_palloc()+memset() is technically superior to apr_pcalloc(). What is your technical reason for forcing me to use apr_pcalloc()? > If the end result of the calloc vote is that we should remove calloc, > then feel free to do a search and replace across the entire tree. > Until then, let's please remain consistent to our API. -- justin I'm really not sure about the macro yet. On the one hand it's too late to remove apr_pcalloc(). The macro stinks the same way #define safe_free()-like stuff does, but at least it is a compromise. OTOH, as Cliff brought up, we'll get a SEGV if apr_palloc() returns NULL. I don't see how: foo = apr_palloc(p, sizeof(*foo)); memset(foo, 0, sizeof(*foo)); is any less desirable than: foo = apr_pcalloc(p, sizeof(*foo)); It is quite obvious how the memory is being initialized in both cases, and for the reasons discussed earlier it is obvious why the first would be optimal. -aaron
