What's fixed

See also What's New in OmniMark 9 and Backwards Compatibility.

What's fixed in OmniMark 9.1.0

What's fixed in the OmniMark 9.1.0 compiler

• A warning is now emitted if a string function outputs to its inherited #current-output.
• If the initial clause of an optional argument for a function contained %c, and the function was invoked in an element rule without specifying an argument, the compiler rejected the program on the basis that %c was not being processed in the element rule.
• An internal error could be triggered if the second branch of a conditional operator contained a pattern expression in a non-pattern context.
• An incorrect warning was emitted if the key of shelf query was applied to a field access whose record was specified as an expression.
• It was possible for the compiler to get into an infinite loop if a program contained an elsewhere declaration of a record type that extended a parent type which was in turn referenced as the type of a field of the original record type.
• A do select-type statement applied to an instance whose dynamic type is not explicitly specified as one of the clauses could fail to execute its parent clause.
• An incorrect file name/line number combination was given when a duplicate function definition was encountered
• An internal error was triggered at compile-time if ||* appeared in a shelf initializer.
• A spurious warning was emitted when #console was encountered in a program.
• In a context where #current-input is a markup source, it could be used in a context expecting a string source. This is contrary to the specification, and is now disallowed.
• It was possible to trigger an internal error with a malformed import declaration.
• In some circumstances, an invalid overriding function definition could lead to an internal error at compile time.
• An internal error was triggered in the compiler if a static cast appeared in the dispatch argument of a call to a dynamic function.
• The as opaque qualifier on an exported record declaration did not have to match that of the corresponding elsewhere. This could allow record fields to be visible in contexts where they should not have been; this is contrary to the specification and should not have been allowed.
• An incorrect error message was emitted if an & was encountered where a | was expected, and vice versa.
• An internal error was triggered if a catch was declared to take a value string source argument, and subsequently used in an external-text-entity rule.
• The warning that number of was being applied to a fixed-sized shelf was being emitted too aggressively, leading to too many false warnings.
• The warning emitted when a shelf is unused or uninitialized now points to the location where the shelf was declared, instead of the location of the end of its scope.
• If the filename specified by the -depend command-line option could not be opened, an incorrect error message was output, followed by a segmentation fault.
• An internal error was triggered if an initializer was specified on a optional markup source argument in an elsewhere definition of a function.
• A segfault occurred if an optional markup source function argument specified a constant string as an initial value.
• An initializer could not be specified for an optional markup sink argument in an elsewhere definition of a function.
• An incorrect error message was emitted if #suppress was used as the initializer for an optional string sink argument, and both elsewhere and as definitions of the function were present in the program.
• An internal error could be triggered at run-time if a processing-instruction rule failed to match the input, and a subsequent one succeeded.

What's fixed in the OmniMark 9.1.0 runtime

• A throw from a string sink function that passes its #current-input to a string source function, whose output it then parses, could cause an internal error in OmniMark.
• Error message 6143 has been improved to report both the expected and encountered end tag in case of mismatch.
• In some circumstances, it was possible for the has key test to fail even though an item existed with such a key.
• A markup error that triggered a markup-error rule could cause a memory leak.
• A markup error event could be counted more than once in #markup-error-total if a markup-error rule signalled its #current-markup-event< to another markup-parse.
• The %c consumed in a streaming fashion inside a data-content rule would be interrupted by CDATA and SDATA entities.
• A program error inside a signalled coroutine could cause a segmentation fault.
• Garbage collection could cause a segmentation fault.
• Throwing from a do markup-parse consuming #content of an element that changes the namespace could cause an internal error.
• Removal or setting a key of a new shelf item caused a run-time error. This is now allowed.
• A throw from a nested coroutine caught in its parent could cause the grandparent to die with no error reported.
• A segfault was triggered when a PI entity with empty value was encountered and fired either a processing-instruction rule or a translate rule containing the named pattern.
• The validating XML parser would reject the entity reference < in attribute values.
• A misleading error message was emitted when attempting to access a non-existant element attribute during a well-formed parse.
• Attempting to use a compiled DTD in a validating XML parse, and specifying an empty string for the document-element parameter would lead to a segmentation fault at run-time.

What's fixed in the OmniMark 9.1.0 libraries

• A TAB character in the data fed to the omxmlwrite library could lead to a character entity in the output appearing in a context where one is not allowed.
• A conversion function from string to markup-buffer has been added to markup utilities.
• Two markup-buffer values can now be compared for equality of their contents using the = and != operators.
• The omrelaxng validator did not always accept a valid instance of an attribute value in case the schema specified each alternative value model together with the repeated attribute name.
• relaxng.compile-schema could return an invalid schema object for some heavily recursive RELAX NG schemata.
• Character entities emitted by the omxmlwrite library are now emitted in a hexadecimal representation.

What's fixed in OmniMark 9.0.2

What's fixed in the OmniMark 9.0.2 compiler

• A memory leak would occur at compile time if certain errors were encountered while parsing a module and the error threshold limit was crossed.
• Entity patterns would allow entity patterns for the named and valued components. These could never match, and so are now rejected at compile time. This may cause programs that previously compiled successfully to stop compiling. The solution is to remove the offending pattern.
• The error message emitted when encountering a keyword hidden by a user declaration gave no indication of where the keyword was hidden.
• An inaccurate compile-time error message was emitted when a markup parsing block did not contain a %c, suppress, or #content.
• A misleading error message was emitted at compile time if the arguments to do sgml-parse appeared in the wrong order.
• optional argument pass-through can now be used in a context where a conversion-function would otherwise have been invoked. Previously, this had led to a run-time error.
• The namecase declaration could affect whether or not a program compiles. This declaration is deprecated, and has no effect on program compilation or program execution.
• An error message was emitted if a module exported the predefinition of a function, but the function was never invoked. This impedes early prototyping of modules, and has been relaxed to a warning.
• A needlessly confusing error message was emitted at compile time if | appeared where a || was expected.
• Using the new operator as an argument to a function could lead to erratic behavior at compile time.
• Using new on a field access in an open action could lead to erratic results when the type of the shelf item was incorrect.
• Using the name of operator in an erroneous context could lead to erratic results.
• Conflicting definitions of dynamic functions could lead to a segmentation fault at run-time.
• An internal error could be triggered at run-time if multiple shelf literals appeared in different match clauses of a do scan block.
• A function predefined as dynamic and later defined as not dynamic could trigger an internal error if the latter had no arguments.
• A misleading error message was triggered when name of was applied to a function.
• A misleading error message was triggered when set was applied to a function other than a string sink or markup sink function.
• An internal error was triggered if either #content or #current-markup-event was used in a shelf context (e.g., passed to a function as a read-only argument).
• In certain error messages, the built-in type markup-region-event was being described as user-defined.
• A conditional operator containing a pattern variable in one of its two branches could lead to unpredictable behavior.
• If a module exported the predefinition of a conversion-function that was needed in an importing module, an inaccurate error message was emitted.
• A nonsensical error message was emitted if a throw to a catch target had a comma-delimited argument list and was missing an argument.
• A warning is emitted at compile-time when the instance keyword is used to invoke the well-formed XML parser.

What's fixed in the OmniMark 9.0.2 runtime

• Processing instructions captured by #content were causing memory leaks.
• Signalling to a string sink function whose #current-input is being consumed by a string source function could cause a subsequent signal from the latter coroutine to be misdirected.
• After a program error from a signal throw destination coroutine, the always clauses in the signalling scope would not run.
• The second of two signal throw actions with no intervening output could end up being uncaught if the target coroutine delegated its work to another coroutine.
• If two signals were sent with no intervening data to a coroutine that delegated its input processing to another coroutine that would die after the first signal, the second signal would not be caught.
• Signalling to a string source coroutine wrapped in a string sink coroutine could cause a segmentation fault.
• Certain element name tests like previous is could fail inside a do markup-parse.
• A segmentation fault occurred at run-time if a stream was attached with referents-allowed to a referent that had previously been attached to a stream with referents-allowed.
• Processing of %c in a different coroutine than the one that started the parse could lead to uninitialized memory access.
• A complex markup-processing pipeline could cause a segmentation fault.
• If the last coroutine signalled in a chain of coroutines suspended by outputting instead of asking for input from the first one, the next signal could become uncatchable.
• Using signal throw on a coroutine that has already terminated could cause a segmentation fault.
• A chain of functions of markup sink, markup source, and markup sink return types, each invoking the next in turn, could cause a segmentation fault.
• Wrapping a source coroutine in a sink coroutine and using the latter one could change the program behavior.
• copy and save applied to a stream containing referents could lead to incorrect output or internal errors.
• Outputting the %c directly could behave differently from passing it as a value markup source function argument and outputting the argument.
• A copy or save of a stream opened with referents-allowed and then closed could lead to a later segmentation fault.
• Malformed markup errors could lead to memory leaks and memory access errors
• Some complex signalling coroutine pipelines could deadlock.
• As part of a complex pipeline, %c and #content in a markup-comment rule did not behave the same.
• Replacing a markup source function in a pipeline by an equivalent function of markup sink type could cause markup event signals to not be caught.
• A throw from an element rule triggered from a markup sink function could cause a memory leak.
• Use of an in a markup-processing pipeline could cause an internal error and bad memory access.
• Signalling a markup event to multiple destinations could cause an erroneous run-time error.
• Access to #current-markup-event in an element rule from inside a %c scanning scope yielded the last parsed element instead of the element that triggered the rule.
• Complex markup-processing pipelines could sometimes hang.
• An external text entity reference could cause an internal error when parsing an already started coroutine.
• Complex markup-processing pipelines could leak memory.
• Well-formed XML parsing of repeated elements of same name but with different attributes, conducted concurrently with a do markup-parse of the element events, could lead to an internal error or wrong behavior.
• If an external text entity event was passed to a do markup-parse and the original parse was killed immediately after that, an internal error would result.

What's fixed in the OmniMark 9.0.2 libraries

• Invalid UTF-8 character could be generated by the omxerces library, for valid UTF-8 input.
• Function uri.parse in the OMURI library, when given a relative path, was incorrectly providing both the relative and absolute path in its uri-components argument.
• The functions utf8.code-point and utf8.multi-byte-char in the library omutf8 accepted so-called overlong sequences.
• The uri.parse function from OMURI now decodes the hex-encoded characters.
• Function uri.parse in the OMURI library failed to parse URIs with registry names containing special characters.
• The OMVFS library in the Development Package came without the certificates file.

What's fixed in the OmniMark 9.0.2 markup parsers

• The well-formed XML parser could report an internal error if the coroutine producing its input suspended inside a processing instruction.

What's fixed in OmniMark 9.0.1

What's fixed in OmniMark Studio for Eclipse 9.0.1

• An internal error was triggered when debugging a program containing a do select construct.
• If fields of a record instance were expanded in the variable view before stepping over an action that releases the record instance, debugging could not continue.
• remainder function arguments did not show in the variable view during debugging.
• A scanning datascope was not being created when a string sink function was invoked.
• The Use default working directory checkbox in OmniMark launch configuration was always reverting to active state.
• The -reqkeygen command-line option was outputting a wrong error message when used incorrectly.
• Garbage could appear at the end of a referent value.
• When debugging a program that imported OMFLOAT or OMBCD, the first breakable line was incorrect.
• element end tags were duplicated in the right pane of the Parsing Sources view.
• Type names for shelf literals in the global scope were not being properly initialised. This could lead to erratic behavior.

What's fixed in the OmniMark 9.0.1 compiler

• The code generated for access of constant values has been improved.
• A spurious warning was emitted if the only use of a shelf was number of.
• A constant shelf item could not be used as an initializer in an elsewhered function definition.
• The error message emitted when a duplicate or colliding I/O declaration was encountered was needlessly confusing, and lacked information that could help the user correct the problem.
• The error message emitted for conflicting function definitions pointed to the wrong line number.
• A spurious empty pattern warning could be emitted if the single item of a constant string shelf appeared in a pattern.
• A markup source called within the body of a do xml-parse or do sgml parse scope was unable to signal markup events.
• A reference to a constant shelf declared with an empty initializer is no longer allowed in a value context: a compile-time error is now emitted. Such a reference would have triggered a run-time error in previous versions of OmniMark.
• Invalid numeric values were being accepted when initializing an integer from the command-line using the -c command-line option.
• Valid format items (e.g., "%q") were being rejected in optional argument initializers.
• An escape declaration in a module could affect the importer, and vice versa.
• Setting the escape character to certain letters or the space character could make compilation fail.
• Certain combinations of nested modules containing macros could lead to a valid program being rejected at compile-time.
• Using the %g format item on an optional string function argument inside of a conditional operator could lead to an incorrect run-time error about accessing an unspecified optional argument.
• An escape declaration in a program containing a not-reached with no argument or an assert with no argument could cause the otherwise valid program to be rejected.
• An internal error was triggered when the types of the with modifier specifier were incorrect.
• An incomplete error message was emitted when an external conversion-function did not specify an external library binding.
• In some circumstances, the #base and #full element rule lists were not both being searched.

Fixed in the OmniMark 9.0.1 runtime

• Opening a large number of files with referents-allowed could exhaust the number of file handles available.
• A failure to resolve the #dtd external text entity to a file could lead to a segfault if the #content from the failed parse was fed to do markup-parse.
• The error message "A disallowed stream operation was attempted" came with the error code 6030 which was already in use. The error code has been changed to 6146.
• Use of #content in a data-content rule led to an internal error.
• A large contiguous data content region could cause a buffer overflow when consumed through #content.
• Partial scanning of %c could cause an internal error.
• A cdata or rcdata marked section could lead to a segfault at run-time if no rule fired in response to the event.
• A string source literal directly passed as a value string source to a function did not match value-start.
• Default external-text-entity rule was using #library and #libpath shelves from the module where the markup was first parsed, not from the module with the do markup-parse action that triggered the rule.
• An internal error could occur if %c was scanned or submitted in presence of a markup-error rule.
• A markup-error rule that performs a signal throw of its #current-markup-event into a markup-processing pipeline could cause an internal error.
• An internal error was triggered if consumption of #content was interrupted more than once and then continued from inside a markup comment region.
• If the creating sgml-dtds or creating xml-dtds clause was used, the content had to be processed by %c or suppress, as #content attempted to parse beyond the DTD end.
• If do markup-parse was directly applied to a %c, external text entity references were being attached to the inner parse instead of the outer one. This could lead to input corruption and internal errors.
• A signal throw sent to a coroutine that was delegating their handling to another coroutine could not always get through.
• The external-text-entity rules triggered by a do markup-parse were inheriting domain-bound global variables from the domain of the original parse, not the parse that triggered them.
• A shelf of an abstract type could not be saved.
• An attempt to process content from the markup input coroutine could raise an internal error instead of a catchable program error.
• Use of %v on a CDATA attribute could cause an internal error if a translate rule suspended to a different coroutine.
• Throwing from inside a parse launched from a coroutine used as an input to another parse could lead to an internal error.
• A resignalled markup error event could cause a segmentation fault at run time.
• A sequence of user-created markup errors passed through several markup filters could lead to a segmentation fault.
• Character references could be corrupted when captured by #content and then recaptured.
• If an external text entity event was pipelined through more than one markup-parse before being handled, an internal error was reported.
• If a do markup-parse action was applied to a malformed stream where a markup-comment region contained markup events, an internal error was reported instead of a program error.
• The Solaris 10 native build of OmniMark could suffer from degraded performance in certain circumstances.
• The test last content is #data would return an incorrect result if the only data were character entity references.
• In some circumstances, using a dynamic element name in a string source function feeding a markup parse could trigger a segmentation fault at run-time.
• A line break in markup comment coud cause the rest of the comment to be lost if the output of markup-comment rule was processed by another coroutine.
• The newline (LF) characters inside the #content of a markup-comment, invalid-data, or markup-region ignore would be expanded into the CR LF character sequence.
• An internal non-text entity followed by a PI entity was being expanded twice.
• A signal thrown to a chain of alternating markup sink and markup source functions could end up uncaught.

Fixed in the OmniMark 9.0.1 markup parsers

• Invalid processing instructions were being accepted by the well-formed XML parser. A markup error is now being emitted for invalid processing instructions, however processing-instruction rules continue to be triggered as before, to maintain backwards compatibility.
• The validating XML parser was accepting invalid marked sections in the instance of an XML document. Markup errors are now being triggered for invalid marked sections in the instance of an XML document when performing a validating XML parse, however any related rules (e.g.,marked-section ignore) still fire, as before. This limits any backwards compatibility issues.
• #doctype was not being attached for a well-formed XML parse, even though the input contained a DTD.
• dtd-start and dtd-end rules were not being fired when a well-formed XML parse was launched and a DTD was present in the input. This could make it difficult to write generic markup handling code. The behavior is now consistent across all parse types.
• The validating XML parser would accept < in attribute values. This is forbidden by the XML standard, Section 3.1. A markup error is now triggered when a < is encountered in an attribute value, but parsing continues as before, to maintain backward compatibility.

Fixed in the OmniMark 9.0.1 libraries

• An internal error was triggered when validating against the RELAX NG schema for XHTML.
• In the omrelaxng library, the ns attribute was not being inherited for include elements.

What's fixed in OmniMark 9.0.0

Fixed in the OmniMark 9.0.0 compiler

• A pattern variable could not be used in a sub-clause of the same pattern, if it was enclosed using the x or g format item.
• An unhelpful compile-time error message was emitted for the expression name of notation named "a".
• The warning emitted when a shelf was not properly initialized did not contain file name/line number information. This could lead to confusion when two different modules contained shelves with the same name.
• A throw or a run-time error from the body of an external-data-entity rule would lead to unpredictable run-time behavior.
• string sink could not be used as a cast.
• %c was not streaming properly when it appeared embedded in a larger string.
• The with utf-8 argument to do sgml-parse was erroneously being evaluated after the input to the parse had begun executing. This contrary to earlier versions of OmniMark, where it was evaluated before the input. The proper order of evaluation has been restored (i.e., with utf-8 is evaluated before the input).
• The with utf-8 modifier was being ignored when using the subdocument option of sgml-parse.
• If the prefix binary operator or the complement operator were used in a shelf reference context, an internal error would be triggered.
• An internal error was triggered if an expression containing operator new applied to a stream shelf was passed as a shelf-class argument to a function.
• The with id-checking parameterization was being allowed when launching the well-formed XML parser. This is contrary to the specification.
• Conflicting definitions for dynamic and/or overriding functions could lead to misleading error messages.
• An invalid invocation of do markup-parse could trigger a segmentation fault at compile-time.
• The error message emitted when the void action was applied to an invalid type was misleading.
• The error message emitted when applying save or save-clear to a string source or string sink was confusing.
• A catch could not be declared following the declaration of a record type exported as opaque.
• The built-in shelf #xmlns-names is now declared as a string shelf, rather than as a stream shelf. This change can be reflected in certain error messages.
• The OmniMark compiler could take an amount of time exponential to the number of mutually-referencing record types.
• If the only use of a single-item, fixed size shelf was in the header of a repeat over with an alias, no warning was emitted about it being otherwise unused.
• An invalid memory read was triggered if an else clause appeared in a do select-type block containing an invalid type name as one of its cases.
• If a value-returning function failed to return a value from the else clause of a do ... done block, the line number reported in the error message would point to the last action of the previous block.
• A string sink identity cast (i.e., casting a string sink expression in a context requiring an expression of type string sink) would lead to an internal error at compile-time.
• If an exception occurred in a match clause of a do scan ... done block, the line number reported in the error message would point to the last action of the previous block.
• It was possible to repeat over two shelves of differing sizes, if the larger shelf was declared variable. This is contrary to the specification and contrary to statements made in the documentation.
• If a fixed-size shelf of size 0 was used in the header of a repeat over where a pseudo-shelf or a variable-size shelf was also present (e.g., attributes), an invalid error message was triggered, claiming that the shelves have different sizes, even when the pseudo-shelf was also empty.
• A numeric literal was allowed in a pattern. This is contrary to the specification, and is no longer allowed.
• A program that shadowed the and infix operator by a user declaration, and then used it between two string sinks, would no longer compile. Such a program is valid and should be accepted.
• An optional value string sink function argument could not have an initial clause containing a conditional operator.
• An inaccurate error message was emitted when an overriding of a dynamic function was dispatching on an exported type, but not itself exported.
• The -depend command-line option now includes external function library information in its dependency graph.
• The first argument in the invocation of a parenthesised, overloaded function was not being correctly parsed by the OmniMark compiler. This would lead to a syntax error. A workaround was to insert additional parentheses around the argument.
• void on a string source expression could lead to inefficient execution.
• Appending modifiers to a read-only stream in a string sink context could lead to segmentation fault.
• Appending modifiers to a string value in a string sink context could lead to segmentation fault.
• Hiding the keywords variable and/or size with a shelf declaration could lead to a confusing error message.
• Under exceptional circumstances, it was possible for a program's string literals to get corrupted.
• initial as a function argument herald was not being handled properly in various contexts. This would lead to the rejection of correct programs.
• The error message emitted for conflicting argument counts contained a grammatical error.
• Using argument pass-through with an optional string sink argument initialized to a stream would lead to a segmentation fault at run-time.
• An xmlns-change rule in a multi-module program, where the main module ends with a function, could cause all rules in other modules not to fire.
• Throwing an exception from the header of an external-text-entity rule would lead to a segmentation fault.
• In certain circumstances, external-text-entity rules and external-data-entity rules could lead to unpredictable behavior in later parts of the program.
• A throw or a run-time error from the body of an external-data-entity rule would lead to unpredictable run-time behavior.
• The compile-time error message triggered on mismatched catch clause arguments was confusing.
• Passing a read-only stream to a function expecting a value string sink argument would lead to a confusing error message.
• An internal error was triggered when a value switch argument was aliased in a repeat over loop. A workaround was to drop the alias and use the argument name directly.
• The compile-time message emitted when a read-only stream was used in the header of a using output as did not make sense.
• If counter was used as a type herald, the error message thereby triggered referred to integer as the type.
• If int32 was used as a type herald, the error message thereby triggered referred to integer as the type.
• Using take on a string source on the right-hand side of a matches could lead to the string source being entirely consumed.
• Referencing #current-input or #current-output in a using shelf item association would trigger an internal error at compile-time.
• #current-output was accessible in the body of a markup sink function. This is contrary to the specification.
• A markup sink function was being rejected on the left-hand side of set.
• A warning is now emitted when a shelf literal is being used where a simple expression would suffice.
• Spurious warnings were emitted when record types were being assigned.
• A join in a find rule could trigger an incorrect compile-time warning, and could also negatively impact performance.
• A repeated (||*) in a pattern was not being compiled properly; this would lead to inefficient execution at run-time.
• A warning is now emitted when the g format item is encountered alone in a string; the use of the g format item in this way is redundant, and should be eliminated.
• The error message triggered for an undeclared string in a g format item referenced the wrong line in the program.
• An incorrect error was being emitted when the require qualifier was encountered in a shared module.
• A keyword could not be used as a module prefix.
• The set new action on a record shelf was not constructing intermediate values.

Fixed in the OmniMark 9.0.0 run-time

• The body of an external-text-entity rule in OmniMark 8 was run in a coroutine whose parent was the current element rule, in contrast to the correct input domain parent coroutine in earlier versions of OmniMark. The behavior has been corrected.
• The effects of sgml-in and sgml-out were being incorrectly propagated to XML parses launched as children of a parent SGML parse.
• Whitespace was being dropped when a well-formed XML parse was launched as a child of a validating XML parse.
• If a consumer coroutine suspended using the output action before trying to consume its input, it could be left suspended in that position. This caused problems if the suspension preceded a catch clause that was supposed to handle signals coming through its input.
• A segmentation fault could occur if a string was returned from a function, and the string was a run-time constant (e.g., the name of an external string sink attachment).
• The values of #markup-error-count and #markup-warning-count were not local to the current parse in case of multiple co-routining parses.
• A confusing error message was emitted when attempting to copy a shelf with a variable size to one with a fixed size, and the two sizes did not match.
• A throw from a string source function used by a do xml-parse could cause a memory leak.
• Leaving a stream attached to a referent unclosed by the end of the referent scope could lead to a segmentation fault.
• In a scenario where multiple OmniMark threads are running in OMWSB, a markup error in one thread could corrupt the state of other threads, leading to an internal error or unpredictable behavior.
• The presence of a markup-error rule could cause the subsequent markup error reports to leave out the exact error locations.
• Under certain circumstances, the status of last subelement is inclusion test could return an incorrect result.
• A log directive in a markup-error rule launched from one parse could affect the logging of a different markup-error rule.
• In some circumstances, referents could not be written to a stream attached to a referent, even though referents had been enabled.
• A value written to a stream attached to a referent that had previously been assigned a value with referents-allowed, was being appended to the previously-assigned value rather than replacing it.
• name of #suppress would lead to an internal error at run-time.
• #suppress has name would lead to an internal error at run-time.
• After the consumption of #current-input in a string sink function was interrupted by a signal, it could not be resumed if the take operator was being used.
• If no element rule was fired, OmniMark would report an error message with no file name and line number.
• In certain contexts, a guarded new could lead to a run-time error about accessing a non-existent shelf item.
• A markup error in the input could cause an internal error if multiple OMWSB services were running in parallel.
• A well-formed XML parse would allow the carriage return character (%13#) to propagate to the output: this is contrary to the XML specification.
• A signal sent to multiple coroutine sinks (combined into a single sink by the & operator) at the same time stopped its propagation as soon as one of the target coroutines suspended to any coroutine other than the signalling one.
• Executing output-to at the top-level of a string source function called as the argument to file would lead to a segmentation fault at run-time.
• If any content modifers were set, but a %c was run in a separate coroutine, the modifiers were ignored.
• Referring to an undeclared notation in a DTD scanned by the well-formed XML parser would trigger an internal error.
• translate patterns erroneously matched a content-end when content was interrupted by a processing instruction, comment, or marked section.
• A signal thrown from a markup rule could cause an internal error.
• Artifacts of markup parsing were not being updated properly when using an external markup parser.
• An internal error was triggered if a string sink function with referents-allowed was passed to a second function as a value string sink argument, and the latter function terminated without yielding to its argument. Typically, this meant the argument was not accessed in the body of the second function.
• Multiple, nested joins would lead to a segmentation fault at run-time.
• It was possible to trigger an internal error by outputting referents into a string sink function that parses its #current-input .
• An internal error was triggered when a throw occurred in a markup-error rule and a processing instruction was being parsed by the well-formed XML parser.
• If any markup-comment rules were present in a program, the text of every markup comment that did not trigger any of the rules would be submitted to translate rules, when it should have been suppressed instead.

Fixed in the OmniMark 9.0.0 markup parser

• An incorrect error message was emitted when an invalid owner identifier in the public identifier of a notation declaration was encountered.
• The well-formed XML parser was incorrectly accepting -- in comments; this is contrary to the specification.
• An error message referring to an SGML document was emitted by the validating XML parser if an XML document did not contain a valid DTD.
• The validating XML parser did not properly handle hexadecimal character references with leading zeroes.
• The well-formed XML parser was rejecting parameter entity references in the DTD if they were not properly nested with markup declarations. According to the XML standard, this is a validity constraint, not a well-formed constraint.
• An undeclared notation was triggering a markup error in a well-formed XML parse; this is contrary to the specification.
• Invalid character references were being accepted by the well-formed XML parser. It now implements the restrictions dictated by the XML 1.1 specification.
• Referring to an undeclared notation in a DTD scanned by the well-formed XML parser would trigger an internal error.
• In a scenario where multiple OmniMark threads are running in OMWSB, a markup error in one thread could corrupt the state of other threads, leading to an internal error or unpredictable behavior.
• The well-formed XML parser would incorrectly trigger a markup error if more input was required while reading the doctype keyword.

Fixed in the OmniMark 9.0.0 libraries

• The OMCGI library function cgiGetQuery could fail with a program error for certain inputs.
• The external OMRTF parser would segmentation fault.
• OMVFS library triggered a compiler warning about uninitialized data access.
• The function HttpRequestSetFromUrl in the OMHTTP library did not correctly parse a URL if the query string component contained an @ sign.
• A source filter's output could be terminated too early if its argument produced a zero-sized chunk.