!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 ****************************************************************