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? nd
