Weird string I/O problem

Weird string I/O problem

[Jerry]

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

Re: Weird string I/O problem

[christoph.grein]

>     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).

Re: Weird string I/O problem

[christoph.grein]

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".)

Re: Weird string I/O problem

[Dmitry A. Kazakov]

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

Re: Weird string I/O problem

[Jean-Pierre Rosen]

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

Re: Weird string I/O problem

[John McCormick]

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

Re: Weird string I/O problem

[Adam Beneschan]

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

Re: Weird string I/O problem

[Jean-Pierre Rosen]

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

Re: Weird string I/O problem

[Adam Beneschan]

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

Re: Weird string I/O problem

[Jerry]

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

Re: Weird string I/O problem

[Jean-Pierre Rosen]

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

Re: Weird string I/O problem

[anon]

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

Re: Weird string I/O problem

[christoph.grein]

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
>
> -- ...

Re: Weird string I/O problem

[anon]

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
>>
>> -- ...

Re: Weird string I/O problem

[christoph.grein]

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.

Re: Weird string I/O problem

[Adam Beneschan]

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

Re: Weird string I/O problem

[anon]

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

Re: Weird string I/O problem

[christoph.grein]

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?

Re: Weird string I/O problem

[John B. Matthews]

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/

Re: Weird string I/O problem

[anon]

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?

Re: Weird string I/O problem

[christoph.grein]

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."

Re: Weird string I/O problem

[Ludovic Brenta]

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.

Re: Weird string I/O problem

[Georg Bauhaus]

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.

Re: Weird string I/O problem

[stefan-lucks]

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

Re: Weird string I/O problem

[anon]

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

Re: Weird string I/O problem

[stefan-lucks]

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

Re: Weird string I/O problem

[anon]

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

Re: Weird string I/O problem

[Georg Bauhaus]

anon wrote:
> The error is in 
> making it a multi-usable code.

Good one.