[THE_PUN_STOPS]

"It might be possible to embed a C compiler into a PDF by compiling it to JS with Emscripten, for example, but then your C compiler has to take input through a plain-text form field and spit its output back through a form field."

[shadowofneptune]

You know, when I read "Horrifying PDF," I thought it would be an exaggeration.

[makomk]

Even just basic text is... interesting in PDFs. A few years back, I created a PDF which displayed its own MD5 hash by making every single letter a separate chain of sub-documents and using MD5 collisions to change which sub-document each pointed to without changing the hash. Pretty much every PDF reader managed to interpret this cleanly as ordinary, copy-and-pasteable text because it wasn't any worse than they could expect to encounter in an ordinary PDF, and they all had robust heuristics for dealing with these kinds of shenanigans. (The exception I found was PDF.js, possibly due to the fact it was rendering the whole thing to HTML.) The only real issue was that every PDF reader had a slightly different idea of what characters I could safely use in the names of those nested documents.

[quotemstr]

Well yeah. Why is that horrifying? Give any Turing complete system whatsoever basic IO capabilities and you can make it compile C.

[kangalioo]

Yes, but why is a document format turning-complete in the first place

[layer8]

Because it evolved to also be a client-side form fill-in & validation etc. format. It’s quite similar to Javascript use for HTML forms.

[saagarjha]

It’s often hard to make it not be. Heck, the fonts themselves are probably Turing complete.

[phreack]

You might enjoy this then! https://www.gwern.net/Turing-complete

[wwweston]

Would be more impressive it could still compile input to the form field after I print it out.

[derefr]

Now that's an intriguing concept. "A file format for declaratively specifying a physical data-communication artefact, abstractly-defined by the interactions it supports."

• Just showing the user text? Compiles to plaintext.

• Get the user to give some input? Compiles to a styled form, as PostScript.

• Add radio buttons? Compiles to a physical form but with a 3D-printed notched slider glued to it.

• Require validation for freeform-text form fields? Compiles to a 3D-print + VLSI + pick-and-place specification for a tablet embedded-device that displays the form and does the validation.

Now imagine a "printer" that takes such abstract documents as input, and can print any of these... :)

[Buttons840]

If it can't, must be a printer bug. Can't even print a PDF!

[ljm]

Maybe if you bury the page deep within a forest, so the compiler could hook into the distreebuted CPU cluster in order to facilitate more effective computation.

[FlyMoreRockets]

E-ink to the rescue.

[vuciv1]

i kinda have a noob question. doesn't a compiler just translate high level code to low level code?

it doesn't actually execute code, right? Then what's the power of having a compiler in a PDF? you can output the executable, but can you run it?

also, is the "input" and "output" of this compiler just code and executables?

[xg15]

I don't think the example had any practical use, really. I understood it more as an illustration of how weird Chrome's scripting support is: On the one hand, it lets you put programs as complex as a working C compiler in there - but on the other hand, interaction with the outside world is limited to putting stuff into text fields...

> also, is the "input" and "output" of this compiler just code and executables?

Mostly yes. I'm not sure how much of a typical build chain he was trying to convert to JS here, but the compiler itself typically takes a bunch of files with C code and outputs a number of "object files", which are really chunks of machine code. In an actual build process, you'd then use a linker to glue those object files together in the right way and make an executable.

I guess, what you could do if you wanted was to include the whole build chain (including linker) into the PDF, encode the executable as Base64 and fill some form field of the PDF with it. Then your workflow would be as follows:

1) Write some C code

2) Copy the C code into form field #1 if the PDF.

3) Hit a "compile" button or something. Form field #2 fills with what looks like an enormous amount of random gibberish (really the Base64-encoded binary)

5) Copy all the text from form field #2, use a program of your choice to decode the Base64 and save the decoded binary on your hard drive.

6) Run the binary on your hard drive and watch your C code execute. Hooray!

[vuciv1]

ah this was perfect and really cleared it up for me! thanks!

[bsaul]

You compile C to « js ». Then pdf readers being able to execute js, you can basically execute C.

[gpvos]

If you have an eval function or some kind of API to start that execution.

[bawolff]

Eval() is part of the js language so you obviously do. But regardless you could make your own interpreter if neccessary. You could compile to x86 and then run it in your own VM if you felt like it.

[josefx]

Or run your own JavaScript interpreter, of course nesting interpreters that way is going to be horribly slow.

[xg15]

I mean, despite all the weirdness, it's all still run by Chrome's V8 in the end, so it might work...

[klyrs]

> it doesn't actually execute code, right? Then what's the power of having a compiler in a PDF? you can output the executable, but can you run it?

Depends what you mean by "run", really. You can write a full-on X86 emulator, and execute a compiled binary there. But given that it's an emulator running in a nested series of sandboxes, it won't be terribly useful -- for example, it still won't have I/O capabilities.

[cbozeman]

This is truly the 9th circle of Hell...