Version 1.1 of acs/ac-00245.txt

Unformatted version of acs/ac-00245.txt version 1.1
Other versions for file acs/ac-00245.txt

!standard 2.2(14)          13-01-31 AC95-00245/00
!class confirmation 13-01-31
!status received no action 13-01-31
!status received 13-01-28
!subject Line length and identifier length the same?
!summary
!appendix

From: Randy Brukardt
Sent: Monday, January 28, 2013  7:56 PM

A current discussion on comp.lang.ada is discussing the rather unimportant point
of implementation-defined maximum line lengths.

Someone made the point that the main reason for limiting line lengths is to put
a maximum size on identifiers. Someone else objected to that, saying that
2.2(14) says:

An implementation shall support lines of at least 200 characters in length, not
counting any characters used to signify the end of a line. An implementation
shall support lexical elements of at least 200 characters in length. The maximum
supported line length and lexical element length are implementation defined.

They read the last sentence as saying these are two different quantities.

Normally, I would think of this as a tempest in a teapot, but there is another
data point: the ACATS. The ACATS (inherited from the ACVC) has always had a
macro parameter of the maximum line length, and identifiers that are of that
same length. That is, the ACATS tests do not allow the maximum identifier length
to be shorter than the maximum line length.

No one has ever disputed this requirement (at least not since Ada 95 came out),
so I have to think the intent is that the third sentence of 2.2(14) is talking
about a single quantity. If it is talking about two quantities, the ACATS ought
to be repaired (although I'd probably put that on the to-do list to wait until
someone actually complained).

What do the rest of you think?

***************************************************************

From: Tucker Taft
Sent: Monday, January 28, 2013  8:43 PM

> No one has ever disputed this requirement (at least not since Ada 95
> came out), so I have to think the intent is that the third sentence of
> 2.2(14) is talking about a single quantity. If it is talking about two
> quantities, the ACATS ought to be repaired (although I'd probably put
> that on the to-do list to wait until someone actually complained).

I think the intent was that these two limits could be different, but no one has
objected to linking them in the ACATS, so there seems no reason to change
anything in this area at this point.

> What do the rest of you think?

No action. ;-)

***************************************************************

From: Randy Brukardt
Sent: Monday, January 28, 2013  9:11 PM

> > No one has ever disputed this requirement (at least not since Ada 95
> > came out), so I have to think the intent is that the third sentence
> > of
> > 2.2(14) is talking about a single quantity. If it is talking about
> > two quantities, the ACATS ought to be repaired (although I'd
> > probably put that on the to-do list to wait until someone actually complained).
>
> I think the intent was that these two limits could be different, but
> no one has objected to linking them in the ACATS, so there seems no
> reason to change anything in this area at this point.

It's interesting that Ada 9x 2.0 only talks about the line limit; the lexical
item limit didn't appear until version 4.0, and then the wording was changed
twice more after that. I vaguely remember someone complaining about this for Ada
83; I was hoping to find an Ada 83 AI on the topic but wasn't able to find one.

I did find the URG UI that the AARM note mentions, UI-0035. It sets the limit at
250 rather than 200, and the text seems to indicate that it is assuming that the
line length and identifier length are the same. The discussion section says:

	Clearly  we would  not accept  a  compiler
	whose maximum  line length  is 16,  even though such a
	compiler is in compliance with the RM (16 is chosen to
	be long  enough to  spell any  of the reserved words).
	What is  the minimum  acceptable maximum  line length?
	The suggested  choice of 250 seems reasonably safe. On
	the one hand it is unlikely that  any compiler
	will have  difficulty with this maximum. On the
	other hand, it seems  that  restricting  identifier
	lengths to  250 characters  in	portable  programs  is
	probably reasonable.  Note that  the  limitation  also
	applies to strings and other literals.
	A long line length could be required by some tools, such
	as one which inserts automatic qualification (without
	changing the layout). The limit has been made as long as
	seems reasonable without introducing additional overheads
	into a compilation system.

No clear answer, but obviously the importance level is about 0.2 on a scale of 0
to 10. :-)

***************************************************************

From: Robert Dewar
Sent: Monday, January 28, 2013  9:31 PM

> No one has ever disputed this requirement (at least not since Ada 95
> came out), so I have to think the intent is that the third sentence of
> 2.2(14) is talking about a single quantity. If it is talking about two
> quantities, the ACATS ought to be repaired (although I'd probably put
> that on the to-do list to wait until someone actually complained).
>
> What do the rest of you think?

Assume they are the same, why not?

***************************************************************

From: Robert Dewar
Sent: Monday, January 28, 2013  9:33 PM

Note that the ACATS has always implemented requirements that go beyond what the
RM says, so I think it is fine for the ACATS to regard these two quantities as
identical.

***************************************************************

From: Jean-Pierre Rosen
Sent: Tuesday, January 29, 2013  12:07 AM

> That is, the ACATS tests do not allow the maximum identifier length to
> be shorter than the maximum line length.
>
> No one has ever disputed this requirement (at least not since Ada 95
> came out), so I have to think the intent is that the third sentence of
> 2.2(14) is talking about a single quantity. If it is talking about two
> quantities, the ACATS ought to be repaired (although I'd probably put
> that on the to-do list to wait until someone actually complained).
>
> What do the rest of you think?

Clearly, the identifier length cannot be longer than the line length.
Ergo, if they differ, the identifier is shorter. I see no benefit for the user
in having shorter identifiers, and compiler writers never complained about that.
No need to change anything (except a note to make clear that they are the same).

***************************************************************

From: Bob Duff
Sent: Tuesday, January 29, 2013  10:05 AM

> A current discussion on comp.lang.ada is discussing the rather
> unimportant point of implementation-defined maximum line lengths.
>
> Someone made the point that the main reason for limiting line lengths
> is to put a maximum size on identifiers. Someone else objected to
> that, saying that 2.2(14) says:
>
> An implementation shall support lines of at least 200 characters in
> length, not counting any characters used to signify the end of a line.
> An implementation shall support lexical elements of at least 200
> characters in length. The maximum supported line length and lexical
> element length are implementation defined.
>
> They read the last sentence as saying these are two different quantities.

The wording is clear -- it does not tie the two limits together.
They just happen to both be 200.

What's more, I wrote those words, and the intent is that they not be tied
together.

> Normally, I would think of this as a tempest in a teapot, but there is
> another data point: the ACATS. The ACATS (inherited from the ACVC) has
> always had a macro parameter of the maximum line length, and
> identifiers that are of that same length. That is, the ACATS tests do
> not allow the maximum identifier length to be shorter than the maximum line length.

The ACATS is wrong.  There is no requirement that an implementation even HAVE a
limit on line length or identifier length, other than what is imposed by the
size of a disk or memory or whatever.

> No one has ever disputed this requirement (at least not since Ada 95
> came out), so I have to think the intent is that the third sentence of
> 2.2(14) is talking about a single quantity.

Huh?  Why would you use ACATS as an indication of the intent of the RM?
Neither Tucker nor I were studying the ACATS when writing the RM!

Those line-length limits in ACATS date back to Ada 83 days.
They have nothing to do with the intent of 2.2(14).

>...If it is talking about two quantities, the  ACATS ought to be
>repaired (although I'd probably put that on the to-do list  to wait
>until someone actually complained).
>
> What do the rest of you think?

I think you should not change the tests until somebody disputes it.
(I.e., likely never.)

I also think you should not use comp.lang.ada as a source of work items for the
ARG!  ;-)

***************************************************************

From: Bob Duff
Sent: Tuesday, January 29, 2013  10:23 AM

> Clearly, the identifier length cannot be longer than the line length.
> Ergo, if they differ, the identifier is shorter. I see no benefit for
> the user in having shorter identifiers, and compiler writers never
> complained about that. No need to change anything (except a note to
> make clear that they are the same).

No, please let's not even think about changing the RM here.
"I see no benefit" is not a good reason to add a NOTE, especially when that NOTE
would be wrong. It directly contradicts the wording, and the intent of the
wording.

If anything needs to be changed, it's the ACATS. I don't know what the official
policy is on that, but I'd think it should wait until somebody disputes the
test(s).

P.S. Reminiscence: The test in question (or one of them, if there's more than
one) is c23001a.  I remember that without looking it up! The reason I remember
is that it was called Duck Soup (meaning "easy") at Intermetrics. Duck Soup was
considered the easiest to pass, and so was the first to pass in the C-ADA
compiler.

Later, it was the first to pass on the 1750A compiler.
That compiler generated grossly inefficient code, compounded by the fact that it
was running on a simulator. I was working late one night, and around midnight, I
heard shouting from the 1750A team at the other end of the building. "Bob, come
quick!  We're passing Duck Soup!"  I ran across the building, and they pointed
me to a terminal:

==== C23001A PASSED =========

and we cheered as it printed more and more '=' characters, about one every 2
seconds.  We finally saw:

==== C23001A PASSED ========================================.=

and everybody quit cheering, because that last '=' is wrong; the correct output
is:

==== C23001A PASSED ========================================.

Off by one!

:-)

***************************************************************

From: Robert Dewar
Sent: Tuesday, January 29, 2013  10:31 AM

> If anything needs to be changed, it's the ACATS. I don't know what the
> official policy is on that, but I'd think it should wait until
> somebody disputes the test(s).

No one will!

***************************************************************

From: Dan Eilers
Sent: Tuesday, January 29, 2013  12:38 PM

> P.S. Reminiscence: The test in question (or one of them, if there's
> more than one) is c23001a.  I remember that without looking it up!

Actually, c23001a is even easier than you remember, and doesn't involve any long
lines or customization, at least not the latest version.

The tests that do involve customization for long lines are:

    c23003a.tst
    c23003b.tst
    c23003g.tst
    c23003i.tst
    c35502d.tst
    c35502f.tst


> Those line-length limits in ACATS date back to Ada 83 days.
> They have nothing to do with the intent of 2.2(14).

Agreed.  I think now that the language enforces a minimum identifier length of
200, there is no need to use macro substitution to customize the 6 tests listed
above.  Instead, they can simply verify that 200-character identifiers work
properly.

I think in general it would be a good idea to do away with the notion of C-tests
that require modification, because ACATS currently has a fatal problem with its
cost/benefit ratio.

***************************************************************

From: Bob Duff
Sent: Tuesday, January 29, 2013  12:49 PM

> Actually, c23001a is even easier than you remember, and doesn't
> involve any long lines or customization, at least not the latest version.

Ah, yes, Duck Soup is about case insensitivity, not identifier length, as I had
misremembered.

> Agreed.  I think now that the language enforces a minimum identifier
> length of 200, there is no need to use macro substitution to customize
> the 6 tests listed above.  Instead, they can simply verify that
> 200-character identifiers work properly.

That would indeed make more sense, but I'm not sure it's worth the trouble to
make changes, when vendors aren't disputing tests.

> I think in general it would be a good idea to do away with the notion
> of C-tests that require modification, because ACATS currently has a
> fatal problem with its cost/benefit ratio.

There are several places where the ACATS annoyingly make things hard without any
actual testing benefit.

But there are so many implementation defined things in Ada, I don't see how an
effective test suite could avoid that sort of modification.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, January 29, 2013  1:54 PM

...
> The tests that do involve customization for long lines are:
>
>     c23003a.tst
>     c23003b.tst
>     c23003g.tst
>     c23003i.tst
>     c35502d.tst
>     c35502f.tst

There are a bunch of B-Tests as well that depend on customization for long
lines:
B22001A  B22001B  B22001C  B22001D  B22001E  B22001F B22001G  B22001I  B22001J
B22001K  B22001L  B22001M  B22001N

These test that overly long lines are detected. The ACATS has always insisted
that there is a line limit, which is interesting (as there doesn't seem to be
any reason for such a requirement in reading either the Ada 83 or Ada 95 RMs).
Again, no one has complained on my watch -- quite possibly because it would take
more effort to complain than it does to implement a line length limit.

> > Those line-length limits in ACATS date back to Ada 83 days.
> > They have nothing to do with the intent of 2.2(14).
>
> Agreed.  I think now that the language enforces a minimum identifier
> length of 200, there is no need to use macro substitution to customize
> the 6 tests listed above.  Instead, they can simply verify that
> 200-character identifiers work properly.

The "modern" ACATS does not depend on macro customization at all (rather, it
depends on the customization of the ImpDef packages when necessary). Certainly
any new tests will avoid these macros.

> I think in general it would be a good idea to do away with the notion
> of C-tests that require modification, because ACATS currently has a
> fatal problem with its cost/benefit ratio.

The only thing less beneficial than having those tests is expending effort to
remove and replace them, especially in the absence of any submitted tests to
replace them. That won't do anything to improve the benefit part of the equation
and would have almost no effect on the cost, either. If we are going to work on
chapter 2 tests, some Unicode identifier tests would be much more valuable
(improving the denominator in the cost/benefit ratio).

***************************************************************

From: Dan Eilers
Sent: Tuesday, January 29, 2013  2:45 PM

> There are several places where the ACATS annoyingly make things hard
> without any actual testing benefit.
>
> But there are so many implementation defined things in Ada, I don't
> see how an effective test suite could avoid that sort of modification.

There are only 35 C-tests that require customization, including these 6, and I
think it would be straightforward to fix them all to be portable, even if some
required use of the impdef package.

As Randy notes, there are also some B tests that involve customization, but I'm
more concerned with getting the C tests to be trivial to compile/run/grade
without any unnecessary complications.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, January 29, 2013  3:54 PM

...
> > No one has ever disputed this requirement (at least not since Ada 95
> > came out), so I have to think the intent is that the third sentence
> > of
> > 2.2(14) is talking about a single quantity.
>
> Huh?  Why would you use ACATS as an indication of the intent of the RM?
> Neither Tucker nor I were studying the ACATS when writing the RM!

But you were not trying to change the language (if you were, you would have
documented that fact as "Wording Change" or "Extension" and there would have
been a discussion about it -- none of those things exist that I can find). And
it is clear that for Ada 83, the ACATS required a line length and identifier
length that is bounded and the same. As we all know, the ACATS defines Ada in a
practical sense; we tend to make the RM match the ACATS (especially in terms of
long-standing practice), not the other way around.

> Those line-length limits in ACATS date back to Ada 83 days.
> They have nothing to do with the intent of 2.2(14).

The only documented intent of 2.2(14) is a add a minimum limit to the line
length and identifier length. Any effect on *maximum* lengths seems to be
undocumented and unintended (or at least unreviewed, since it wasn't documented,
and nothing turned up in the archives on this topic).

My question was whether the RM should match what has been required (and
unchallenged) from the start of (Ada) time. Knowledgable people like myself and
Jean-Pierre thought that it WAS required by the RM; it was a surprise to see
that the Ada 9x team apparently changed the requirements on maximum line limits
without asking anybody.

...
> I also think you should not use comp.lang.ada as a source of work
> items for the ARG!  ;-)

Why not? The topics that come up there tend to have arisen in real use of the
language. Those seem like exactly the ones that the ARG ought to be working on
(as opposed to Adam-style wording issues or Bairdian corner cases!). This
particular issue doesn't really fall into that category, but it bothered me
because it is so far from the ACATS requirements (which everyone follows). I
thought that the RM should match the ACATS in this area, or the ACATS ought to
be scheduled to be repaired -- leaving them wildly different is a bad idea.

In any case, this isn't the most important issue, and I doubt any action will be
taken (certainly not in the absence of a dispute and submitted replacement
tests).

***************************************************************

From: Dan Eilers
Sent: Tuesday, January 29, 2013  4:15 PM

> In any case, this isn't the most important issue, and I doubt any
> action will be taken (certainly not in the absence of a dispute and
> submitted replacement tests).

I am happy to submit a formal dispute along with replacement tests if you think
that would make a difference.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, January 29, 2013  4:27 PM

Let's talk about that off-line, because it's somewhat off-topic here and it
takes time to file messages posted here.

***************************************************************

From: Bob Duff
Sent: Tuesday, January 29, 2013  4:48 PM

> ...
> > > No one has ever disputed this requirement (at least not since Ada
> > > 95 came out), so I have to think the intent is that the third
> > > sentence of
> > > 2.2(14) is talking about a single quantity.
> >
> > Huh?  Why would you use ACATS as an indication of the intent of the RM?
> > Neither Tucker nor I were studying the ACATS when writing the RM!
>
> But you were not trying to change the language (if you were, you would
> have documented that fact as "Wording Change" or "Extension" and there
> would have been a discussion about it -- none of those things exist that I can
> find).

Actually, I think we WERE changing the language.  I was opposed to the change,
by the way.  I wrote the words, but under duress, as it were. I was happy with
the Ada 83 wording, which doesn't mention any 200-char limits or whatever.  (It
has always been the case that you can't have a lexeme longer than a line, which
might be where some of the confusion comes from.)

I don't remember the rationale for the people pushing the 200-char thing.
Probably they wanted to squelch compilers that only supported short-ish lines.
I don't know if those compilers were real or imagined. There were operating
systems at the time that represented text as 80-column "card images" and such
foolishness.

> And it is clear that for Ada 83, the ACATS required a line length and
> identifier length that is bounded and the same.

That was always wrong.  In all versions of Ada, a compiler is allowed to support
1-billion-character lines, and an ACATS test of that is ludicrous.

Anyway, the days of compilers putting unreasonable limits on things are mostly
over, so tests to prevent that are not all that useful.

>...As we all know, the ACATS
> defines Ada in a practical sense; we tend to make the RM match the
> ACATS  (especially in terms of long-standing practice), not the other way
> around.

And we tend to make our compilers match the ACATS, too, because we're too lazy
to challenge wrong tests.

> > Those line-length limits in ACATS date back to Ada 83 days.
> > They have nothing to do with the intent of 2.2(14).
>
> The only documented intent of 2.2(14) is a add a minimum limit to the
> line length and identifier length. Any effect on *maximum* lengths
> seems to be undocumented and unintended (or at least unreviewed, since
> it wasn't documented, and nothing turned up in the archives on this topic).
>
> My question was whether the RM should match what has been required
> (and
> unchallenged) from the start of (Ada) time. Knowledgable people like
> myself and Jean-Pierre thought that it WAS required by the RM; it was
> a surprise to see that the Ada 9x team apparently changed the
> requirements on maximum line limits without asking anybody.

That's not true!  As I said, I was opposed to the change.
IIRC, the change was forced on me by some vote of the DR's.

I don't remember if Tucker was opposed to the change.
I do remember there was some heated debate, as there often is for issues that
are trivial enough that everybody can understand them.  ;-)

> ...
> > I also think you should not use comp.lang.ada as a source of work
> > items for the ARG!  ;-)
>
> Why not? The topics that come up there tend to have arisen in real use
> of the language. Those seem like exactly the ones that the ARG ought
> to be working on (as opposed to Adam-style wording issues or Bairdian
> corner cases!). This particular issue doesn't really fall into that
> category, but it bothered me because it is so far from the ACATS
> requirements (which everyone follows). I thought that the RM should
> match the ACATS in this area, or the ACATS ought to be scheduled to be
> repaired -- leaving them wildly different is a bad idea.

I'm strongly opposed to changing the RM here.  If you insist on changing
something, change the ACATS.

> In any case, this isn't the most important issue, and I doubt any
> action will be taken (certainly not in the absence of a dispute and
> submitted replacement tests).

I'm happy with "no action".  I see from another email that Dan has volunteered
to rewrite the tests (thanks, Dan!), and I'm happy with that, too.  I agree with
Dan's plan for rewriting (just make sure implementations support 200-char lines,
identifiers, string literals, etc).

***************************************************************

From: Bob Duff
Sent: Tuesday, January 29, 2013  5:04 PM

> Actually, I think we WERE changing the language.

Well, now wait a minute.  I might be misremembering.

I think it's debatable whether it was an actual language change.
We all know implementations can impose capacity limitations, and AI83-325 says
so.  But only if it's "impossible or impractical" to avoid the limitation.

So my thinking at the time might have been that an 80-char line limit is OK only
if you're on a broken operating system that imposes that limit.  If the user can
manage to create an Ada source file with 1000-char lines, the compiler ought to
handle it.  And if the RM says "at least 200" and the OS makes that impractical,
you can ignore the 200 requirement, too.  So it's not really changing anything.

Note that if I thought it was a wording change, I would probably not have
documented it.  The purpose of "Wording Change" was to document cases where
people might be outraged that the loose-cannon MRT was changing things -- we
were protecting ourselves against false accusations of gratuitous language
changes.  More recently, you have misunderstood the purpose of the "Wording
Change" sections, thinking that you're supposed to document all wording changes.
I hope you stop documenting ALL wording changes, because it adds a lot of noise.
Just document important ones, and ones where people might think it's a "real"
change.

>...  I was opposed to the
> change, by the way.

I was opposed to adding the wording, but I guess I thought it was innocuous
enough, and not worth documenting as a "Change".

***************************************************************

From: Robert Dewar
Sent: Tuesday, January 29, 2013  5:17 PM

I am shocked to be away from my computer for a few hours and come back to find a
dozen messages on this thread which I certainly do not intend to read.

Is this really the sort of thing the ARG feels it can spend time on? If so, it
must mean there is nothing worth while to discuss and we should suspend the
activitirs of the ARG.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, January 29, 2013  5:28 PM

...
> More recently, you have misunderstood the purpose of the "Wording
> Change" sections, thinking that you're supposed to document all
> wording changes.  I hope you stop documenting ALL wording changes,
> because it adds a lot of noise.  Just document important ones, and
> ones where people might think it's a "real" change.

I have to document all of the Binding Interpretations somewhere so that the AARM
has an indication of that status. That does lead to some pretty lame "Wording
Changes" notes. And of course, it's rare that an Amendment goes under Wording
Changes. But I have tried to avoid writing lame ones (subject to the above)
since you first complained. I have absolutely no interest (or money) to take out
the lame ones already written, of course, so I doubt that change it particularly
evident. (Besides, most of the recent BIs have potential incompatibilities with
"Standard Ada 2012", which have to be documented as such, although it is
unlikely that any will actually ever exist because the one current Ada 2012
implementation doesn't have the issue and it's unlikely that a new
implementation would ignore approved BIs.)

***************************************************************

From: Randy Brukardt
Sent: Tuesday, January 29, 2013  5:53 PM

> I am shocked to be away from my computer for a few hours and come back
> to find a dozen messages on this thread which I certainly do not
> intend to read.
>
> Is this really the sort of thing the ARG feels it can spend time on?
> If so, it must mean there is nothing worth while to discuss and we
> should suspend the activitirs of the ARG.

I don't think that anyone exactly decides what topics generate a lot of e-mail
messages; it just happens. I wouldn't have expected this topic to generate more
than a couple replies. When I post something important that needs discussion,
everybody ignores it (or so it seems). Ergo, I don't think e-mail traffic has
much to do with what the "ARG feels" about anything.

In any case, I don't see this topic ever making it onto a meeting agenda; I'm
sure we'll find more important things to work on.

***************************************************************

From: John Goodenough
Sent: Wednesday, January 29, 2013  8:57 PM

At the risk of adding to Robert's shock, I find at last a (trivial) issue on
which I can make a meaningful (historical) comment. :-) Although I no longer
have access to the ACVC Implementor's Guide, which explained the rationale for
tests, I'm pretty sure that my reasoning was something like the following:

*  Since the RM specifies no limit on identifier length, identifiers can be as
   long as physically possible, namely, the maximum line length that a compiler
   supports (assuming that "line length" is a meaningful concept for a
   particular compiler)

*  Given the lack of a limit on identifier length, the ACVC should check that
   implementers do not impose an unjustified constraint on identifier length, so
   the ACVC needed a check that the longest possible identifier is allowed

*  Hence the test that an identifier can be equal to the line length

*  An implementation could always argue that there was no limit on line length,
   in which case, the test could use some big value, just to test the (unlikely)
   situation that some constraint existed on identifier length, or one could
   argue that the test is bogus

Although the test was perhaps useful in a day when some compilers had limits on
identifier length, it certainly isn't very useful today I would think.

(No need to further clutter the list with a response to this note!)

John
(still reading the list!)

***************************************************************

From: Randy Brukardt
Sent: Thursday, January 31, 2013  12:40 AM

Well, I do still have the IG (it was too heavy to throw out ;-), and your
explanation here is much more enlightening than that in the IG. The IG just says
to check that identifiers can be as long as the maximum line input length, and
that all of the characters are significant. It also asks to check that lexical
elements can't be broken across maximum length lines. It doesn't explain how the
idea that the maximum identifier is the same length as the maximum line came to
be. Or why it essentially assumes that there is a practical maximum to a line
length.

The (trivial) problem is that nothing in the IG, nor in the ACVC, seems to
contemplate the notion that the maximum line length might be larger than any
practical identifier (or program). Any compiler that supports more than 8-bit
position numbers certainly supports enough for practical use; it would be silly
to test identifiers with 32767 and 32768 characters (if the line position was a
16-bit integer), and insane to test 2**32 character identifiers. And of course,
it doesn't contemplate 1.1.3(6) or the equivalent Ada 83 AI (I forget the
number).

This discussion seems to support the idea that most compiler vendors put a line
limit into their compiler mainly to pass the ACVC/ACATS tests, as that's a lot
easier than disputing them. Probably not the intent of the tests!

Anyway, thanks for the history lesson

***************************************************************

From: Robert Dewar
Sent: Thursday, January 31, 2013  9:15 AM

Well some benefit from this thread! John, really nice to hear from you, hope
everything is going well in Pittsburgh!

***************************************************************


Questions? Ask the ACAA Technical Agent