[comp.lang.c] Max line length

jfc@athena.mit.edu (John F Carr) (03/12/89)

>Of course, you need to delete the newline after the first line.

What is the longest line allowed in a C program?  Does the standard say?
Do present compilers care?

--
   John Carr             "When they turn the pages of history,
   jfc@Athena.mit.edu     When these days have passed long ago,
   bloom-beacon!          Will they read of us with sadness
   athena.mit.edu!jfc     For the seeds that we let grow?"  --Neil Peart

klatchko@cory.Berkeley.EDU (ron klatchko) (03/13/89)

In article <9777@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
>>Of course, you need to delete the newline after the first line.
>
>What is the longest line allowed in a C program?  Does the standard say?
>Do present compilers care?

That is implementation dependent.  If your compiler attempts to read in 
an entire line at a time and digest it, then you're compiler would have 
some maximum length.  If the compiler reads the the code in character by 
character (lex does this), then there should be no maximum length.

--------------------------------------------------------------------------------
Ron Klatchko          klatchko@cory.Berkeley.EDU        ...!ucbvax!cory!klatchko   

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/13/89)

In article <9777@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
>What is the longest line allowed in a C program?

It depends on the implementation (naturally).

>Does the standard say?

A conforming implementation must accept a program containing 509 characters
in a logical source line.  A "logical source line" is what results after
lines ending in a \ are spliced with the following physical source line.
Constraints on physical source line length are left up to various
implementations; I wouldn't recommend relying on more than 80 characters
(not counting newline).

>Do present compilers care?

Certainly many of them do.

mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (03/13/89)

In article <11005@pasteur.Berkeley.EDU> klatchko@cory.Berkeley.EDU.UUCP (ron klatchko) writes:
+In article <9777@bloom-beacon.MIT.EDU> jfc@athena.mit.edu (John F Carr) writes:
+>>Of course, you need to delete the newline after the first line.
+>
+>What is the longest line allowed in a C program?  Does the standard say?
+>Do present compilers care?
+
+That is implementation dependent.  If your compiler attempts to read in 
+an entire line at a time and digest it, then you're compiler would have 
+some maximum length.  If the compiler reads the the code in character by 
+character (lex does this), then there should be no maximum length.

The proposed standard does say that all compilers must be able to support 
at least a 509 character logical source line.  (ss 2.2.4.1 Environmental
Considerations).  Obviously, if your compiler supports more, that is fine,
but as a programmer, you should not write code that would require lines
longer than 509 characters after they have been combined.

-- 
Mark H. Colburn                  "Look into a child's eye;
Minnetech Consulting, Inc.        there's no hate and there's no lie;
mark@jhereg.mn.org                there's no black and there's no white."

msb@sq.com (Mark Brader) (03/14/89)

> What is the longest line allowed in a C program?  Does the standard say?
> Do present compilers care?

It's still a proposed standard, technically.  X3 has accepted it,
so it will be becomes a standard, but it hasn't actually been
officially called one yet.

#  2.2.4.1  Translation Limits
#     The implementation shall be able to translate and execute at least
#  one program that contains at least one instance of every one of the
#  following limits*:
#
#     ...
#     509 characters in a logical source line
#  ...

#  *An implementation should avoid imposing fixed translation limits
#  wherever possible.

"Logical" source line is defined in 2.1.1.2 as what you get after you
(notionally, at least) replace your system's idea of end-of-line with
UNIX-like newline characters, translate trigraphs into the corresponding
characters, and then eliminate any backslash-newlines.

By the way, any nonempty source file is required to end with an
unbackslashed newline.  Of course, a compiler is at liberty to ignore
this requirement.

Now I suppose I should describe trigraphs, to forestall any followups from
new readers.  C was designed to use almost the full ASCII character set,
which causes problems in Europe where the bit patterns that ASCII uses for
things like # and \ and { are instead used for accented letters (different
ones in different countries, yet), and so, many terminals lack those
characters altogether.  As a partial workaround for this problem -- and
nobody pretends it is more than that -- an ANSI C compiler is required to
recognize in its initial translation phase the sequences ??= ??( ??/ ??)
??' ??< ??! ??> ??- (called trigraphs) and replace them respectively with
the characters # [ \ ] ^ { | } ~ which are needed for C but may not be
available in some character sets.  Please DO NOT post suggestions for
alternatives to the net; all possibilities have been discussed AT LENGTH.

The sed command in my signature below is to fix any old programs that may
have accidentally contained trigraphs (the only likely case would be
printf ("What??!\n");) by inserting a backslash between the ?'s to break
up the trigraph without changing the string.  ('\?' == '?' in ANSI C.)

Mark Brader, Toronto		sed -e "s;??\\([-=(/)'<!>]\\);?\\\\?\\1;g"
utzoo!sq!msb, msb@sq.com	will fix them...	-- Karl Heuer

guy@auspex.UUCP (Guy Harris) (03/14/89)

>What is the longest line allowed in a C program?

It depends on the implementation.

>Does the standard say?

Well, there's no standard, there's just a proposed standard, but the
December 7, 1988 draft, which is probably now the proposed standard (and
which is probably going to be very similar to the final standard) says:

	2.2.4.1 Translation limits

	   The implementation shall be able to translate and execute at
	least one program that contains at least one instance of every
	one of the following limits:

	...

	   + 509 characters in a logical source line

	...

In a footnote, it says "Implementations should avoid imposing fixed
translation limites whenever possible."

jeenglis@nunki.usc.edu (Joe English) (03/16/89)

guy@auspex.UUCP (Guy Harris) writes:
>Well, there's no standard, there's just a proposed standard, but the
>December 7, 1988 draft, which is probably now the proposed standard (and
>which is probably going to be very similar to the final standard) says:
>
>	2.2.4.1 Translation limits
>
>	   The implementation shall be able to translate and execute at
>	least one program that contains at least one instance of every
        ^^^^^ ^^^ ^^^^^^^
>	one of the following limits:
>

Huh?  Now I'm probably reading this wrong, but the way I
parse this sentence it means:

 If (there exists a program P such that
        (     (for all L in {following limits} P contains an instance of L)
          and (the implementation can deal with P)
        )
    )
 then the implementation is in compliance with section 2.2.4.1.


Shouldn't it say instead:

  If (for all programs P such that 
            (there exists an L in {following limits} such that P contains L)
      the implementation can handle P
     )
  then the implementation is in compliance with section 2.2.4.1?

Put simply, if I write a compiler that will correctly
translate and execute *one* program that contains a 509-character
line, a 31-character identifier, and so on, but barfs
on all other programs, does that pass 2.2.4.1?

(Obviously the answer is "no," and I've misinterpreted the
excerpt.  Can someone explain the language here?)

--Joe English

  jeenglis@nunki.usc.edu

bph@buengc.BU.EDU (Blair P. Houghton) (03/17/89)

In article <3072@nunki.usc.edu> jeenglis@nunki.usc.edu (Joe English) writes:
>guy@auspex.UUCP (Guy Harris) writes:
>>
>>December 7, 1988 draft, says:
>>	2.2.4.1 Translation limits
>>
>>	   The implementation shall be able to translate and execute
>>	at least one program that contains at least one instance of
>       ^^ ^^^^^ ^^^ ^^^^^^^
>>	every one of the following limits:
>
>Shouldn't it say instead:
>
>  If (for all programs P such that 
>            (there exists an L in {following limits} such that P contains L)
>      the implementation can handle P
>     )
>  then the implementation is in compliance with section 2.2.4.1?
>
>(Obviously the answer is "no," and I've misinterpreted the
>excerpt.  Can someone explain the language here?)

I did the same double-take at that semantic curveball, but then I looked
askance and it seemed to be sensible.

For instance, your version says that the compiler should compile EVERY
program that contains those limits, but, your program may be broken in
many other ways, and your version of this rule would STILL require the
compiler to compile it, which is patently impossible.

The rule as it is written allows for the rejection of a program if it
breaks other rules, but if it does not, then that program has got to be
compiled, provided it is within these limits, even if the program
stretches to use all of these limits.

The program implied by "at least one program" would therefore be the
program with all of its syntax perfectly C, and using _all_ of the
limits given.

Does anyone have any intention of writing such a program?  Is anyone going
to write the ANSI-C "exerciser" program?  Sounds like fun.

				--Blair
				  "510 or fight!"

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/17/89)

In article <3072@nunki.usc.edu> jeenglis@nunki.usc.edu (Joe English) writes:
->	   The implementation shall be able to translate and execute at
->	least one program that contains at least one instance of every
-        ^^^^^ ^^^ ^^^^^^^
->	one of the following limits:
-Huh?  Now I'm probably reading this wrong, but the way I
-parse this sentence it means:
- If (there exists a program P such that
-        (     (for all L in {following limits} P contains an instance of L)
-          and (the implementation can deal with P)
-        )
-    )
- then the implementation is in compliance with section 2.2.4.1.

Right.

-Shouldn't it say instead:
-  If (for all programs P such that 
-            (there exists an L in {following limits} such that P contains L)
-      the implementation can handle P
-     )
-  then the implementation is in compliance with section 2.2.4.1?

Nope.  If a program pushes all the limits simultaneously, an
implementation that dynamically allocates resources might be
unable to translate the program, yet still be perfectly usable
for the vast majority of programs.

-Put simply, if I write a compiler that will correctly
-translate and execute *one* program that contains a 509-character
-line, a 31-character identifier, and so on, but barfs
-on all other programs, does that pass 2.2.4.1?

Yes.

Here's the relevant text from the Rationale for Section 2.2.4.1:

	The Standard requires that an implementation be able to
	translate and compile some program that meets each of the
	stated limits.  This criterion was felt to give a useful
	latitude to the implementor in meeting these limits.
	While a deficient implementation could probably contrive
	a program that meets this requirement, yet still succeed
	in being useless, the Committee felt that such ingenuity
	would probably require more work than making something
	useful.  The sense of the Committee is that implementors
	should not construe the translation limits as the values
	of hard-wired parameters, but rather as a set of criteria
	by which an implementation will be judged.

	Some of the limits chosen represent interesting
	compromises.  The goal was to allow reasonably large
	portable programs to be written, without placing
	excessive burdens on reasonably small implementations.

mcdonald@uxe.cso.uiuc.edu (03/17/89)

#  2.2.4.1  Translation Limits
#     The implementation shall be able to translate and execute at least
#  one program that contains at least one instance of every one of the
#  following limits*:
#
#     ...
#     509 characters in a logical source line
#  ...

#  *An implementation should avoid imposing fixed translation limits
#  wherever possible.


Is that REALLY true? "at least one program" is a loophole larger than
the hole in the Titanic. What if it indeed translated and executed
one particular program by including the text of one specific
program in itself, checking for that program, and then spitting out
a hand coded compiled result? 

bph@buengc.BU.EDU (Blair P. Houghton) (03/18/89)

In article <2314@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>In article <3072@nunki.usc.edu> jeenglis@nunki.usc.edu (Joe English) writes:
>>guy@auspex.UUCP (Guy Harris) writes:
>>>
>>>December 7, 1988 draft, says:
>>>	2.2.4.1 Translation limits
>>>
>>>	   The implementation shall be able to translate and execute
>>>	at least one program that contains at least one instance of
>>>	every one of the following limits:
>>
>>Shouldn't it say instead:
[...you've seen that part...]

Some of what I replied:
>The program implied by "at least one program" would therefore be the
>program with all of its syntax perfectly C, and using _all_ of the
>limits given.

Yep.  I'm wrong, and it's that snidely whiplash, Doug Gwyn, that dood it,
by posting the rationale.

It seems that "all of its syntax perfectly C" is completely ingermane.

2.2.4.1 implies that a {Fortran,Pascal,Algol,*} program that exercises
all of the 2.2.4.1 limits is acceptable C wrt 2.2.4.1.  The fact that
it breaks all the other rules doesn't matter to 2.2.4.1.  That's what
all the other rules are for.

And they came up with 509 chars as a minimum maximum-edible line length
to give small computers a chance.  I assume this means that an
implementation that allows, say, 1021 chars on a line would be
encouraging the creation of non-universally-portable code, and therefore
there's something that makes such an implementation non-conforming.

Yes?

				--Blair
				  "510 or Fight!"

david@dhw68k.cts.com (David H. Wolfskill) (03/18/89)

[Referring to "Translation limits," section 2.2.4.1 of [p?]ANS C:]

In article <2314@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes:
>Does anyone have any intention of writing such a program?  Is anyone going
>to write the ANSI-C "exerciser" program?  Sounds like fun.

It is my understanding that a firm that was represented on X3J11 has a
validation suite available; I would expect just such a program to be a
part of that validation suite.

That, of course, ought not deter you from writing your own....  :-)

david
-- 
David H. Wolfskill
uucp: ...{spsd,zardoz,felix}!dhw68k!david	InterNet: david@dhw68k.cts.com

henry@utzoo.uucp (Henry Spencer) (03/19/89)

In article <225800141@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>... "at least one program" is a loophole larger than
>the hole in the Titanic. What if it indeed translated and executed
>one particular program by including the text of one specific
>program in itself, checking for that program, and then spitting out
>a hand coded compiled result? 

Does it matter?  Nobody would buy it after the word got around.

(Unless of course it was released by Berkeley with 4.22BSD or AT&T with
System V release 57, in which case thousands of people would buy it
automatically, and then complain about it being X3J11's fault.)
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

bitbug@vicom.COM (James Buster) (03/19/89)

I have a question on how the dpANS words its descriptions of limits.
Are they worded as:
	"The implementation shall accept *a maximum of*.."
or
	"The implementation shall accept *at least*..."

It seems to me that the second wording is far superior, in
that if I create an implementation that has no explicit limits other
than those imposed by available virtual memory (for example), I can still
be dpANS compliant, rather than be forced to saddle my implementation
with silly limits. Of course, if you write a program that exceeds
one of those limits, it is still non-portable, but my implementation
can still properly translate it. I would appreciate flames to the contrary :-)

--------------------------------------------
	     James Buster
	Mad Hacker Extraordinaire
    	...!ames!vsi1!bitbug
	   bitbug@vicom.com
--------------------------------------------

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/19/89)

In article <1574@vicom.COM> bitbug@vicom.COM (James Buster) writes:
>I have a question on how the dpANS words its descriptions of limits.

Rest assured that the pANS does not require that implementations
impose unnecessary fixed limits.  In fact a footnote advises to
the contrary.