[Zlib-devel] zlib-1.2.3-cos1

[Cosmin Truta]

On Mon, 15 May 2006, Andrei Polushin wrote:

> > 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."

Yes, I am familiar with that thread - but don't miss Mr. Sutter's
statement that the word "deprecated" sounds too harsh and shall be
reworded in the future Visual C++ products.

Yet the fact that "deprecated != to_be_removed" does not disprove my
point. My point is a simple logical inference:
a) standard C constructs are deprecated (or whatever)
b) zlib depends on standard C constructs
=> zlib is deprecated (or whatever)

> 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.

Let us make a distinction between what Microsoft thinks is good for its
customers, and what its customers actually demand. Herb Sutter agreed it
was too harsh to complain about "deprecated functions", but that
happened exactly because many Microsoft customers were very unhappy and
very loud about that warning.

Fortunately, the Visual C++ dev team seems responsive enough about their
customers' demands. (As a remote example, in VS2003 there were ugly C++
keywords intended to make a bridge between C++ and .NET. But after lots
of customers complained, VC++ developers removed those keywords and
introduced C++/CLI, which is IMO a far better solution.)

Check out this quote:

  In the end, though, Microsoft listened to the objections. Herb Sutter,
  a software architect at Microsoft and chairman of the ISO C++
  standards committee, said Tuesday that Microsoft backed down.
  "We never intended to offend anybody. We've already agreed to change
  it," he said.

http://www.devsource.com/article2/0,1895,1885051,00.asp

So I don't see a reason to worry about letting those macros inside the
public zconf.h - but I admit that moving them inside the private zutil.h
works equally well.

Best regards,
Cosmin