RE: [NeoStats-Devel] [Commits] r2705 - trunk/modules/statserv

DeadNotBuried wrote:
> M wrote:
> >>From: [email protected] [mailto:[email protected]]
> >>Author: DNB
> >>   trunk/modules/statserv/htmlstats.c
> >>Log:
> >>call do_copyright at end of stats html page only, not each 
> line remove 
> >>case sensitivity for checking end of html template file change html 
> >>file umode to include owner write permission so html file can be 
> >>overwritten
> > 
> > 
> > Win32 no longer compiles:
> > 
> > htmlstats.c(472) : warning C4013: 'strcasestr' undefined; assuming 
> > extern returning int
> 
> is strstr on win32 case sensitive ?

Yes.

> if not a #ifndef WIN32 would resolve the case sensitivity on 
> *nix, or should that be added anyway even if the win32 is 
> case sensitive ?

#ifndef WIN32 is not acceptable because:

1) It makes the code different between different operating systems thereby
introducing different behaviour and support paths. Since strstr and
strcasestr are different functions, the intended operation is not covered by
using strstr where strcasestr is unavailable. Given that strstr has worked
for the life of NeoStats to date, it was acceptable for me to revert to the
original code until I had time to solve the issue while I fixed more
pressing issues with the Win32 build.
2) strcasestr may be unavailable on platforms other than Win32 so you would
potentially introduce a compile error on such platforms that would not be
covered by a WIN32 define.
3) All library functions should be checked during configure and an
appropriate solution added for cases where it is not available. 
4) We do not really want to have *any* WIN32 only defines in the module code
unless there is no other alternative since it makes it harder to maintain
the two paths and harder for third parties to create modules that are OS
independent if even our modules cannot achieve it.

FYI, I have added a configure check and a replacement support function to
provide strcasestr on any platform that does not natively provide it. 

A quick glance through support.c/h will show you a subset of functions I
have written to support systems that do not provide what one might assume to
be common and acceptable to add. There are others in the code besides these
but they are abstracted now which will become the case for the majority, if
not all, library functions in the future.

I appreciate that you may not be confident about creating a support function
to provide support on systems that do not provide an equivalent so if you
add any library call that is not already checked in configure, you should
also add a configure check or mail the list so it can be checked and added.
The functionality can then also be handled through a contribution or as is
likely the case I write one. :)

As a temporary solution in such cases, if you are able to add the configure
check, the library call should be wrapped in an #ifdef using the configure
result (e.g. HAVE_STRCASESTR in this case) so that all platforms will
continue to build and operate despite the lack of support then fire off a
mail to the list.

Hope that makes sense.

Mark.