From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,8143b93889fe9472
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
X-Received: by 10.180.87.229 with SMTP id bb5mr199110wib.7.1359710133717;
        Fri, 01 Feb 2013 01:15:33 -0800 (PST)
Path: 
 bp2ni9671wib.1!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Newsgroups: comp.lang.ada
Subject: Re: Ada standard and maximum line lengths
Date: Fri, 01 Feb 2013 11:15:32 +0200
Organization: Tidorum Ltd
Message-ID: <an1fdkFjimtU1@mid.individual.net>
References: <8dfcf819-e1d0-4578-a795-a4bf724b5014@googlegroups.com>
 <ke55qi$59m$1@dont-email.me> <ammppjF63goU1@mid.individual.net>
 <ke69q3$vou$1@dont-email.me> <amo50dFg605U1@mid.individual.net>
 <ke6o2n$jrj$1@dont-email.me> <amo8u2Fh3ngU1@mid.individual.net>
 <ke7peh$tof$1@dont-email.me> <ampmcqFqh9aU1@mid.individual.net>
 <5107b329$0$6556$9b4e6d93@newsspool4.arcor-online.net>
 <amptotFs5ouU1@mid.individual.net>
 <5107eaed$0$6566$9b4e6d93@newsspool4.arcor-online.net>
 <amqdeeF1b3qU1@mid.individual.net>
 <51080c38$0$6561$9b4e6d93@newsspool4.arcor-online.net>
 <amqnmtF3q45U1@mid.individual.net>
 <51085776$0$6637$9b4e6d93@newsspool2.arcor-online.net>
 <ams6reFdfsdU1@mid.individual.net> <wccfw1iheq9.fsf@shell01.TheWorld.com>
 <keca2j$uha$1@munin.nbi.dk> <wccwquucd1x.fsf@shell01.TheWorld.com>
 <kef08a$6om$1@munin.nbi.dk>
Mime-Version: 1.0
X-Trace: individual.net
 NyLWTj6daPNaabxygGPPYgkGsEqySArQ3z1FfORD1Mn6IZwRAxvTQQNEb7wp5qn1RZ
Cancel-Lock: sha1:VBBQBzEgY619ksNcIvqasj7E9L0=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:17.0) Gecko/20130107 Thunderbird/17.0.2
In-Reply-To: <kef08a$6om$1@munin.nbi.dk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Date: 2013-02-01T11:15:32+02:00
List-Id: <comp.lang.ada>

On 13-02-01 01:54 , Randy Brukardt wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> news:wccwquucd1x.fsf@shell01.TheWorld.com...
> ...
>>> ...but I still
>>> wouldn't like wasting significant amounts of memory (line/position
>>> information being stored in almost every symbol table entry) to carry 
>>> almost
>>> no information.
>>
>> There are various ways to store line/column numbers compactly without
>> limiting line lengths.
> 
> Really? Do tell! I know of no such technique that still would be usable 
> (meaning does not involve indirection, which would add complication and 
> fragmentation issues, and can be used at any time without calculation, 
> because you don't know ahead of time when and where you'll need to generate 
> error messages, debugging information, and traces).

I'm not sure that I understand your conditions on what is "usable", but
the LEB128 encoding (little-endian base 128) used in DWARF works pretty
well for storing unbounded but usually small integers without wasting a
lot of space. An integer is encoded as a sequence of octets, with one
end-marker bit and 7 significand bits in each octet. Numbers from 0 to
127 take one octet, number from 128 to 2**14 - 1 take two octets, and so on.

All records of course become variable-length octet sequences, which
causes processing overhead when storing and loading data. But if the
bottleneck is the disk I/O, that may be tolerable.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .