🚀 go-pugleaf

clive@stdc.demon.co.uk (Clive D.W. Feather) wrote:
>In article <44sfo3$mbe@news0.rain.rg.net>, Paul Long  <plong@perf.com> wrote:
>> berthold@ix.netcom.com (Richard Berthold) wrote:
>>> I have written a program which outputs C code and recently ran into a
>>> problem under OpenVMS related to the length of lines of code. It is not
>>> difficult to split the output into multiple lines with a \ at the end
>>> of the multiple lines but I have some questions about how sophisticated
>>> an algorithm must be used.
>> I may be able to find the code I wrote that'll do all the
>> splitting for you automatically between tokens.
>
>To clarify, though, the splitting does not need to be between tokens.
>A line length limiter program could be as simple as:
[snip:yeah, right :-) ]
>/* or, more practically: */
[snip:that's more like it]

You are certainly correct that one does not _need_ to split lines
between tokens. However, here are two reasons to do so:

First, one often has little control over the length of a
machine-generated logical line, which I believe is the core problem
that the original poster is experiencing. Even though your program would
split a logical line into several physical lines, this does nothing to
prevent that spliced logical line from being "too long" in the first
place. If it is longer than the 509-character limit, the resulting
program would not be strictly conforming, or, more practically, the
line could be longer than the limit imposed by the implementation
(if any). For example, Borland gets an out-of-memory error at a little
over 1000 characters. This may be an unreasonable length for a
machine-generate program.

Second, machine-generated C must often be read by a human, either to
simply understand the program when C is used as an intermediate language
or to maintain it, as is the case with source translators. Think about
it. I know that I'd rather look at a properly indented C program than
one that has margin-to-margin code.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.