Variable length strings...

Variable length strings...

[Thomas Hoyt]

In issue #142, D. Papay is right on the $$$ with his comments on variable
length strings.  However...

>...I suggest you remove the default expression " := 0" from your
> record type ... and always declare ... with explicit discriminant
> contraints...

If you do this, you lose all the advantages of a parameterized record,
i.e. variable length strings.  Why not constrain the subtype of the
range of the record parameter:
^^^^^
   subtype Len_range is integer range 0..256; -- or some other max
                                              -- string length

This way the compiler would know exactly how big the strings could ever
get and plan accordingly...i.e. stop complaining.

Of course, you could still have pretty huge strings without coming close to
whatever Integer'Last is.  Another advantage is that the writer of the
generic could explicitly control how big the variable length strings
could ever get, without having to rely upon implimentation details. 

You also eliminate a generic parameter, relieving the user of an unnecessary
detail.  Most text editing functions wouldn't ever need more than about
1024 chars at a time (need...hope?:-))
 

******
Thomas Hoyt             |  "Government Computers for Government business..."
CRC Systems, Inc.       |  "NO FUN ALLOWED..."
thoyt@ddn-wms.arpa		|	"Oh no...it's written in COBOL..."
******

re: Variable Length Strings

["Jonathan B. Owen"]

In issue #143, Thomas Hoyt replied to my question about variable length
strings.  He is right by commenting that if the type V_string is used
without the default of zero, your string is not of a variable length...

Cliff baker replied to my question by saying he thinks the Verdix Ada
is not smart enough to recognize the Max. size of the type by taking
into consideration the upper limit of Len_range (and that the problem
has nothing to do with the fact that the package is generic).  Well,
I disagree with this, as the Verdix Ada DOES recognize the max. size,
IF THE UPPER LIMIT OF THE SUBTYPE IS CONSTANT, as in:

   subtype Len_range is integer range 0..132;

I did not bother to mention my work-around to this problem.  I defined
a few non-generic packages to handle V_strings of length 15,80,132,512,
1024,2048.  I had to replicate manually the body of these packages.  Of
course working this way is a compromise...  The point is that the Verdix
Ada works fine with these non-generic packages, in respect to the
issue at hand.

Baring the above in mind, I don't understand why the generic parameter
Max_len should not be considered constant for the issue of determining
the max. size.  After all, it's value is avaliable during elaboration
time, and of course cannot change, there after.

                                   Any thoughts?

                                                Jonathan

______________________________________________________________________________
  (--)    /--)     /-(\                 Email: gdau100@bguvm (bitnet)
  \ /    /--K      | \|/\   /\/) /|-\   Snail: 55 Hovevei Zion
  _/_/o /L__)_/o \/\__/  \X/  \_/ | |_/        Tel-Aviv, 63346  ISRAEL
 (/        Jonathan B. Owen             Voice: (03) 281-422

 Point of view:  A chicken is the means by which an egg reproduces an egg.
______________________________________________________________________________

Variable Length Strings...

[Thomas Hoyt]

In Issue #143, Jonathon B. Owen writes...
>...
>Baring the above in mind, I don't understand why the generic parameter
>Max_len should not be considered constant for the issue of determining
>the max. size.  After all, it's value is avaliable during elaboration
>time, and of course cannot change, there after.

From what I understand of your problem, it *is* a constant, just a constant
that is too big for the compiler to handle.  Max_Len is declared:

   generic
      Max_Len : Integer;
   Package (etc)...

The string range statement thus defines the variable length string to be
anywhere from 0 to Integer'Last.  This raises the possiblity that Integer'Last
length strings could be created on the fly.  This frightening implication
causes the anxiety from the compiler.

Try this in your original generic.  Put some constaints on the generic
parameter:

   generic
      Max_Len : Integer range 0..20000 := 20000;
   Package (etc)...

This does two things.  It allows for a default max variable string length
if you choose to pass in nothing for the parameter.  It also tells the
compiler that at most there will be 20000 char length strings created
dynamically.  This is a whole lot less than Integer'Last( normally around
2^32 or there abouts ) and will calm Verdix's nerves.  Of course, you can
adjust the constants accordingly.  Also there may be implimentation limits
on how big you can define dynamic objects at one time.  As always, check
your manuals.

This ought to permit you to keep the generic solution, i.e. without hard
coding string range limits into separate packages. (*Disclaimer* I do
not *sigh* have access to a Verdix compiler...as always, if this patch should 
fail, the secretary will disavow all knowledge...etc...)


******
thoyt@ddn-wms.arpa      |  "Oh no...it's written in COBOL..."
Thomas Hoyt             |  "Government Computers for Government business..."
CRC Systems, Inc., Fairfax, VA -- 703-359-9400       |  "NO FUN ALLOWED..."
******

Variable Length strings...

["Jonathan B. Owen"]

Thomas Hoyt writes that having the following:

   generic
         Max_len : Integer;
   package VSTR is

         subtype Len_range is integer range 0..Max_len;

   etc...

DOES imply a maximum length for a discriminant of type Len_range, be it
integer'LAST.   Also, he suggests using a fixed upper limit to Max_len,
say 20000.

   First, as far as I observed, on Vax Ada, the actuall value for Max_len
for a particular instantiation is taken as the upper limit for a disc.
of type Len_range.   I see no reason why Verdix Ada should not do it.

   Secondly, I do believe defining the range of Max_len to be limited to
20000.   Still, I think it would be unreasonable to allocate 20K for each
V_string defined, when typicalalues for Max_len would be much smaller
(say 15, 80 and such).

   It seems to me Verdix Ada handles Dynamically defined types/Subtypes
differently than the Vax Ada.

   Come to think of it, I ran into a related problem as the above, in
a non-generic package.

   Consider the following:

       type Record_header is
           record
               key  : Key_type;
               time : Time_type;
           end record;

       Max_data_len : constant integer := 2048-Record_header'SIZE/8;

       subtype Data_len_range is integer range 0..Max_data_len;

       type Record_type( data_len : Data_len_range := 0 ) is
           record
               header : Record_header;
               data   : String(1..data_len);
           end record;

Say the Record_header occupies 48 bytes.  The purpose of the above is
to define a record which would occupy 2K at the most, including the
header.   The above works find on Vax-Ada but fails on Verdix with
the same problem of not recognizing the upper limit of Data_len_range.

                      I hope the shortcoming of Verix is now obvious...

                                                   Jonathan

______________________________________________________________________________
  (--)    /--)     /-(\                 Email: gdau100@bguvm (bitnet)
  \ /    /--K      | \|/\   /\/) /|-\   Snail: 55 Hovevei Zion
  _/_/o /L__)_/o \/\__/  \X/  \_/ | |_/        Tel-Aviv, 63346  ISRAEL
 (/        Jonathan B. Owen             Voice: (03) 281-422

 Point of view:  A chicken is the means by which an egg reproduces an egg.
______________________________________________________________________________

Re: Variable Length Strings

[Paul Warren]

In article <8906012020.AA03083@ajpo.sei.cmu.edu>, GDAU100@BGUVM.BITNET ("Jonathan B. Owen") writes:
> In issue #143, Thomas Hoyt replied to my question about variable length
> strings.  He is right by commenting that if the type V_string is used
> without the default of zero, your string is not of a variable length...
> 

I used to use the V_STRING package quite a lot (using the Alsys compiler)
and discovered that it was none too fast.  I tried a Grady Booch
package for the same job and got a speed-up factor of 40.

I never tried these two components on VADS though.
-- 
Paul Warren,				tel +44 970 623111 x3068
Computer Science Department,		pfw%cs.aber.ac.uk@uunet.uu.net (ARPA)
University College of Wales,		pfw@uk.ac.aber.cs (JANET)
Aberystwyth, Dyfed, United Kingdom. SY23 3BZ.

Re: variable length strings

[Larry Kilgallen]

In article <mailman.61.1098789536.10401.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:

> This however perpetuates another problem: text files cannot be shared 
> between different OSes.

The problem of variable length record text files is beyond the reach
of any Ada standard.

The possibilities VMS must handle are:

	Out-of-band record termination (as codified in ISO-9660 6.10.4)
	CRLF record termination (compatible with Microsoft)
	CR record termination (compatible with MacOS)
	LF record termination (compatible with Unix)

I do not think any non-proprietary standard supports all of those (in
the sense of providing an out-of-band indicator regarding which is in
use).

Solutions which involve rewriting the data into another format are only
for people who have never seen a truly large file.  ISO-9660, for example
can use 32767 volumes to hold a single file, and even though the various
DVD formats are limited to less than about 10 GB, the ISO-9660 format
can also be used on magnetic disks.

Re: variable length strings

[Warren W. Gay VE3WWG]

Larry Kilgallen wrote:
> In article <mailman.61.1098789536.10401.comp.lang.ada@ada-france.org>, Marius Amado Alves <amado.alves@netcabo.pt> writes:
> 
> 
>>This however perpetuates another problem: text files cannot be shared 
>>between different OSes.
> 
> 
> The problem of variable length record text files is beyond the reach
> of any Ada standard.
> 
> The possibilities VMS must handle are:
> 
> 	Out-of-band record termination (as codified in ISO-9660 6.10.4)
> 	CRLF record termination (compatible with Microsoft)
> 	CR record termination (compatible with MacOS)
> 	LF record termination (compatible with Unix)

Conceptually, someone/OS could also create:

         LFCR record termination

though I don't know of any in the wild.


> I do not think any non-proprietary standard supports all of those (in
> the sense of providing an out-of-band indicator regarding which is in
> use).

Agreed. I think it is reasonable that text files be in the correct
format for the platform in use. If they are not, then they require
conversion. I also accept that from a practical point of view, we
all like it to adapt anyway ;-)

Warren.

Re: variable length strings

[Björn Persson]

Warren W. Gay VE3WWG wrote:

> I think it is reasonable that text files be in the correct
> format for the platform in use. If they are not, then they require
> conversion. I also accept that from a practical point of view, we
> all like it to adapt anyway ;-)

The way I see it, the unfortunate reality is that any program that 
processes text files needs to handle both LF, CR and CR-LF, and maybe 
NEL too (and record-based files on such platforms I suppose), as well as 
both presence and absence of a line break at the end of the last line. 
In the Internet era it's not possible to keep all your files in one format.

In the IO package for EAstrings I let the programmer configure the line 
break characters for each file. By default it uses the platform's 
convention on output and recognizes LF, CR, CR-LF and NEL on input.

-- 
Björn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: variable length strings

[Larry Kilgallen]

In article <n0xfd.7175$d5.60027@newsb.telia.net>, =?ISO-8859-1?Q?Bj=F6rn_Persson?= <spam-away@nowhere.nil> writes:
> Warren W. Gay VE3WWG wrote:
> 
>> I think it is reasonable that text files be in the correct
>> format for the platform in use. If they are not, then they require
>> conversion. I also accept that from a practical point of view, we
>> all like it to adapt anyway ;-)
> 
> The way I see it, the unfortunate reality is that any program that=20
> processes text files needs to handle both LF, CR and CR-LF, and maybe=20
> NEL too (and record-based files on such platforms I suppose), as well as =
> both presence and absence of a line break at the end of the last line.=20

VAX/DEC/Compaq/HP Ada on VMS (and presumably GNAT on VMS) have that
under control just by making the operating system call that takes
care of such differences.

Re: variable length strings

[Jacob Sparre Andersen]

Pascal Obry wrote:

> Such program is creating a security hole anyway... if you know that
> somebody has used such algorithm just send him (file upload on a Web
> site for example) a file with a very long line!

Please distinguish between security (unauthorized access) and
denial-of-service.

And will continuous appending to an Unbounded_String not give the same
risks?

Greetings,

Jacob
-- 
"It's not a question of whose habitat it is,
 it's a question of how fast you hit it."

Re: variable length strings

[Pascal Obry]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> And will continuous appending to an Unbounded_String not give the same
> risks?

Probably but a program has certainly lot more heap space than stack space. And
if a chunk of memory can't be allocated you get a Storage_Error exception. At
this point the program can still try to recover (the stack being clean) by
calling some clean-up routines.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Larry Kilgallen]

In article <rlssm80bgp2.fsf_-_@jacob.crs4.it>, Jacob Sparre Andersen <sparre@nbi.dk> writes:

> Please distinguish between security (unauthorized access) and
> denial-of-service.

Since the time of the Orange Book, security has long been divided
into three segments in discussions:

	Confidentiality
	Integrity
	Availability

Denial-of-service issues clearly fall under Availability.
Unauthorized access is just a tiny part of Confidentiality.

Re: variable length strings

[Larry Kilgallen]

In article <uwtxcla1n.fsf@obry.org>, Pascal Obry <pascal@obry.org> writes:
> 
> Jacob Sparre Andersen <sparre@nbi.dk> writes:
> 
>> And will continuous appending to an Unbounded_String not give the same
>> risks?
> 
> Probably but a program has certainly lot more heap space than stack space.

Your "certainly" is misplaced since you do not restrict your claim to
a particular environment or program.

On VMS (even VAX) the stack space for the main DEC Ada task is limited
to roughly 1 Gigabyte (minus some overhead).  The heap space is limited
to the same size, minus the size of the program.  As programs get larger
the availability of stack space over heap space grows.

Re: variable length strings

[Samuel Tardieu]

>>>>> "Larry" == Larry Kilgallen <Kilgallen@SpamCop.net> writes:

Larry> In article <uwtxcla1n.fsf@obry.org>, Pascal Obry
Larry> <pascal@obry.org> writes:

>>  Probably but a program has certainly lot more heap space than
>> stack space.

Larry> Your "certainly" is misplaced since you do not restrict your
Larry> claim to a particular environment or program.

Pascal was probably thinking about multi-tasking programs, where the
default stack size per task is usually small while the heap is
generally limited only by the available memory.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: variable length strings

[Pascal Obry]

Samuel Tardieu <sam@rfc1149.net> writes:

> Pascal was probably thinking about multi-tasking programs, where the
> default stack size per task is usually small while the heap is
> generally limited only by the available memory.

Yes. Thanks for pointing this.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Pascal Obry]

Kilgallen@SpamCop.net (Larry Kilgallen) writes:

> Your "certainly" is misplaced since you do not restrict your claim to
> a particular environment or program.

I don't know all of them :) And since the goal is to develop programs that
are *safe* (whatever it means for you) I think that such Get_Line
implementation should be avoided. Moreover returning unconstraint objects on
the stack uses lot of stack space (ok, this depends on the
implementation). Now you are free to choose the implementation you like :) I
will never accept such Get_Line implementation, that's all!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Dmitry A. Kazakov]

On 27 Oct 2004 15:04:31 +0200, Pascal Obry wrote:

> Kilgallen@SpamCop.net (Larry Kilgallen) writes:
> 
>> Your "certainly" is misplaced since you do not restrict your claim to
>> a particular environment or program.
> 
> I don't know all of them :) And since the goal is to develop programs that
> are *safe* (whatever it means for you) I think that such Get_Line
> implementation should be avoided. Moreover returning unconstraint objects on
> the stack uses lot of stack space (ok, this depends on the
> implementation).

But the existing Get_Line does not reaches the goal either. Normally it is
used with the buffer allocated on the stack. So it is the stack again.
Moreover, differently to the "unsafe" version you are forced to allocate
more stack than actually needed, to read the longest possible line. Where
that upper limit is quite often undeterminable: "as much as the computer
can".

> Now you are free to choose the implementation you like :) I
> will never accept such Get_Line implementation, that's all!

Huh, better to have something that works in 99% cases than to face a global
memory optimization problem. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: variable length strings

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> But the existing Get_Line does not reaches the goal either. Normally it is
> used with the buffer allocated on the stack. So it is the stack again.

That's wrong!

   procedure Get_Line(Item : out String; Last : out Natural);

The buffer is bounded in this case, it's up to you to read a chunk of data
(using a small buffer on the stack) and do whatever is needed with it. So I
see not problem with the standard Get_Line. I never said that you can't use
the stack, just that using a buggy Get_Line implementation as proposed here
could heat too much stack space and is therefore unsafe.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Jacob Sparre Andersen]

Larry Kilgallen wrote:
> In article <rlssm80bgp2.fsf_-_@jacob.crs4.it>, Jacob Sparre Andersen
> <sparre@nbi.dk> writes:

> > Please distinguish between security (unauthorized access) and
> > denial-of-service.
> 
> Since the time of the Orange Book, security has long been divided
> into three segments in discussions:
> 
> 	Confidentiality
> 	Integrity
> 	Availability
> 
> Denial-of-service issues clearly fall under Availability.
> Unauthorized access is just a tiny part of Confidentiality.

I stand corrected, apologise to Pascal, and go to the library to have
a look at the �Orange Book� (what's its real title?).

Jacob
-- 
"simply because no one had discovered a cure for the universe as a
 whole - or rather the only one that did exist had been abolished"

Re: variable length strings

[Dmitry A. Kazakov]

On 27 Oct 2004 18:38:29 +0200, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> But the existing Get_Line does not reaches the goal either. Normally it is
>> used with the buffer allocated on the stack. So it is the stack again.
> 
> That's wrong!
> 
>    procedure Get_Line(Item : out String; Last : out Natural);
> 
> The buffer is bounded in this case, it's up to you to read a chunk of data
> (using a small buffer on the stack) and do whatever is needed with it. So I
> see not problem with the standard Get_Line.

You (Get_Line) just push the problem to the user, who will write:

declare
   Buffer : String (1..?);
   Length : Integer;
begin
   Get_Line (Buffer, Length);

1) Buffer is on the stack. 2) Its upper bound is unknown except for very
rare cases. The requirements usually as helpful as "it should work with
reasonable files". Go figure out the upper bound!

As for chunks of data, this is well another story. Note, if the parsing
methods allow arbitrary splitting the lines <=> it can work with character
stream <=> you need no Get_Line, the appropriate method is:

procedure Get(Item : out Character); 

> I never said that you can't use
> the stack, just that using a buggy Get_Line implementation as proposed here
> could heat too much stack space and is therefore unsafe.

I agree that it is a problem, but it is not the Get_Line's one. It is a
more general language issue, which probably should be answered in the
future. We cannot just dismiss T'Class, unconstrained containers etc. An
ability to deal with them (on the stack) is quite important. It is also a
question what compromises safety more: use of pointers or potential stack
overflow. For large projects, I would say it is definitively pointers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: variable length strings

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> You (Get_Line) just push the problem to the user, who will write:
> 
> declare
>    Buffer : String (1..?);
>    Length : Integer;
> begin
>    Get_Line (Buffer, Length);
> 
> 1) Buffer is on the stack. 2) Its upper bound is unknown except for very
> rare cases. The requirements usually as helpful as "it should work with
> reasonable files". Go figure out the upper bound!

You missed it ! Please have a look at the Get_Line documentation.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Dmitry A. Kazakov]

On 28 Oct 2004 10:49:14 +0200, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> You (Get_Line) just push the problem to the user, who will write:
>> 
>> declare
>>    Buffer : String (1..?);
>>    Length : Integer;
>> begin
>>    Get_Line (Buffer, Length);
>> 
>> 1) Buffer is on the stack. 2) Its upper bound is unknown except for very
>> rare cases. The requirements usually as helpful as "it should work with
>> reasonable files". Go figure out the upper bound!
> 
> You missed it ! Please have a look at the Get_Line documentation.

What have I missed?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: variable length strings

[Larry Kilgallen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]

In article <rlsoeinb9ag.fsf@jacob.crs4.it>, Jacob Sparre Andersen <sparre@nbi.dk> writes:
> Larry Kilgallen wrote:
>> In article <rlssm80bgp2.fsf_-_@jacob.crs4.it>, Jacob Sparre Andersen
>> <sparre@nbi.dk> writes:
> 
>> > Please distinguish between security (unauthorized access) and
>> > denial-of-service.
>> 
>> Since the time of the Orange Book, security has long been divided
>> into three segments in discussions:
>> 
>> 	Confidentiality
>> 	Integrity
>> 	Availability
>> 
>> Denial-of-service issues clearly fall under Availability.
>> Unauthorized access is just a tiny part of Confidentiality.
> 
> I stand corrected, apologise to Pascal, and go to the library to have
> a look at the �Orange Book� (what's its real title?).

Reverse engineering "TCSEC", I believe it is "Trusted Computer Security
Evaluation Criteria".

But I did not promise those exact words are in the Orange Book, just
that the _timing_ of that terminology matched that of the Orange Book :-)

While those words were widely used at the time, NSA employees might
have felt it inappropriate to use three terms with that acronym.
But it was the way the rest of us remembered them.

Re: variable length strings

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> > You missed it ! Please have a look at the Get_Line documentation.
> 
> What have I missed?

That when there is nothing more to read Last is set to 0. So I don't see the
problem with Get_Line. You use a small buffer on the stack, and read chunk of
data at a time. You are free to write those data where you want in memory or
on disk or ...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: variable length strings

[Jeffrey Carter]

More FWIW: I implemented a binding to the C function fgets, which 
behaves similarly to Ada.Text_IO.Get_Line (stops at end of buffer or end 
of line; in latter case, skips line terminator), and implemented a 
Get_Line function using it. It exhibits the same behavior as a Get_Line 
function using Ada.Text_IO.Get_Line for the case of a last line that is 
not properly terminated and is a multiple of the buffer length.

Win98/GNAT 3.15p.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: variable length strings

[Randy Brukardt]

"Jeffrey Carter" <spam@spam.com> wrote in message
news:E2egd.10071$KJ6.6647@newsread1.news.pas.earthlink.net...
> More FWIW: I implemented a binding to the C function fgets, which
> behaves similarly to Ada.Text_IO.Get_Line (stops at end of buffer or end
> of line; in latter case, skips line terminator), and implemented a
> Get_Line function using it. It exhibits the same behavior as a Get_Line
> function using Ada.Text_IO.Get_Line for the case of a last line that is
> not properly terminated and is a multiple of the buffer length.
>
> Win98/GNAT 3.15p.

C is broken so Ada should be too? That makes *no* sense.

For the record, Janus/Ada inserts a (single) implied line terminator at the
end of a file if there is not one explicitly there. So the OP's technique
will work without any headstanding. Note that handling End_Error provides no
help in this case, because doing so would cause the last line to be
discarded (if there was no implicit line terminator).

GNAT's implementation may be technically correct, but an implementation that
doesn't allow reading the last line of a file without standing on your head
is (practically) broken IMHO. How many people know to worry about this?

                             Randy.

Re: variable length strings

[Jeffrey Carter]

Randy Brukardt wrote:
> 
> C is broken so Ada should be too? That makes *no* sense.

It was certainly not my intention to imply that; I'm merely cataloguing
the behavior of different systems. So far I've tried GNAT, ObjectAda,
and gcc C. I have an old Janus/Ada 83 for DOS somewhere, but I'll take
your word that it behaves differently.

> Huh? A null line without a line terminator would be indistinguishable
> from a line terminator at the end of a file. So it is perfectly
> reasonable for an implementation to treat this as reading past the
> end of a file (Janus/Ada certainly does too). Indeed, I'd argue that
> it is impossible for there to be a null line without a line
> terminator at the end of a file.

I think we violently agree about this.

> The case I'm talking about is when the last line is *not* null and
> there is no explicit line terminator. In that case, the
> implementation should provide an implicit line terminator, as the
> logical view of a file is that it is always there (see A.10(7)), and
> (IMHO) it is unreasonable to refuse to properly process a file that
> is missing one.

And about this, too.

-- 
Jeff Carter
"In the frozen land of Nador they were forced to
eat Robin's minstrels, and there was much rejoicing."
Monty Python & the Holy Grail
70

Re: variable length strings

[Dmitry A. Kazakov]

On 28 Oct 2004 18:07:24 +0200, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>>> You missed it ! Please have a look at the Get_Line documentation.
>> 
>> What have I missed?
> 
> That when there is nothing more to read Last is set to 0.

How do you know that there *will* be nothing more, when you allocate the
buffer?

> So I don't see the
> problem with Get_Line. You use a small buffer on the stack, and read chunk of
> data at a time.

Re-read my post. If you *can* do it, then you need no Get_Line.

> You are free to write those data where you want in memory or
> on disk or ...

The issue is: what is the best way to get one physical line in one
*contiguous* piece of memory.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de