* Weird string I/O problem @ 2008-11-26 5:52 Jerry 2008-11-26 7:24 ` christoph.grein ` (2 more replies) 0 siblings, 3 replies; 28+ messages in thread From: Jerry @ 2008-11-26 5:52 UTC (permalink / raw) The following program misbehaves if the line Get(A_Float); -- PROBLEMATIC LINE is present; the call to Get_Line is made but there is no opportunity for the user to enter a string--the program continues (I suppose) as though the user entered a line terminator, causing the following output: Enter a float: 12.3 Enter a string: Hello from Get_Line. Your string was It was 0 long. However, if the problematic line is commented out, the following occurs: Enter a float: Enter a string: Hello from Get_Line. bla bla Your string was bla bla It was 7 long. Here is the program: with Ada.Text_IO, Ada.Float_Text_IO, Ada.Strings.Unbounded; use Ada.Text_IO, Ada.Float_Text_IO, Ada.Strings.Unbounded; procedure temp1 is -- Crude Get_Line for unbounded strings. procedure Get_Line(An_Unbounded_String : out Unbounded_String) is Max_Length : Integer := 256; A_String : String(1 .. Max_Length); Length : Integer; begin Put_Line("Hello from Get_Line."); Get_Line(A_String, Length); An_Unbounded_String := To_Unbounded_String(A_String(1 .. Length)); end Get_Line; UBS : Unbounded_String; A_Float : Float; begin Put("Enter a float: "); Get(A_Float); -- PROBLEMATIC LINE Put("Enter a string: "); Get_Line(UBS); Put_Line("Your string was " & To_String(UBS)); Put_Line("It was" & Length(UBS)'img & " long."); end temp1; What is going on here? I am running GNAT 4.3 on OS X 10.4. Jerry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 5:52 Weird string I/O problem Jerry @ 2008-11-26 7:24 ` christoph.grein 2008-11-26 7:38 ` christoph.grein 2008-11-26 9:07 ` Jean-Pierre Rosen 2008-11-27 4:46 ` Jerry 2008-12-01 19:47 ` anon 2 siblings, 2 replies; 28+ messages in thread From: christoph.grein @ 2008-11-26 7:24 UTC (permalink / raw) > Put("Enter a float: "); > Get(A_Float); -- PROBLEMATIC LINE Here you enter "12.3<Return>" Get consumes the number and leaves <Return> in the input stream. > Put("Enter a string: "); > Get_Line(UBS); Here, Get_Line consumes the rest of the previous input up to the <Return>, in your case the rest is empty. (If you had entered 12.3 xxx<Return>, the contents of UBS would be " xxx".) So you have no opportunity to enter a further string. What you need, is a Skip_Line after the Get(A_Float). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 7:24 ` christoph.grein @ 2008-11-26 7:38 ` christoph.grein 2008-11-26 8:25 ` Dmitry A. Kazakov 2008-11-26 9:07 ` Jean-Pierre Rosen 1 sibling, 1 reply; 28+ messages in thread From: christoph.grein @ 2008-11-26 7:38 UTC (permalink / raw) I meant Here, Get_Line consumes the rest of the previous input up to and including the <Return>, in your case the rest is empty. (If you had entered 12.3 xxx<Return>, the contents of UBS would be " xxx".) ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 7:38 ` christoph.grein @ 2008-11-26 8:25 ` Dmitry A. Kazakov 0 siblings, 0 replies; 28+ messages in thread From: Dmitry A. Kazakov @ 2008-11-26 8:25 UTC (permalink / raw) On Tue, 25 Nov 2008 23:38:04 -0800 (PST), christoph.grein@eurocopter.com wrote: > I meant > Here, Get_Line consumes the rest of the previous input up to and > including the <Return>, in your case the rest is empty. > (If you had entered 12.3 xxx<Return>, the contents of UBS would be > " xxx".) And a little advise for text processing: 1. Never read data items directly from files. Do lines first, as strings. Then parse obtained strings. 2. Take care to remove trailing LF and CR at the line end. (You never know if the text file do obey UNIX or MS-DOS conventions.) 3. Always verify that the whole line was parsed. 4. Do not use Unbounded_String, it is just an unnecessary overhead. Ada 2005 has Get_Line returning String. (In high-integrity software use Ada 95's Get_Line, that with the line size limited). -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 7:24 ` christoph.grein 2008-11-26 7:38 ` christoph.grein @ 2008-11-26 9:07 ` Jean-Pierre Rosen 2008-11-26 15:21 ` John McCormick 2008-11-26 15:56 ` Adam Beneschan 1 sibling, 2 replies; 28+ messages in thread From: Jean-Pierre Rosen @ 2008-11-26 9:07 UTC (permalink / raw) christoph.grein@eurocopter.com a �crit : > What you need, is a Skip_Line after the Get(A_Float). If you want to make sure you read something from a fresh new line, you can use set_col(1). It has the nice property that if the previous get consumed the end_of_line, it does nothing, and if it didn't, it skips everything up to and including the end_of_line. -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 9:07 ` Jean-Pierre Rosen @ 2008-11-26 15:21 ` John McCormick 2008-11-26 15:56 ` Adam Beneschan 1 sibling, 0 replies; 28+ messages in thread From: John McCormick @ 2008-11-26 15:21 UTC (permalink / raw) Good advice from Dmitry. A nifty solution from Jean-Pierre! A shameless plug from me: For a lengthy elementary discussion on the input of mixed types check out Chapter 3 of Programming and Problem Solving with Ada by Dale, Weems, and McCormick. John On Nov 26, 3:07 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote: > christoph.gr...@eurocopter.com a écrit :> What you need, is a Skip_Line after the Get(A_Float). > > If you want to make sure you read something from a fresh new line, you > can use set_col(1). > > It has the nice property that if the previous get consumed the > end_of_line, it does nothing, and if it didn't, it skips everything up > to and including the end_of_line. > > -- > --------------------------------------------------------- > J-P. Rosen (ro...@adalog.fr) > Visit Adalog's web site athttp://www.adalog.fr ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 9:07 ` Jean-Pierre Rosen 2008-11-26 15:21 ` John McCormick @ 2008-11-26 15:56 ` Adam Beneschan 2008-11-27 10:13 ` Jean-Pierre Rosen 1 sibling, 1 reply; 28+ messages in thread From: Adam Beneschan @ 2008-11-26 15:56 UTC (permalink / raw) On Nov 26, 1:07 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote: > christoph.gr...@eurocopter.com a écrit :> What you need, is a Skip_Line after the Get(A_Float). > > If you want to make sure you read something from a fresh new line, you > can use set_col(1). Set_Col(1) will use the current output file by default, so I don't think it has any effect on input. Set_Col (Current_Input, 1) is what I think you want. -- Adam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 15:56 ` Adam Beneschan @ 2008-11-27 10:13 ` Jean-Pierre Rosen 2008-12-01 16:17 ` Adam Beneschan 0 siblings, 1 reply; 28+ messages in thread From: Jean-Pierre Rosen @ 2008-11-27 10:13 UTC (permalink / raw) Adam Beneschan a �crit : > Set_Col(1) will use the current output file by default, so I don't > think it has any effect on input. Set_Col (Current_Input, 1) is what > I think you want. > Sure. Just a shorthand for "calling Set_Col (on the appropriate file) with a value of 1". -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-27 10:13 ` Jean-Pierre Rosen @ 2008-12-01 16:17 ` Adam Beneschan 0 siblings, 0 replies; 28+ messages in thread From: Adam Beneschan @ 2008-12-01 16:17 UTC (permalink / raw) On Nov 27, 2:13 am, Jean-Pierre Rosen <ro...@adalog.fr> wrote: > Adam Beneschan a écrit :> Set_Col(1) will use the current output file by default, so I don't > > think it has any effect on input. Set_Col (Current_Input, 1) is what > > I think you want. > > Sure. Just a shorthand for "calling Set_Col (on the appropriate file) > with a value of 1". I'd strongly recommend avoiding this particular kind of shorthand. Since Set_Col(1) will actually compile in Ada due to overloading, but won't do what you want, it could very easily be confusing. If you want shorthand, try an ellipsis [e.g. Set_Col(..., 1);] because at least that couldn't be confused with something you could actually write in your program. Just my 0.01576 euros... -- Adam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 5:52 Weird string I/O problem Jerry 2008-11-26 7:24 ` christoph.grein @ 2008-11-27 4:46 ` Jerry 2008-11-27 10:27 ` Jean-Pierre Rosen 2008-12-01 19:47 ` anon 2 siblings, 1 reply; 28+ messages in thread From: Jerry @ 2008-11-27 4:46 UTC (permalink / raw) On Nov 25, 10:52 pm, Jerry <lancebo...@qwest.net> wrote: > The following program misbehaves if the line ... > Jerry Thanks for all the help, everyone. Making Skip_Line or Set_Col(Current_Input, 1) the first line of my Get_Line works--Set_Col looks a little more general, so I'll use it. I now see that Ada 2005 has a Get_Line returning Unbounded_String: http://www.adaic.org/standards/05rat/html/Rat-7-5.html However, it does not solve my problem because it, too, reads the "dangling" line terminator which is left over from the Get on a Float. And--I can't do anything about it (such as adding Set_Col) unless of course I want to edit the source and thus subvert the intentions of the smart people who figured all of this out. So my problem is solved, but I'm still puzzled. All I'm trying to is to very simple IO from keyboard and monitor to enter e.g. a numeric parameter into my program as well as, say, a file name. So any Get on a Float followed by any of the Get_Line routines will raise this problem. It just seems odd to me that for such a simple application, I have to remember to clear the dangling line terminator after the Get on a Float. (Or, in the present case, since I have easy access to the code, to have the Get_Line do it for me.) Thanks, Jerry ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-27 4:46 ` Jerry @ 2008-11-27 10:27 ` Jean-Pierre Rosen 0 siblings, 0 replies; 28+ messages in thread From: Jean-Pierre Rosen @ 2008-11-27 10:27 UTC (permalink / raw) Jerry a �crit : > So my problem is solved, but I'm still puzzled. All I'm trying to is > to very simple IO from keyboard and monitor to enter e.g. a numeric > parameter into my program as well as, say, a file name. So any Get on > a Float followed by any of the Get_Line routines will raise this > problem. It just seems odd to me that for such a simple application, I > have to remember to clear the dangling line terminator after the Get > on a Float. (Or, in the present case, since I have easy access to the > code, to have the Get_Line do it for me.) > The real issue is that you never know what the user will type! Suppose you want to get a real value, and the user types: 3.14 Ooops one of my keys got stuck ------------------------------- What should you do? Clearly, the language has no opinion about this, it is just designed in a way that allows /you/ to implement anything you want. For example: 1) Ignore everything until EoL => call skip_line 2) Make it an error => write a message if End_Of_Line is false after reading. 3) Allow only spaces after the number => Read the remaining of the line with Get_Line, and do your own analysis 4) Consider that it is text for the next get of string, unless there is no remaining text on the same line => if end_of_line then skip_line etc... -- --------------------------------------------------------- J-P. Rosen (rosen@adalog.fr) Visit Adalog's web site at http://www.adalog.fr ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-11-26 5:52 Weird string I/O problem Jerry 2008-11-26 7:24 ` christoph.grein 2008-11-27 4:46 ` Jerry @ 2008-12-01 19:47 ` anon 2008-12-02 5:44 ` christoph.grein 2 siblings, 1 reply; 28+ messages in thread From: anon @ 2008-12-01 19:47 UTC (permalink / raw) -- -- Build your own input routine. Example: -- with Ada.Characters.Latin_1 ; -- Needed for control chars. use Ada.Characters.Latin_1 ; -- ... char : character ; input_string : String ( 1..80 ) ; last : natural ; -- ... input_string := ( others => nul ) ; for index in input_string'Range loop Get ( char ) ; exit when char = CR or char = LF ; input_string ( index ) := char ; Last := Index ; end loop -- valid data is input_string ( 1 .. last ) ; with no term control characters -- ... In <c6f5748b-923f-4077-b33e-a5017309ac46@w39g2000prb.googlegroups.com>, Jerry <lanceboyle@qwest.net> writes: >The following program misbehaves if the line > > Get(A_Float); -- PROBLEMATIC LINE > >is present; the call to Get_Line is made but there is no opportunity >for the user to enter a string--the program continues (I suppose) as >though the user entered a line terminator, causing the following >output: > > Enter a float: 12.3 > Enter a string: Hello from Get_Line. > Your string was > It was 0 long. > >However, if the problematic line is commented out, the following >occurs: > > Enter a float: Enter a string: Hello from Get_Line. > bla bla > Your string was bla bla > It was 7 long. > >Here is the program: > > > >with > Ada.Text_IO, > Ada.Float_Text_IO, > Ada.Strings.Unbounded; >use > Ada.Text_IO, > Ada.Float_Text_IO, > Ada.Strings.Unbounded; > >procedure temp1 is > > -- Crude Get_Line for unbounded strings. > procedure Get_Line(An_Unbounded_String : out Unbounded_String) is > Max_Length : Integer := 256; > A_String : String(1 .. Max_Length); > Length : Integer; > begin > Put_Line("Hello from Get_Line."); > Get_Line(A_String, Length); > An_Unbounded_String := To_Unbounded_String(A_String(1 .. >Length)); > end Get_Line; > > UBS : Unbounded_String; > A_Float : Float; > >begin > Put("Enter a float: "); > Get(A_Float); -- PROBLEMATIC LINE > Put("Enter a string: "); > Get_Line(UBS); > Put_Line("Your string was " & To_String(UBS)); > Put_Line("It was" & Length(UBS)'img & " long."); >end temp1; > > >What is going on here? I am running GNAT 4.3 on OS X 10.4. > >Jerry > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-01 19:47 ` anon @ 2008-12-02 5:44 ` christoph.grein 2008-12-02 6:55 ` anon 0 siblings, 1 reply; 28+ messages in thread From: christoph.grein @ 2008-12-02 5:44 UTC (permalink / raw) On 1 Dez., 20:47, a...@anon.org (anon) wrote: > -- > -- Build your own input routine. Example: > -- > with Ada.Characters.Latin_1 ; -- Needed for control chars. > use Ada.Characters.Latin_1 ; > > -- ... > char : character ; > input_string : String ( 1..80 ) ; > last : natural ; > > -- ... > > input_string := ( others => nul ) ; > for index in input_string'Range loop > Get ( char ) ; > exit when char = CR or char = LF ; Does anon ever read the RM? See A.10.7(1..3): After skipping any line terminators and any page terminators, reads the next character from the specified input file and returns the value of this character in the out parameter Item. Also A.9(8): Effect of input (Get) ... of control characters ... is not specified. This tries to do what Get_Line is for - and is wrong! > input_string ( index ) := char ; > Last := Index ; > end loop > > -- valid data is input_string ( 1 .. last ) ; with no term control characters > > -- ... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-02 5:44 ` christoph.grein @ 2008-12-02 6:55 ` anon 2008-12-02 7:53 ` christoph.grein 0 siblings, 1 reply; 28+ messages in thread From: anon @ 2008-12-02 6:55 UTC (permalink / raw) Have you ever learn, you do not give the complete code, because too many students like to steal code for there grade. So, you ONLY give enough code for the person to use the code to build his own. And that's what i did! And what of your answer! In <6d9d4120-3af9-42c6-b3e9-768418948084@t3g2000yqa.googlegroups.com>, christoph.grein@eurocopter.com writes: >On 1 Dez., 20:47, a...@anon.org (anon) wrote: >> -- >> -- Build your own input routine. =A0Example: >> -- >> with Ada.Characters.Latin_1 ; -- Needed for control chars. >> use Ada.Characters.Latin_1 ; >> >> -- ... >> =A0 char : character ; >> =A0 input_string : String ( 1..80 ) ; >> =A0 last : natural ; >> >> -- ... >> >> input_string :=3D ( others =3D> nul ) ; >> for index in input_string'Range loop >> =A0 Get ( char ) ; >> =A0 exit when char =3D CR or char =3D LF ; > >Does anon ever read the RM? See A.10.7(1..3): >After skipping any line terminators and any page terminators, reads >the next character from the >specified input file and returns the value of this character in the >out parameter Item. > >Also A.9(8): Effect of input (Get) ... of control characters ... is >not specified. > >This tries to do what Get_Line is for - and is wrong! > >> =A0 input_string ( index ) :=3D char ; >> =A0 Last :=3D Index ; =A0 >> end loop >> >> =A0 -- valid data is input_string ( 1 .. last ) ; with no term control ch= >aracters >> >> -- ... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-02 6:55 ` anon @ 2008-12-02 7:53 ` christoph.grein 2008-12-02 16:39 ` Adam Beneschan 0 siblings, 1 reply; 28+ messages in thread From: christoph.grein @ 2008-12-02 7:53 UTC (permalink / raw) On 2 Dez., 07:55, a...@anon.org (anon) wrote: > Have you ever learn, you do not give the complete code, because too many > students like to steal code for there grade. > > So, you ONLY give enough code for the person to use the code to > build his own. And that's what i did! anon pretending educational intentions presents wrong code. What a nice fellow! for index in input_string'Range loop ... Here get the next char from the input stream. ... Be careful, there might be control characters. ... See Ada.Text_IO for appropriate subprograms. exit when char = CR or char = LF ; -- not all OSes treat end of lines like this this is why there are End_of_Line queries input_string ( index ) := char ; Last := Index ; end loop; This would be the way, I guess. To quote from Porgy and Bess: anon is a sometime thing. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-02 7:53 ` christoph.grein @ 2008-12-02 16:39 ` Adam Beneschan 2008-12-03 9:16 ` anon 0 siblings, 1 reply; 28+ messages in thread From: Adam Beneschan @ 2008-12-02 16:39 UTC (permalink / raw) On Dec 1, 11:53 pm, christoph.gr...@eurocopter.com wrote: > On 2 Dez., 07:55, a...@anon.org (anon) wrote: > > > Have you ever learn, you do not give the complete code, because too many > > students like to steal code for there grade. > > > So, you ONLY give enough code for the person to use the code to > > build his own. And that's what i did! > > anon pretending educational intentions presents wrong code. What a > nice fellow! > > for index in input_string'Range loop > ... Here get the next char from the input stream. > ... Be careful, there might be control characters. > ... See Ada.Text_IO for appropriate subprograms. > exit when char = CR or char = LF ; -- not all OSes treat end of > lines like this > this is why there are > End_of_Line queries > input_string ( index ) := char ; > Last := Index ; > end loop; > > This would be the way, I guess. Also make sure it works when the user enters an empty string. Aside from the error of trying to test characters for CR and LF, and the issue that it wouldn't even work on an OS that returns *both* CR and LF in sequence, when the above code is executed multiple times to input multiple lines, there's a nasty bug (in anon's original code) that will show up when the input is an empty string. In other words, even from an educational standpoint, the original code seems more useful as a "Can you spot all the errors in this?" exercise than as something to help a student get started building his or her own. (And yes, I did catch the missing semicolon after "end loop".) Kind of reminds me of an old MAD Magazine puzzle where they showed you a picture that had everything possible wrong with it (including an upside-down sign that said MAD IS NOT FUNNY), and asked "What's wrong with this picture"? On the answer page, it simply said "Better you should ask, what's RIGHT with this picture"? -- Adam ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-02 16:39 ` Adam Beneschan @ 2008-12-03 9:16 ` anon 2008-12-03 10:42 ` christoph.grein 2008-12-03 11:35 ` stefan-lucks 0 siblings, 2 replies; 28+ messages in thread From: anon @ 2008-12-03 9:16 UTC (permalink / raw) -- Adam. -- -- The reason I used the "exit when char = CR or char = LF ;" -- statement was to allow the program to work in both Linux and -- Windows environment without modification. -- Also, A.10 (8). states the creator of this implementation -- can define the terminators or EOL. So, I just used the OS -- defined in two standard OS. -- And the reason I forgot the ";", well it was a typo. And those who -- says they do not make typos is a person that is not trust worthy! -- -- For christoph.grein -- Better re-read RM A.10.7. It does not say what you think it does. -- -- Now A.9(8) should be A.10.8. And it says that it is up to the -- author's implementation to define the terminators. Normally -- that is defined by the OS and hardware, but it can be redefined -- by the author code. -- -- Full Working Example: -- -- This version contains the orginal core code that I posted with some -- extra code on the outside of the core, plus some extra comments. -- -- -- Build your own input routine. Example: -- with Ada.Characters.Latin_1 ; -- Needed for control chars. use Ada.Characters.Latin_1 ; with Ada.Text_IO ; use Ada.Text_IO ; procedure t is -- -- Is control character codes in a String illegal or is it legal? That -- is up to the user of this routine. But the code is easy to adapt to -- the users needs. -- -- This routine does not handle other control codes except EOL which -- is defined by either LF or CR/LF. This allows one to insert the -- BEL control character into the inputed string, then later it can be -- printed or removed by other routines. -- Exceptions: 1. Control C is handled by OS. -- 2. Some characters like BS (8) may be stored in the -- string while others characters like TAB (9) may -- be expanded, depending on OS or BIOS. -- -- Returns String: On EOL or -- the number of non-expanded keystokes > 79 -- function Get ( P : String ) return String is char : character ; input_string : String ( 1..80 ) ; last : natural ; procedure Get ( C : out character ) is begin loop Get_Immediate ( C ) ; exit when C /= NUL ; end loop ; Put ( C ) ; end Get ; begin Put ( P ) ; input_string := ( others => nul ) ; for index in input_string'Range loop -- limits data size Get ( char ) ; -- Traps both LF or CR/LF type of EOL exit when char = CR or char = LF ; input_string ( index ) := char ; Last := Index ; end loop ; if char = CR then -- for CR/LF pairing type of OSs Get ( char ) ; end if ; if char = LF or Last = input_string'Last then -- process EOL on screen New_Line ; end if ; -- valid data is input_string ( 1 .. last ) ; -- with no term control characters like LF or CR return ( input_string ( 1 .. last ) ) ; end get ; begin Put_Line ( Get ( ">> " ) ) ; end t ; In <184a2bfd-4d95-434b-91e0-64c8f869e8b7@r15g2000prh.googlegroups.com>, Adam Beneschan <adam@irvine.com> writes: >On Dec 1, 11:53 pm, christoph.gr...@eurocopter.com wrote: >> On 2 Dez., 07:55, a...@anon.org (anon) wrote: >> >> > Have you ever learn, you do not give the complete code, because too many >> > students like to steal code for there grade. >> >> > So, you ONLY give enough code for the person to use the code to >> > build his own. And that's what i did! >> >> anon pretending educational intentions presents wrong code. What a >> nice fellow! >> >> for index in input_string'Range loop >> ... Here get the next char from the input stream. >> ... Be careful, there might be control characters. >> ... See Ada.Text_IO for appropriate subprograms. >> exit when char = CR or char = LF ; -- not all OSes treat end of >> lines like this >> this is why there are >> End_of_Line queries >> input_string ( index ) := char ; >> Last := Index ; >> end loop; >> >> This would be the way, I guess. > >Also make sure it works when the user enters an empty string. Aside >from the error of trying to test characters for CR and LF, and the >issue that it wouldn't even work on an OS that returns *both* CR and >LF in sequence, when the above code is executed multiple times to >input multiple lines, there's a nasty bug (in anon's original code) >that will show up when the input is an empty string. > >In other words, even from an educational standpoint, the original code >seems more useful as a "Can you spot all the errors in this?" exercise >than as something to help a student get started building his or her >own. (And yes, I did catch the missing semicolon after "end loop".) >Kind of reminds me of an old MAD Magazine puzzle where they showed you >a picture that had everything possible wrong with it (including an >upside-down sign that said MAD IS NOT FUNNY), and asked "What's wrong >with this picture"? On the answer page, it simply said "Better you >should ask, what's RIGHT with this picture"? > > -- Adam > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-03 9:16 ` anon @ 2008-12-03 10:42 ` christoph.grein 2008-12-03 12:21 ` John B. Matthews 2008-12-04 0:15 ` anon 2008-12-03 11:35 ` stefan-lucks 1 sibling, 2 replies; 28+ messages in thread From: christoph.grein @ 2008-12-03 10:42 UTC (permalink / raw) On Dec 3, 10:16 am, a...@anon.org (anon) wrote: > -- For christoph.grein > -- Better re-read RM A.10.7. It does not say what you think it does. ??? Hu. I quoted paras (1..3). So what do you think they say? > -- Now A.9(8) should be A.10.8. And it says that it is up to the Hehe ;-) We're all fond of typos. The correct quote here is A.10(8). > -- author's implementation to define the terminators. Normally > -- that is defined by the OS and hardware, but it can be redefined > -- by the author code. What do you mean with "author"? Who is the author here, the implementor (the programmer definitely cannot redefine them)? Of course terminators are implementation defined. This is why there are End_of_Line and End_of_Page queries. So if you want to write portable code, use those, not CR/LF etc. This will simplify the code. BTW: Doesn't Mac use only CR for End_of_Line? Then anon's code will fail again. anon: I didn't doubt that you are able to write working code. But what do you want to demonstrate with this example? It simply does what Get_Line does, so what is the advantage of your code? OK, it keeps all control characters (except CR and LF and NUL) that might be present in the input, but ruins the line and page counts that Text_IO maintains. So what? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-03 10:42 ` christoph.grein @ 2008-12-03 12:21 ` John B. Matthews 2008-12-04 0:15 ` anon 1 sibling, 0 replies; 28+ messages in thread From: John B. Matthews @ 2008-12-03 12:21 UTC (permalink / raw) In article <d74c1eb0-676f-43c5-85f4-de82b4c9e581@w35g2000yqm.googlegroups.com>, christoph.grein@eurocopter.com wrote: [...] > BTW: Doesn't Mac use only CR for End_of_Line? [...] Mac OS X, version 10.0 and later, uses LF; prior versions used CR: <http://en.wikipedia.org/wiki/End-of-line> It's always amusing (or annoying) to inadvertently cat an old source file and watch it flicker by on a single line. -- John B. Matthews trashgod at gmail dot com http://home.roadrunner.com/~jbmatthews/ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-03 10:42 ` christoph.grein 2008-12-03 12:21 ` John B. Matthews @ 2008-12-04 0:15 ` anon 2008-12-04 7:31 ` christoph.grein 1 sibling, 1 reply; 28+ messages in thread From: anon @ 2008-12-04 0:15 UTC (permalink / raw) It answers the original poster, That is if one find something they do not like in Ada or the RM either work around it or write your own routine. But stop complaining about it! And I did not say MAC. I say OSs that use LF or CR/LF pairing. As for you! You need to learn English. And there are many different ways someone can say the same thing. Just like in programming, there is no single way to perform a routine. Some may like the RTL of Ada to do the validation, while others prefer the concept of Ravenscar or no RTL. In <d74c1eb0-676f-43c5-85f4-de82b4c9e581@w35g2000yqm.googlegroups.com>, christoph.grein@eurocopter.com writes: >On Dec 3, 10:16=A0am, a...@anon.org (anon) wrote: >> -- For christoph.grein >> -- =A0 =A0Better re-read RM A.10.7. It does not say what you think it doe= >s. > >??? Hu. I quoted paras (1..3). So what do you think they say? > >> -- =A0 =A0Now A.9(8) should be A.10.8. =A0And it says that it is up to th= >e > >Hehe ;-) We're all fond of typos. The correct quote here is A.10(8). > >> -- =A0 =A0author's implementation to define the terminators. Normally >> -- =A0 =A0that is defined by the OS and hardware, but it can be redefined >> -- =A0 =A0by the author code. > >What do you mean with "author"? Who is the author here, the >implementor (the programmer definitely cannot redefine them)? Of >course terminators are implementation defined. This is why there are >End_of_Line and End_of_Page queries. So if you want to write portable >code, use those, not CR/LF etc. This will simplify the code. > >BTW: Doesn't Mac use only CR for End_of_Line? Then anon's code will >fail again. > >anon: I didn't doubt that you are able to write working code. But what >do you want to demonstrate with this example? It simply does what >Get_Line does, so what is the advantage of your code? OK, it keeps all >control characters (except CR and LF and NUL) that might be present in >the input, but ruins the line and page counts that Text_IO maintains. >So what? ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 0:15 ` anon @ 2008-12-04 7:31 ` christoph.grein 2008-12-04 7:56 ` Ludovic Brenta 0 siblings, 1 reply; 28+ messages in thread From: christoph.grein @ 2008-12-04 7:31 UTC (permalink / raw) On Dec 4, 1:15 am, a...@anon.org (anon) wrote: > As for you! You need to learn English. I'm apt to laugh. anon with his botchy grammer tells me to learn English :-) :-) A nice attitude: If someone finds a bug, omission, wrong RM interpretation, etc in his lengthy and often gratuitous code samples, it's just because "You do not give the complete code." ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 7:31 ` christoph.grein @ 2008-12-04 7:56 ` Ludovic Brenta 2008-12-04 8:46 ` Georg Bauhaus 0 siblings, 1 reply; 28+ messages in thread From: Ludovic Brenta @ 2008-12-04 7:56 UTC (permalink / raw) On Dec 4, 8:31 am, christoph.gr...@eurocopter.com wrote: > A nice attitude: If someone finds a bug, omission, wrong RM > interpretation, etc in his lengthy and often gratuitous code samples, > it's just because "You do not give the complete code." Or maybe because anon's code has been reviewed and used by so many people there can't be any bugs left in it :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 7:56 ` Ludovic Brenta @ 2008-12-04 8:46 ` Georg Bauhaus 0 siblings, 0 replies; 28+ messages in thread From: Georg Bauhaus @ 2008-12-04 8:46 UTC (permalink / raw) Ludovic Brenta wrote: > On Dec 4, 8:31 am, christoph.gr...@eurocopter.com wrote: >> A nice attitude: If someone finds a bug, omission, wrong RM >> interpretation, etc in his lengthy and often gratuitous code samples, >> it's just because "You do not give the complete code." > > Or maybe because anon's code has been reviewed and used by so many > people there can't be any bugs left in it :) Loophole rhetorics employed to maintain face? To be honest, who is not guilty of it? Hopefully, we can tag these discussions by using email addresses like anon-2@anon-2.org (or, talking@parrot.org if someone has the guts to do that) when answering. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-03 9:16 ` anon 2008-12-03 10:42 ` christoph.grein @ 2008-12-03 11:35 ` stefan-lucks 2008-12-04 0:27 ` anon 1 sibling, 1 reply; 28+ messages in thread From: stefan-lucks @ 2008-12-03 11:35 UTC (permalink / raw) On Wed, 3 Dec 2008, anon wrote: > -- Build your own input routine. Example: [...] if the variable Last is not initialised to 0 *before* you enter the loop ... > begin > Put ( P ) ; > input_string := ( others => nul ) ; > for index in input_string'Range loop -- limits data size > Get ( char ) ; > -- Traps both LF or CR/LF type of EOL > exit when char = CR or char = LF ; ... and if the user immediately presses the return key (i.e., if you read an empty line), ... > input_string ( index ) := char ; > Last := Index ; > end loop ; > if char = CR then -- for CR/LF pairing type of OSs > Get ( char ) ; > end if ; > if char = LF or Last = input_string'Last then -- process EOL on screen > New_Line ; > end if ; > -- valid data is input_string ( 1 .. last ) ; > -- with no term control characters like LF or CR ... then Input_String ( 1.. Last ) depends on the uninitialised variable Last ... > return ( input_string ( 1 .. last ) ) ; ... and the statement above may raise an exception. > end get ; -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-03 11:35 ` stefan-lucks @ 2008-12-04 0:27 ` anon 2008-12-04 8:58 ` stefan-lucks 0 siblings, 1 reply; 28+ messages in thread From: anon @ 2008-12-04 0:27 UTC (permalink / raw) Did I use the "pragma Initialize_Scalars ;" in GNAT.ADC or the command-line option version of that pragma or did I, as I have said "You do not give the complete code." That's something for you to think about! In <Pine.LNX.4.64.0812031226320.14772@medsec1.medien.uni-weimar.de>, stefan-lucks@see-the.signature writes: >On Wed, 3 Dec 2008, anon wrote: >> -- Build your own input routine. Example: >[...] > >if the variable Last is not initialised to 0 > *before* you enter the loop ... > >> begin >> Put ( P ) ; >> input_string := ( others => nul ) ; >> for index in input_string'Range loop -- limits data size >> Get ( char ) ; >> -- Traps both LF or CR/LF type of EOL >> exit when char = CR or char = LF ; > >.... and if the user immediately presses the return key > (i.e., if you read an empty line), ... > >> input_string ( index ) := char ; >> Last := Index ; >> end loop ; >> if char = CR then -- for CR/LF pairing type of OSs >> Get ( char ) ; >> end if ; >> if char = LF or Last = input_string'Last then -- process EOL on screen >> New_Line ; >> end if ; >> -- valid data is input_string ( 1 .. last ) ; >> -- with no term control characters like LF or CR > >.... then Input_String ( 1.. Last ) depends on > the uninitialised variable Last ... > >> return ( input_string ( 1 .. last ) ) ; > >.... and the statement above may raise an exception. > >> end get ; > >-- >------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ > Stefan dot Lucks at uni minus weimar dot de >------ I love the taste of Cryptanalysis in the morning! ------ > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 0:27 ` anon @ 2008-12-04 8:58 ` stefan-lucks 2008-12-04 22:54 ` anon 0 siblings, 1 reply; 28+ messages in thread From: stefan-lucks @ 2008-12-04 8:58 UTC (permalink / raw) On Thu, 4 Dec 2008, anon wrote: > Did I use the "pragma Initialize_Scalars ;" in GNAT.ADC or the command-line > option version of that pragma or did I, as I have said "You do not give the > complete code." > > That's something for you to think about! Well, in the message I replied to, you explicitely called your code a "Full Working Example". I apologise for taking our postings seriously! > > In <Pine.LNX.4.64.0812031226320.14772@medsec1.medien.uni-weimar.de>, stefan-lucks@see-the.signature writes: > >On Wed, 3 Dec 2008, anon wrote: > >> -- Build your own input routine. Example: > >[...] > > > >if the variable Last is not initialised to 0 > > *before* you enter the loop ... > > > >> begin > >> Put ( P ) ; > >> input_string := ( others => nul ) ; > >> for index in input_string'Range loop -- limits data size > >> Get ( char ) ; > >> -- Traps both LF or CR/LF type of EOL > >> exit when char = CR or char = LF ; > > > >.... and if the user immediately presses the return key > > (i.e., if you read an empty line), ... > > > >> input_string ( index ) := char ; > >> Last := Index ; > >> end loop ; > >> if char = CR then -- for CR/LF pairing type of OSs > >> Get ( char ) ; > >> end if ; > >> if char = LF or Last = input_string'Last then -- process EOL on screen > >> New_Line ; > >> end if ; > >> -- valid data is input_string ( 1 .. last ) ; > >> -- with no term control characters like LF or CR > > > >.... then Input_String ( 1.. Last ) depends on > > the uninitialised variable Last ... > > > >> return ( input_string ( 1 .. last ) ) ; > > > >.... and the statement above may raise an exception. > > > >> end get ; > > > >-- > >------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ > > Stefan dot Lucks at uni minus weimar dot de > >------ I love the taste of Cryptanalysis in the morning! ------ > > > > -- ------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ Stefan dot Lucks at uni minus weimar dot de ------ I love the taste of Cryptanalysis in the morning! ------ ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 8:58 ` stefan-lucks @ 2008-12-04 22:54 ` anon 2008-12-05 9:06 ` Georg Bauhaus 0 siblings, 1 reply; 28+ messages in thread From: anon @ 2008-12-04 22:54 UTC (permalink / raw) And it does work each time it is you run it. But if you follow the code you will see the routine is to be executed only once. The error is in making it a multi-usable code. with extra code allowing someone to reset the maximun string length. Plus the routine may need to handle BackSpace or Del characters and some other control characters. But like I said there are too many student cheating to give a complete example. But no one else even gave code. They just try to BS someone with a paragraph that say nothing. At least in my answer I gave a concept and a starting point that any programmer could follow and finish which would make the code his. But I guess except for Adam, Robbert Duff, and myself there are no programmer here. Only guys who can try to BS an answer to dead. To coin a phrase, "Talk is cheat, Code is priceless"! In <Pine.LNX.4.64.0812040954120.21966@medsec1.medien.uni-weimar.de>, stefan-lucks@see-the.signature writes: >On Thu, 4 Dec 2008, anon wrote: > >> Did I use the "pragma Initialize_Scalars ;" in GNAT.ADC or the command-line >> option version of that pragma or did I, as I have said "You do not give the >> complete code." >> >> That's something for you to think about! > >Well, in the message I replied to, you explicitely called your code a >"Full Working Example". I apologise for taking our postings seriously! > >> >> In <Pine.LNX.4.64.0812031226320.14772@medsec1.medien.uni-weimar.de>, stefan-lucks@see-the.signature writes: >> >On Wed, 3 Dec 2008, anon wrote: >> >> -- Build your own input routine. Example: >> >[...] >> > >> >if the variable Last is not initialised to 0 >> > *before* you enter the loop ... >> > >> >> begin >> >> Put ( P ) ; >> >> input_string := ( others => nul ) ; >> >> for index in input_string'Range loop -- limits data size >> >> Get ( char ) ; >> >> -- Traps both LF or CR/LF type of EOL >> >> exit when char = CR or char = LF ; >> > >> >.... and if the user immediately presses the return key >> > (i.e., if you read an empty line), ... >> > >> >> input_string ( index ) := char ; >> >> Last := Index ; >> >> end loop ; >> >> if char = CR then -- for CR/LF pairing type of OSs >> >> Get ( char ) ; >> >> end if ; >> >> if char = LF or Last = input_string'Last then -- process EOL on screen >> >> New_Line ; >> >> end if ; >> >> -- valid data is input_string ( 1 .. last ) ; >> >> -- with no term control characters like LF or CR >> > >> >.... then Input_String ( 1.. Last ) depends on >> > the uninitialised variable Last ... >> > >> >> return ( input_string ( 1 .. last ) ) ; >> > >> >.... and the statement above may raise an exception. >> > >> >> end get ; >> > >> >-- >> >------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ >> > Stefan dot Lucks at uni minus weimar dot de >> >------ I love the taste of Cryptanalysis in the morning! ------ >> > >> >> > >-- >------ Stefan Lucks -- Bauhaus-University Weimar -- Germany ------ > Stefan dot Lucks at uni minus weimar dot de >------ I love the taste of Cryptanalysis in the morning! ------ > ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: Weird string I/O problem 2008-12-04 22:54 ` anon @ 2008-12-05 9:06 ` Georg Bauhaus 0 siblings, 0 replies; 28+ messages in thread From: Georg Bauhaus @ 2008-12-05 9:06 UTC (permalink / raw) anon wrote: > The error is in > making it a multi-usable code. Good one. ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2008-12-05 9:06 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-26 5:52 Weird string I/O problem Jerry 2008-11-26 7:24 ` christoph.grein 2008-11-26 7:38 ` christoph.grein 2008-11-26 8:25 ` Dmitry A. Kazakov 2008-11-26 9:07 ` Jean-Pierre Rosen 2008-11-26 15:21 ` John McCormick 2008-11-26 15:56 ` Adam Beneschan 2008-11-27 10:13 ` Jean-Pierre Rosen 2008-12-01 16:17 ` Adam Beneschan 2008-11-27 4:46 ` Jerry 2008-11-27 10:27 ` Jean-Pierre Rosen 2008-12-01 19:47 ` anon 2008-12-02 5:44 ` christoph.grein 2008-12-02 6:55 ` anon 2008-12-02 7:53 ` christoph.grein 2008-12-02 16:39 ` Adam Beneschan 2008-12-03 9:16 ` anon 2008-12-03 10:42 ` christoph.grein 2008-12-03 12:21 ` John B. Matthews 2008-12-04 0:15 ` anon 2008-12-04 7:31 ` christoph.grein 2008-12-04 7:56 ` Ludovic Brenta 2008-12-04 8:46 ` Georg Bauhaus 2008-12-03 11:35 ` stefan-lucks 2008-12-04 0:27 ` anon 2008-12-04 8:58 ` stefan-lucks 2008-12-04 22:54 ` anon 2008-12-05 9:06 ` Georg Bauhaus
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox