Re: [relax-ng] Including a schema more than once without causing errors

["MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>]

Mitch,

Thanks for your detailed reply.  I have a better understanding 
of your concern.

The problems you described appears to be cause by separate compilation.  
I believe that no RELAX NG implementations create compiled 
codes from SOME (not all) of the referenced schemas.  I am not 
sure if such separate compilation is needed for RELAX NG.  After 
all, the size of schemas is much smaller to the size of programs.

Cheers,

> The failure points occur when (1) something other than a definition is 
> included in the header, for instance a static variable or (2) the header 
> is changed between compilations of different, linked components. The 
> root fault is in the #ifdef strategy, because it assumes that a single 
> preprocessor process will access a single manifest constant to make a 
> decision that should be made uniformly across the entire build. However, 
> complicated builds can  trigger multiple compile processes, and it is 
> only luck and a low probability of a file changing, or good coding style 
> and version control, that prevents problems from actually occurring.
> 
> By sharing libraries and application objects that were compiled 
> separately, a much larger window of opportunity is created for multiple, 
> inconsistent versions of structures and variables.
> 
> I saw this problem myself in debugging a database application called 
> "Ideo", on Solaris, with its C compiler, and Oracle. The vendor 
> distributed the base system as a set of object files and libraries, then 
> later provided updates by sending new libraries. It was anything but 
> safe. For that matter, it was a pretty dependable way to create an 
> unstable application.
> 
> So what I'm asking is if there is anything analogous in the way the 
> validation process(es) in which a RelaxNG schema will be used that could 
> cause the assumptions of such a guard to fail.
> 
> 
> 
> MURATA Makoto (FAMILY Given) wrote:
> > One area that the include guard breaks down is when files are compiled
> >> separately with poor organization of the makefile dependencies.  Then 
> >> H_GRANDFATHER and its structures, and more importantly static objects, 
> >> can be included multiple times in a series of intermediate object files. 
> >> I think the guard only works when there is but one, and only one, 
> >> compilation context.  Would RELAX NG validators face a similar situation?
> >>     
> >
> > I do not understand your point.  C or C++ programmers have safely used #ifdef 
> > for more than one compliation context.  Are they any examples of
> > failures?
> >
> >   
> 

-- 
MURATA Makoto (FAMILY Given) <EB2M-MRT@asahi-net.or.jp>