[Zlib-devel] OS_CODE

[William A. Rowe, Jr.]

Mark Adler wrote:
> On Aug 20, 2006, at 10:18 PM, William A. Rowe, Jr. wrote:
>> I'm suggesting examining zutil.h to see what would be of interest  
>> to many
>> users, not simply this application
> 
> Yes, I did that.  I may move DEF_MEM_LEVEL out to zlib.h.  I didn't  
> find anything else, besides OS_CODE, that would be useful.  The  
> preprocessor logic for OS_CODE is complicated and intertwined with  
> other function definitions.  So I'll repeat my question: would a  
> function that returns the OS_CODE satisfy your needs?
> 
>> Consider that other utilities may
>> like to examine the internals of a compressed set of files.
> 
> I'm not sure I understand this.  You don't need anything in zutil.h  
> to examine the internals of a compressed set of files.

Very cool - since only OS_CODE was interesting to me I thought I'd raise
the question for other hardcore zlib users :)  But it sounds like only
DEF_MEM_LEVEL and OS_CODE are universally interesting.  Keep in mind the
various OS_CODEs are all interesting, not just the 'current platform'.
Those shouldn't need to be #define's, in fact in this code snippet they
would be a problem (global initializer with a function call in it's ctor?

static const char gzip_header[10] =
{ '\037', '\213', Z_DEFLATED, 0,
  0, 0, 0, 0, /* mtime */
  0, zlib_oscode(OS_UNIX)
};

??? Ick :)

So a function returning 'this build's OS_CODE' could be interesting, but
most useful is the full table of #define's to grok the origin of an
arbitrary gzip stream.

Bill