Re: rcs-5.8 test failures on HP-UX 11.31

[Thien-Thi Nguyen]

() Paul Ackersviller <address@hidden>
() Mon, 25 Jun 2012 03:05:43 +0000

   On Wed, Jun 06, 2012 at 11:19:25AM +0200, Thien-Thi Nguyen wrote:
   > () Paul Ackersviller <address@hidden>
   > () Mon, 23 Apr 2012 02:48:33 +0000
   > 
   > I have just released 5.8.1.  Could you please try it out and let
   > me know if these problems persist?

   I didn't try quite exactly the 5.8.1 release, but the git head
   from a few days ago.  That should be close enough, right?

If you mean branch ‘master’, then no, that is somewhat beyond 5.8.1
(added features (and bugs)).  Try branch ‘a’ or tag ‘5.8.1’ instead,
which corresponds directly.

   > I think i addressed all the warnings for 5.8.  How does 5.8.1 fare?

   Looks pretty good now, it all compiles and tests successfully.
   HP's compiler is still showing a few warnings, one or two of
   which sound possibly troublesome.  I've attached the compiler
   output.

Thanks.  I've briefly looked at the (non gnulib) warnings, and
identified two legitimate errors.  One (use before init) in b-eph.c
is normally masked for me because ('/' != SLASH) is never true, but
i would think that the same applies to an HPUX system and so wonder
what i'm missing.

   One other thing, in case you care, I also ran the tests with memory
   leak checking.  Following is the report for whatever it's worth.

   -------------------------------------------------------------------------
   4064 bytes leaked at 0x40aa40a0 (98.55% of all bytes leaked)
   #0  allocate() at b-divvy.c:49
   #1  xmalloc() at b-divvy.c:95
   #2  _obstack_begin() at obstack.c:173
   #3  make_space() at b-divvy.c:78

   -------------------------------------------------------------------------
   44 bytes leaked at 0x4059c170 (1.07% of all bytes leaked)
   #0  allocate() at b-divvy.c:49
   #1  make_space() at b-divvy.c:76
   #2  pairnames() at rcsfnms.c:340
   #3  rlog_main() at rlog.c:893

   -------------------------------------------------------------------------
   16 bytes leaked at 0x4005d220 (0.39% of all bytes leaked)
   #0  allocate() at b-divvy.c:49
   #1  make_space() at b-divvy.c:73
   #2  pairnames() at rcsfnms.c:340
   #3  rlog_main() at rlog.c:893

   -------------------------------------------------------------------------

Hmm, could it be possible that the obstacks RCS uses is confusing
the memory leak checking program?  (What would that be, btw?)