[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [relax-ng] Including a schema more than once without causing errors
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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]