[Zlib-devel] zlib-1.2.3-cos1

[Cosmin Truta]

On Mon, 15 May 2006, William A. Rowe, Jr. wrote:

> Cosmin Truta wrote:
> >
> > - Add ZLIB_VER_MAJOR, ZLIB_VER_MINOR and ZLIB_VER_REVISION in zlib.h,
> >   for use in win32/zlib1.rc [Polushin, Rowe, Truta]
> >
> >   #define ZLIB_VERSION        "1.2.3-cos1"
> >   #define ZLIB_VERNUM         0x123f
> >   #define ZLIB_VER_MAJOR      1
> >   #define ZLIB_VER_MINOR      2
> >   #define ZLIB_VER_REVISION   3
>
> Cosmin, you omitted ZLIB_VER_BUILD (fourth-level numeric signature).
>
> It's TBD if this should be always included in the text representation.

The fourth letter is not the build number, but it's an internal number
used for the beta versions released by Mark. This cannot correspond with
the fourth letter used in .rc version number; that number was 0 until
now, and it can continue to be 0.

> I think it's VERY unhealth to propogate 'modify the version in three
> places', you retain this behavior unless the net VERNUM and VERSION
> are computed.

It's not three places: it's one place, 5-lines-long at the beginning of
zlib.h. Keeping them in sync is trivial, but if Mark disagrees, he can
resort to the solution that you originally proposed:

#define ZLIB_VERNUM_MAJOR  1
#define ZLIB_VERNUM_MINOR  2
#define ZLIB_VERNUM_MAINT  4

#define ZLIB_STRINGIZE_VAL(val) #val
#define ZLIB_STRINGIZE_TOK(tok) ZLIB_STRINGIZE_VAL( tok )

#define ZLIB_VERSION ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MAJOR ) \
                 "." ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MINOR ) \
                 "." ZLIB_STRINGIZE_TOK( ZLIB_VERNUM_MAINT )

#define ZLIB_VERNUM ( ZLIB_VERNUM_MAJOR << 12 \
                    | ZLIB_VERNUM_MINOR <<  8 \
                    | ZLIB_VERNUM_MAINT <<  4 )

as opposed to:

#define ZLIB_VERSION        "1.2.4"
#define ZLIB_VERNUM         0x1240
#define ZLIB_VER_MAJOR      1
#define ZLIB_VER_MINOR      2
#define ZLIB_VER_REVISION   4


But, as I was saying, I think the latter is better because of many
reasons. It is easier to read, easier to comprehend, easier to maintain,
portable across non-ANSI compilers, and also more flexible (otherwise,
I wouldn't have been able to use "1.2.3-cos1" for ZLIB_VERSION or 0x123f
for ZLIB_VERNUM). And, no, if we were to consider private zlib
modifications, I don't think that introducing an extra macro ZLIB_BLAH
to put in ZLIB_VERNUM as

#define ZLIB_VERNUM ( ZLIB_VERNUM_MAJOR << 12 \
                    | ZLIB_VERNUM_MINOR <<  8 \
                    | ZLIB_VERNUM_MAINT <<  4 \
                    | (ZLIB_BLAH ? 0 : 0xf)

is necessarily a good idea, either.

[So much for my strong opposition ;-)]

Cheers,
Cosmin