Re: [xml] reporting bug for lixml2.2.6-8

[Rich Salz <rsalz datapower com>]

> > Being pedantic, you're not allowed to do "ordering tests" on pointers
> > unless you are sure they are related.  At least not in ANSI/ISO C.
>
> Could you possibly expand somewhat upon this?  Which particular part of the
> spec prohibits what type of pointer compare?

I don't have a copy of the spec convenient, but you can look at K&R 2nd 
edition, for example.

> Well, this approach is obviously unacceptable.  The whole purpose of the
> dictionary routines is to provide a fast and efficient method of working with
> strings, and a serial search does not fit within this criteria.

Yup.  Life stinks sometimes.  That is why I would make it a compile-time 
option.

> I would be willing to put up a (reasonable) wager that changing that statement
> to
>     if ((str >= (xmlChar *)&pool->array) && (str <= pool->free))

You'd lose.  The standard says that if "str" is not within the range of 
the pool, then the results of the above expression are *implementation 
defined.*

Now, it happens that on almost every machine you're likely to run 
across, the "implementation defined" behavior is "we'll do the right, 
and obvious, thing."  But there is no guarantee.  It would be nice if 
Insure had an option to ignore that complaint.  Depending on how 
standards-compliant you want to be, it might be nice if someone patched 
in my idea.

Hope this helps.
        /r$

--
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html
XML Security Overview  http://www.datapower.com/xmldev/xmlsecurity.html