On Oct 14, 2011, at 1:45 PM, Eric Covener wrote: > On Fri, Oct 14, 2011 at 1:35 PM, William A. Rowe Jr. > <[email protected]> wrote: >> On 10/14/2011 7:46 AM, Jim Jagielski wrote: >>> >>> On Oct 13, 2011, at 4:30 PM, William A. Rowe Jr. wrote: >>>> >>>> The largest string value applicable to header values, to URI's >>>> and any presentation string (to errorlog or access log etc) is >>>> MAX_STRING_LEN. The longest config line is MAX_STRING_LEN. >>>> I don't see a lot of reasons supporting something longer. >>> >>> Pre-2.4 that is true, but not on trunk… >> >> Trunk might be even simpler... an ap_pnregsub taking a max-string len arg? >> >>>> This was always unambiguous, NULL on error. The doxygen has *nothing* >>>> to say about the result value. >>>> >>>> So... I'd suggest we fix cases that did not expect NULL and return NULL >>>> on any substitution failure. I don't even see the need for an MMN bump. >>> >>> For trunk? Yes. For pre-2.4? Not so sure (due to external modules)… >>> but I'll go along with it. >> >> I'd love to see some additional eyes on the use cases and proposed solutions >> so we can put this to bed. >> >> > > In pre-2.4, it seems we could be more tolerant than 10 subs or 8K if > we're going to be returning a NULL that's never been returned in > practice. >
Well, we've never allowed things like $10, $11, so they've always been limited to $0->$9, but we've never bothered checking nmatch to be less than 10… For pre-2.4, "" as an error seems safe, but I'm fine with NULL. For 2.4, NULL seems the (only) way to go. I'll be offline mostly for a week so whatever we decide to do with pre-2.4 will be OK… I just want to be able to release 2.0.65 and 2.3.15 when I get back :)
