On 14.06.2013 17:44, André Malo wrote: > On Friday 14 June 2013 17:34:26 Rainer Jung wrote: >> On 14.06.2013 16:41, André Malo wrote: >>> On Wednesday 12 June 2013 21:18:05 Stefan Fritsch wrote: >>>> On Tuesday 11 June 2013, André Malo wrote: >>>>>> trunk patch: http://svn.apache.org/r1491155 >>>>>> 2.4.x patch: trunk patch works >>>>>> nd: why would you do that in a stable branch? >>>>>> >>>>>> + sf: Because it is only annoying and serves no purpose >>>>>> anymore. If you + want, we can make it a minor MMN bump >>>>>> for adding a "new" API. +1: sf, covener >>>>>> >>>>>> -1: nd >>>>> >>>>> Long discussions in STATUS are kinda tedious ;-) >>>>> >>>>> Well, I think, such changes are what trunk is for. Why not simply >>>>> leave everything below as-is? Even more if it removes only an >>>>> annoyance? Or is there a real technical reason I'm just not seeing >>>>> right now? >>> >>> [...] >>> >>>> Or, is there a real technical reason to keep it broken in 2.4? >>> >>> Annoying rhetoric games aside - we went from "only annoying" to "broken". >>> What is it now? >>> >>> No other opinion on this? >> >> As far as I understand the matter, the block removed by the above commit >> would throw a compiler error if code uses strtoul() and includes httpd.h. >> >> The motivation was that at the time the block was introduced some >> supported platforms, e.g. SunOS 4, did not have strtoul(), so it was >> helpful to throw that error even when compiled on other platforms to >> ensure compatibility. >> >> The error will also be thrown for any 3rd-party code that uses strtoul() >> and includes httpd.h when being compiled - so practically all modules >> are prohibited to use strtoul(). >> >> The function is part of C89 which we assume as a minimum when compiling >> Apache 2.4. So I do not see any positive effects of the old block. I do >> recognize, that it breaks module compilation for modules using >> strtoul(). So the proposed change removes an obstacle for full CC89 >> support in modules. Furthermore I can not imagine any risk of breaking >> stuff that worked before removing the block. >> >> Based on that I am +1 to remove the block. > > I agree, that the block should simply die. However, I question the value of > doing cosmetical changes in our stable branches (which is the justification > in STATUS). > > So the question in this specific case is: is it a cosmetical change or not?
We do cosmetical changes in stable branches like e.g. reducing code drift between trunk and 2.4 or fixing typos in comments. We do it if we see only very little risk and anticipate at least some benefit now or for the future. In the case discussed here I'd say the risk is very small and the benefit of a more complete c89 support for module authors is real (but of course not big). I like the addition of the MMN bump suggested by Jeff. Regards, Rainer
