Re: [xml] misc warnings compiling libxml2-2.6.22 (cvs snapshot dloaded 2005/12/09) with HP aC++/ANSI C B3910B A.06.05 [Jul 25 2005]

[Rick Jones <rick jones2 hp com>]

> > "xpath.c", line 11095: warning #2128-D: loop is not reachable from 
> > preceding code
> >      do {
> >      ^
>
>
>   hum ... strange, there is a goto next_node below which allows to get
> back in that do loop. So it is reachable from following code, not a very
> nice piece of code, but I would rather be prudent there.

Might be a mistake on the part of the compiler.

> > This one caught my eye:
> >
> > cc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g 
> > -Wp,-H30000 -c xmlschemastypes.c  +Z -DPIC -o .libs/xmlschemastypes.lo
> > "xmlschemastypes.c", line 1699: warning #2186-D: pointless comparison of 
> > unsigned integer with zero
> >      if ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date))))
> >                                        ^
> >
> > "xmlschemastypes.c", line 1699: warning #2186-D: pointless comparison of 
> > unsigned integer with zero
> >      if ((ret != 0) || (*cur != 0) || !VALID_DATETIME((&(dt->value.date))))
> >                                        ^
>
>
>   The macros expands to quite a lot of code. Maybe running on the preprocessor
> output would help pinpoint what exactly is at stake there. I don't really 
> understand the message too ... unless something like u < 0 I don't see the
> point being raised.

I'll see about getting just the pre-processed stuff.

> > This one brings-up another point:
> >
> > cc -DHAVE_CONFIG_H -I. -I. -I. -I./include -I./include -D_REENTRANT -g 
> > -Wp,-H30000 -c xmlmodule.c+Z -DPIC -o .libs/xmlmodule.lo
> > "xmlmodule.c", line 284: warning #2167-D: argument of type "void **" is 
> > incompatible with parameter
> > of type "shl_t *"
> >      rc = shl_findsym(&handle, name, TYPE_UNDEFINED, symbol);
> >                       ^
>
>
>   data vs. function pointers conversions.
>
>
> > With PA2.0W (64-bit PA) and with IPF/ia64, (either 32 bit or 64) there is 
> > support for dlopen et al.  In fact, the shl_findsym manpage has this to say:
> >
> >      Future HP-UX environments may not support these routines and flags or
> >      may only support a subset of them.  Instead, they will use the SVR4
> >      dynamic loading API.  Users are encouraged to migrate to the dl*
> >      family of dynamic linking routines.  See the dlclose(3C), dlerror(3C),
> >      dlget(3C), dlgetname(3C), dlmodinfo(3C), dlopen(3C), and dlsym(3C) man
> >      pages for more information.
> >
> >
> > for some reason while I'm typing the above I am getting a feeling of deja 
> > vu. anyway...
>
>
>    Well I think we used that code explicitely because dlopen() wasn't available
> on old HP-UX systems...

Small matter of a check for dlopen in configure perhaps?  Indeed old HP-UX 
systems didn't have dlopen.  It arrived with "64-bit" (PA was in one sense 
64-bit from day one - 32-bit spaceid and offsets) PA 2.0 support and is "the" 
mechanism on IA64.


> > "runtest.c", line 3859: warning #2177-D: function "thread_specific_data" 
> > was declared but never referenced
> >  thread_specific_data(void *private_data)
> >  ^
>
>
>   not used on HP-UX but used for pthreads systems... let's ignore this

fair enough. the "not used on HP-UX but used for pthreads systems" seems strange 
- HP-UX has had basically proper pthreads since 11.0.

> > and then finally, an outright build error:
> >
> > creating parse2
> > No suffix list.
> > sh: /usr/bin/xsltproc:  not found.
> > *** Error exit code 127 (ignored)
> > sh: /usr/bin/xsltproc:  not found.
> > *** Error exit code 127 (ignored)
> > sh: /usr/bin/xsltproc:  not found.
> > *** Error exit code 127 (ignored)
> > sh: /usr/bin/xsltproc:  not found.
> > *** Error exit code 127 (ignored)
> > Making all in example
> >
> > there is no xsltproc on the system:
>
>
>   configure should have found this ... strange ...

I thought so - basically it found _something_ that led it to believe that 
xsltproc was present.  I've been meaning to try on a system without the 
pre-compiled xml2 stuff on it but have been having trouble getting a 
contemporary compiler onto that system :(

> > though I must admit my ability to quickly parse shell stuff is pretty weak.
>
>
>   and my ability to read generated configure code, is not much better...


> I have fixed all okay'ed, and will commit as soon as I verify all regression
> tests still pass as expected.

sounds good.

rick jones