165297 - Provide exported header w/ #define of NSS builtin roots module version number

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Kai Engert (:KaiE:)]

PSM should be able to find out, whether the currently loaded version of a roots
module is at least as new as the newest available module at compile time of PSM.

Bob suggested to use an exported header.
That header could contain definitions like:

  #define NSS_BUILTINS_LIBRARY_VERSION_MAJOR 1
  #define NSS_BUILTINS_LIBRARY_VERSION_MINOR 2

Comment 1

[Wan-Teh Chang]

The header nss.h defines macros like NSS_VMAJOR, NSS_VMINOR,
and NSS_VPATCH.  I suggest that these new macros be defined
in nss.h.

The names of the macros should have "ROOT" in them.  Otherwise
it's not clear what these "builtins" are.

Comment 2

[Robert Relyea]

Attachment: nssckbi.h - Builtins version header.

Comment 3

[Wan-Teh Chang]

Comment on attachment 97091 [details] [diff] [review]
nssckbi.h - Builtins version header.

>#ifdef DEBUG
>static const char BUILTINS_CVS_ID[] = "@(#) $RCSfile: nssckbi.h,v $ $Revision: 1.1 $ $Date: 2002/08/28 22:13:19 $ $Name:  $";
>#endif /* DEBUG */

Seems bad to define a static variable in a header file.
Maybe the RCS id string can be put in a comment?

Comment 4

[Robert Relyea]

I typically don't like to, but I'm following the convention of the rest of ckfw.
OTOH this is an exported header file, so it may be better to remove it. I'd like
to check the other stan headers to see if they also include RCSID's.

BTW the rational for including it as a c data time is you can do an ident on the
resulting binary and find out what version of the source was used to build it.

bob

Comment 5

[Kai Engert (:KaiE:)]

I notice a typo in most identifiers, look for VERISON.

Comment 6

[Robert Relyea]

Headers checked in

Comment 7

[Kai Engert (:KaiE:)]

Reopening. Current NSS_CLIENT_TAG appears to neither contain a file named
nssckbi.h nor symbols NSS_BUILTINS_LIBRARY_VERSION_MAJOR or
NSS_BUILTINS_LIBRARY_VERSION_MINOR.

Bob, did possibly something go wrong when you checked in?

Comment 8

[Robert Relyea]

you probably had some update problem: here's what CVS says for that file:
cvs log nssckbi.h

RCS file: /cvsroot/mozilla/security/nss/lib/ckfw/builtins/nssckbi.h,v
Working file: nssckbi.h
head: 1.3
branch:
locks: strict
access list:
symbolic names:
        PHOENIX_0_2_RELEASE: 1.3
        ROGC_20020930_FREEZE: 1.3
        NSS_3_6_BETA2: 1.3
        NSS_CLIENT_TAG: 1.3
        moz_20020919: 1.3
        NSS_3_6_BETA1: 1.3
        STAN_WORK_BRANCH: 1.1.0.2
keyword substitution: kv
total revisions: 5;     selected revisions: 5
description:
----------------------------
revision 1.3
date: 2002/09/06 00:27:35;  author: wtc%netscape.com;  state: Exp;  lines: +1 -1
Bugs 166734 and 166785: fixed compiler warnings reported by gcc on Linux.
The patch for this checkin is attached to bug 166785.
----------------------------
revision 1.2
date: 2002/08/29 17:45:12;  author: relyea%netscape.com;  state: Exp;  lines: +6 -11


Fix Version spelling, remove rcsid.
----------------------------
revision 1.1
date: 2002/08/28 22:13:19;  author: relyea%netscape.com;  state: Exp;
branches:  1.1.2;


File with version number for applications
----------------------------
revision 1.1.2.2
date: 2002/09/16 19:59:33;  author: ian.mcgreer%sun.com;  state: Exp;  lines: +2 -2
make softoken a separate build module so that its headers aren't mixed in with Stan
change 'security' module to 'nss' as on tip
----------------------------
revision 1.1.2.1
date: 2002/08/29 15:35:11;  author: ian.mcgreer%sun.com;  state: Exp;  lines: +1 -1
mgerge from tip
=============================================================================

Comment 9

[Kai Engert (:KaiE:)]

Sorry, my fault. While I was producing the NSS 3.6 test build, I had used a
symbolic link for directories nss and coreconf, forgot to remove them
afterwards, and neither "find" nor "rgrep" (recursive grep) are following
symbolic links by default :(

Resolving fixed again.