apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject tweaking apr.hw for "deprecation" (was [Zlib-devel] zlib-1.2.3-cos1)
Date Wed, 31 May 2006 17:32:44 GMT
FYI - Mladen - you aren't the only one being shot at for polluting public
headers ;-)  Here's Andrei's take at my zlib patch for doing just that, and
we do the same in apr.

I think his comments are sane - perhaps we should adopt this in building apr?
OTOH we are a portability library, once apr.h is loaded the user is trying to
build some portable apr posix-like code.

Thoughts?

Bill

Andrei Polushin wrote:
> Cosmin Truta wrote:
> 
>>- Shut up annoying VS2005 warnings about standard C deprecation [Rowe, Truta]
>>- Swap the order of #include <stdio.h> and #include "zlib.h" in
>>  gzio.c, example.c and minigzip.c [Truta]
>>
>>Both of these changes are here because much of the standard C library
>>is "deprecated" in Visual C++ 8.
>>Andrei Polushin made a point that the modification in zconf.h has side
>>effects, and it's better to resort to using macros in VC makefiles and
>>project files.
>>His point is valid indeed, but I regard that as a "feature" rather than
>>a "side effect". I mean, since zlib inherently depends on the standard
>>C library, and the latter gets "deprecated", it implies the former also
>>should be "deprecated" until that dependency is removed. Which (I bet)
>>won't happen. zlib demands standard C, and anyone who demands zlib
>>should also demand standard C.
> 
> 
> Consider the opinion of Herb Sutter:
>   http://aspn.activestate.com/ASPN/Mail/Message/boost/2731073
> where he says that "We are not removing *any* ISO C or C++ features from
> our compiler or libraries. Period." And "We're just working (hard) to
> help our customers write code that doesn't contain buffer overruns and
> other security problems, and at that we emit only warnings so that
> people can ignore them if they choose not to care about those issues."
> 
> In other words, zlib might choose to ignore those warnings, because the
> authors know what they do exactly, but they should not ignore the demand
> of Microsoft's customers for the slightly better security.
> 
> --
> Andrei Polushin
> 
> _______________________________________________
> Zlib-devel mailing list
> Zlib-devel@zlib.net
> http://madler.net/mailman/listinfo/zlib-devel_madler.net
> 
> 

Mime
View raw message