!standard A.15(14) 18-02-26 AI12-0259-1/01
!standard A.15(16/3)
!class binding interpretation 18-02-26
!status work item 18-02-26
!status received 18-01-31
!priority Low
!difficulty Easy
!qualifier Omission
!subject Lower bound of strings returned in Ada.Command_Line
The strings returned by functions Argument and Command_Name from
Ada.Command_Line have lower bound 1.
!question
A.15(14) and A.15(16/3) say that the strings returned by functions Argument
and Command_Name from Ada.Command_Line have an implementation-defined
value. This does not preclude such strings from having any lower
bound, while the casual user would expect a lower bound of 1. Should
the lower bound be required to be 1? (Yes.)
!recommendation
(See Summary.)
!wording
Modify A.15(14):
If the external execution environment supports passing arguments to
a program, then Argument returns an implementation-defined value {with
lower bound 1} corresponding to the argument at relative position Number.
If Number is outside the range 1..Argument_Count, then Constraint_Error
is propagated.
Change A.15(16/3) as follows:
If the external execution environment supports passing arguments to
a program, then Command_Name returns an implementation-defined value {with
lower bound 1} corresponding to the name of the command invoking the
program; otherwise, Command_Name returns the null string.
!discussion
Most of the langauge-defined library functions that return Strings specify the
lower bound to be 1 - for instance, Ada.Exceptions.Exception_Message
(11.4.1(10.1/4)), all of the functions in Ada.Strings.Fixed (A.4.3(2)),
and the functions in Ada.Directories (A.16(50/2)). These functions should be
the same; it avoids unnecessary variation and thus a tripping hazard when
porting code. The implementation changes needed (if any) should be minimal.
!ASIS
No ASIS effect.
!ACATS test
!appendix
From: Jean-Pierre Rosen
Sent: Wednesday, January 31, 2018 5:07 AM
I just came across this. [This is version /01 of the AI - Editor.] Since it
is both easy and presumably will not impact implementations, it might be
useful to sneak it in...
TBH: There might be other places where it would be useful to specify the lower
bound of returned strings. Does the group think it would be worth chasing
them? I could do that.
****************************************************************
From: John Barnes
Sent: Wednesday, January 31, 2018 5:33 AM
sounds good.
****************************************************************
From: Tucker Taft
Sent: Wednesday, January 31, 2018 8:18 AM
Seems useful to have one less implementation dependency, by specifying lower
bounds of strings returned from language-defined packages.
****************************************************************
From: Randy Brukardt
Sent: Wednesday, January 31, 2018 5:42 PM
> I just came across this. Since it is both easy and presumably will not
> impact implementations, it might be useful to sneak it in...
We can treat this as a bug (it seems like that given the way we've treated
other functions historically, see below), and as such, no need to "sneak"
anything. We'll fix bugs right up to the deadline of the last meeting (June
2019).
As far as not impacting implementations -- if that was True, we wouldn't need
to change the Standard, right?
Here's the last line of Ada.Command_Line.Argument in Janus/Ada:
return Strip_Quotes(Command_Line(Last_Delim .. Last - 1));
where Strip_Quotes is a function that returns a string with the same 'First as
was passed in.
So there is at least one implementation that will need changes. (Not hard, but
not trivial either.)
There would be value to having an ACATS test to make sure this change is
implemented. The proposer of the AI would seem to be the stuckee for that.
:-) We didn't talk about it, but there ought to be an ACATS test for every
Binding Interpretation (read bug fix) which is potentially incompatible
(either at compile-time or runtime) -- which this is.
> TBH: There might be other places where it would be useful to specify
> the lower bound of returned strings. Does the group think it would be
> worth chasing them? I could do that.
I don't think it is worth the substantial time investment. We've fixed such
bugs several times in the past, see AI95-000378 and AI95-00417 for example.
There shouldn't be many such places remaining that aren't covered (and some
of those are covered by blanket rules like A.4.3(2)).
I'm a little surprised that you are bringing this up, since you are the guy
that said that "when writing in Ada, you have to be aware of bounds". It seems
that there is no problem writing code that doesn't trip over the bounds of
these arguments (every existing Janus/Ada program that uses Ada.Command_Line
demonstrates that), and since you seem to be against a bounds normalization
subtype, and that there isn't any sensible way to actually force the bounds of
a string to be one (any solution I know of requires making an extra copy of
the string), I detect something inconsistent here.
It would seem more important verifying that Suppress check names are properly
tied to checks, but no one volunteered for that.
And personally I'd rather you spent the time writing ACATS tests so the
coverage of Ada 2020 is not approximately 0%. :-)
P.S. I assume that you don't have any objection to my fixing the editorial/style
errors in the AI you presented.
****************************************************************
From: Jean-Pierre Rosen
Sent: Thursday, February 1, 2018 3:17 AM
> We can treat this as a bug (it seems like that given the way we've
> treated other functions historically, see below), and as such, no need to "sneak"
> anything. We'll fix bugs right up to the deadline of the last meeting
> (June 2019).
Note that I categorized it as "omission"...
> There would be value to having an ACATS test to make sure this change
> is implemented. The proposer of the AI would seem to be the stuckee for that.
> :-)
I heard you
> I'm a little surprised that you are bringing this up, since you are
> the guy that said that "when writing in Ada, you have to be aware of
> bounds". It seems that there is no problem writing code that doesn't
> trip over the bounds of these arguments (every existing Janus/Ada
> program that uses Ada.Command_Line demonstrates that), and since you
> seem to be against a bounds normalization subtype, and that there
> isn't any sensible way to actually force the bounds of a string to be
> one (any solution I know of requires making an extra copy of the
> string), I detect something inconsistent here.
Not at all. It is definitely more user friendly to have a lower bound of
1 when returning a string, that's part of the /specification/, and useful to
the caller.
I think we don't need a special gizmo just to help people who do not know how
to write a /body/ properly (without benefits from the caller POV).
> P.S. I assume that you don't have any objection to my fixing the
> editorial/style errors in the AI you presented.
Sure
****************************************************************