This is a drive-by revert of a useless change in everyone's favorite commit, 6e5955c4 ("Most of the code folded in"). The line in question is a structure assignment, which is in C99 and behaves exactly as one would expect.

While we generate an error message in parse_xrefs() for this case, parse_xrefs is not the right place to cause the parse error. That should be a semantic validation in the parser proper. Other checks in parse_xrefs can probably be moved completely out of the function in that vein, too. But we will leave doing that properly for another time. For now, let's put a comment to the effect in parse_xrefs and disable the failing test case by masking its .pdf extension.

Not everything is needed outside of init_parser(). Also clear out some gratuitous whitespace.

Duplicates the previous commit. Note that we must pull the INVALID pointer out of resolve() so that resolve_item() can use the same one. Otherwise, the two function could confuse each others' INVALID pointers for valid objects.

Finally. Remove these now-redundant functions.

It is not entirely clear whether the spec allows cyclic object definitions such as the following: obj 1 0 1 0 R endobj There is an open errata issue about this topic, but no consensus has emerged so far. Most implementations will accept this, however, so for the time being I'm guessing we should, too. We will treat an object that is defined (directly or indirectly) as itself as equivalent to the null object. The implementation strategy is to give ourselves an distinct invalid pointer beside NULL and use it to mark the memoization entry for a given cross-reference (ent->obj) as INVALID while we recursively try to resolve it. If we eventually hit an INVALID object, we terminate the process and return NULL. The INVALID entry will internally stay in the memoization slot, but should never be returned by resolve(). This commit contains the implementation for resolve(). We'll do its unfortunate copy-paste sibling resolve_item() in the next one.

We can cover the single-stream case by doing what the multi-stream case does: Get the stream object, validate that its value type is TT_BYTES, and run p_textstream parser over those bytes from parse_pagenode. No need for a special version of p_objdef, kstream, or resolve for that matter.

This commit contains a failing test case. It contains a stream with a /Type entry that is an indirect reference to an object defined as itself: obj 8 0 8 0 R endobj The implementation of resolve() does not properly detect cycles and runs into an infinite loop.

Similar to kbyteostream, kcontentstream is a specialized version of kstream that replaces the generic switch on /Type for the data parser. This version uses either p_textstream (the parser for content streams) or p_objstm__m. I think the latter case must have been the result of some confusion. Object streams are something completely different than content streams and cannot appear in place of one. That leaves kcontentstream identical to kbyteostream except that it uses p_textstream (parsing the stream data directly) instead of p_bytes (leaving the stream data to be parsed in parse_pagenode)...

I can't find the spec saying this has to be a direct object, so we have to call resolve() on the value.

I don't know what the purpose of any of these was, it looks like they were put in as a matter of course just in case it would later turn out that some final cleanup code was needed. Do not write cruft code just in case.

What is this?

If we inspect p_byteostm, we see that it is nothing but a specialized form of p_objdef that replaces the object parser with byteostream which in turn is a specialized form of the stream parser that replaces the switch on /Type (in kstream/kbyteostream) with always using p_bytes, thus returning the stream data (after filters) as raw TT_BYTES. But kstream also treats an unrecognized or unspecified /Type with p_bytes. So, since a content stream should have none of the types recognized, we can just use p_objdef and thus resolve() here and eliminate that whole branch of copy paste. The only downside is that we're now allowing any object to appear where a stream should be (from the content parser's point of view). All we are missing though, is a proper token type for stream objects and a simple check in place of that XXX...

Come on.

This removes the original use of outfn2/stream2 (corresponding to Xfile in main, i.e. the argument to -X) and reuses it for being verbose about fonts. This leaves -x as showing only the text and fixes our tests. It looks to me like the original outfn2 path is a less refined version of the outfn version, though it could be the other way around. Sumit told me that one of the two could go away at some point. Unfortunately, I cannot find the original message. We can readjust this as needed.

h_indirect() is for when you need to refer to a parser before its definition.

This might be severely pedantic nit-picking, but we're not writing one element of size nchars, we're writing nchars elements of size 1, hmpf. Yes, nmemb is also a size_t. ;) NB: The main purpose of these arguments is to let fwrite check for overflow when multiplying them. So yes, technically the order almost certainly doesn't matter when one of them is 1. It does affect the return value (which is not checked here) in that it will report how many bytes were written in one case or just 0/1 in the other.