New Ghostscript PDF interpreter

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment (cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022.

The post has no explananation of this choice. Does anyone know?

Re: New Ghostscript PDF interpreter

#6

Post by aidos » Sun, Jul 31, 2022, 4:54 PM UTC

Does anyone know much about the Artifex team? How big it is etc?

They seem to be the kings of working with PDFs. I’ve not really looked at the Ghostscript code (and I’m surprised to hear their interpreter was still in postscript), but I’ve looked through the mupdf code and what I saw was really nice.

In any case, I appreciate the work they’ve done in providing fantastic tools to the world for decades now.

Re: New Ghostscript PDF interpreter

#7

Post by lordfosco » Sun, Jul 31, 2022, 4:56 PM UTC

Most important part of the announcement - you can still revert back to the former interpreter by setting the `-dNEWPDF=false` flag.

While progress is always nice to see - I am also pleased that we don't necessarily need to update all the scripts that depend on ghostscript at once but can keep them running in their current state.

Re: New Ghostscript PDF interpreter

#8

Post by h2odragon » Sun, Jul 31, 2022, 4:59 PM UTC

vintagedave wrote: post #5

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

I suspect they need portability more than most projects.

Re: New Ghostscript PDF interpreter

#9

Post by amluto » Sun, Jul 31, 2022, 5:04 PM UTC

vintagedave wrote: post #5

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

Beyond a lack of memory safety, C has another issue that makes me dislike it for this kind of application: C has a very minimal set of built in data structures. Combined with a lack of generics, this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary. This is almost invariably done with lots of pointers (since C has no better-constrained reference type), and the result can be bug-prone and difficult to refactor.

For all of C++’s faults, at least it’s possible to use a map (or unordered_set or whatever) and mostly avoid encoding the fact that it’s anything other than an associative container of some sort at the call sites. This is especially true in C++11 or newer with auto.

Re: New Ghostscript PDF interpreter

#10

Post by ris » Sun, Jul 31, 2022, 5:06 PM UTC

lordfosco wrote: post #7

Most important part of the announcement - you can still revert back to the former interpreter by setting the `-dNEWPDF=false` flag. While progress is always nice to see - I am also pleased that we don't necessarily need to update all the scripts that depend on ghostscript at once but can keep them running in their current state.

It's particularly fun for them to introduce this in a point release. If this didn't warrant a major version bump I'm frankly not sure what would.