Re: Problem with Unbounded Strings

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 4 Dec 2015 13:43:22 -0800 (PST), Laurent wrote:

> On Friday, 4 December 2015 21:34:59 UTC+1, Dmitry A. Kazakov  wrote:
>> On Fri, 4 Dec 2015 08:53:54 -0800 (PST), in comp.lang.ada you wrote:
>> 
>>> I don't use append?
>> 
>> No. There is nothing that is not in the buffer read already. Why would you
>> append anything?
>> 
>> In some protocols payload data are accumulated from several packets.
>> Unbounded_String is not used for that either. You want to limit the size of
>> the accumulated data to prevent DoS attacks unless the protocol limits that
>> already, as most protocols do. Simply keep the buffer in the communication
>> object, that is all.
> 
> DoS attacks? Why should I care in this case.

Corrupt files?

> I use the Unbounded Strings because I don't know in advance how many lines
> the message will be long. So I collect everything in a buffer, appending
> the following lines, so that it makes sense and when the message is
> complete, feed it to next procedure which slices of the interesting parts
> and uses them to generate a message object which I store somewhere or
> whatever if I should ever get so far.

No, the strategy is to pass lines or other parts of the message further
instead of accumulating it in the memory. Instead of this "hamster" design
I would do something like:

type Log_Parser
     (  Stream : not null access Root_Stream_Type'Class;
        Size : Positive
     )  is new Ada.Finalization.Limited_Controlled with
record
   Buffer : String (1..Size); -- Input is accumulated here
   Last : Natural; -- Current message line last character in Line_Buffer
   Stamp : Time; -- Current message's time stamp
   Line_No : Positive; -- Current message's line number
   ...
end record;

function Get_Line (Source : not null access Log_Parser) return String;
   -- reads from stream and returns Source.Buffer (1..Source.Last)

This will work with files as well. The client will call Get_Line for each
message line.

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