In GhostPCL 9.23 (not in earlier versions) an input file path that begins with the "#" character causes the program to stall. So an input filename #LPT1.ASC causes the stall (but .\#LPT1.ASC works as designed). This issue was discussed on IRC on 25 May 2018, from 12:11 through 13:15. Here is a link: https://ghostscript.com/irclogs/20180525.html This problem surfaced when I tried to use 9.23 with the vDos DOS emulator, which uses GhostPCL to convert a PCL file named #LPT1.ASC into a PDF file.
This isn't a pdfwrite problem, the loop occurs right at the top level of interpretation and is independent of the device.
Correcting the link in comment 1 https://ghostscript.com/irclogs/2018/05/25.html
There's been some recent internal discussion, and there seems to be some confusion about this bug, so to clarify the situation for whoever works on it next: To reproduce the problem, the leading character of the input filename needs to be a '#'. So: gs #tiger.eps fails, while: gs ./#tiger.eps does not, possibly this is why some people are having trouble reproducing the issue. There was some discussion about deprecating the use of '#' for '=' in parameter passing. This is not currently acceptable in my opinion. The '#' is intended for use in passing parameters to Windows batch files. The command processor on Windows stops when it encounters a '=' sign, which truncates the parameter passing to the batch file, which is why we permit the use of '#' instead. We supply a number of example scripts, particularly ps2pdf, which potentially take parameters, and which need to be able to work on Windows (*lots* of people use this) in addition to not breaking any batch files that existing users have written. As an example: ps2pdf -sOutputFile#/temp/out.pdf works while: ps2pdf -sOutputFile=/temp/out.pdf will not, the command processor will only pass '-sOutputFile' as %1. More importantly, according to the IRC log, its not the processing of # for = that is causing the problem anyway. The problem is apparently that, at a high level, the argument processor treats a # as a comment, and ignores everything until the EOL. I believe this may be for the @file input option where very large lists of options can be supplied in a file. Possibly intended for being able to comment that file. Obviously I have no problem with removing that capability, provided we check to ensure its not currently documented, or if it is, we update the documentation to say its been removed. I think there is another problem there too (also from the IRC logs at about 13:02) because the loop is supposed to terminate when c == 0, but get_codepoint never returns 0, it returns -1.
Fixed in: commit 18e4b59efeca56ec2ca716559a7b9e0639561428 (golden/master) Author: Robin Watts <robin.watts@artifex.com> Date: Thu Jul 5 18:04:28 2018 +0100 Bug 699379: Fix infinite loop with filenames starting with #. The argument handling routines treat lines starting with # as being comments. Unfortunately, the logic for this was failing to recognise EOF as stopping the search for the end of a line. Doubly unfortunatately, it was extending this courtesy, intended for lines within @files to command line arguments too. We take steps to avoid that too. (which relies on its predecessor too).