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=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,bdebc54a485c13a4
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.204.150.90 with SMTP id x26mr2351698bkv.6.1332798454911;
        Mon, 26 Mar 2012 14:47:34 -0700 (PDT)
Path: 
 h15ni52758bkw.0!nntp.google.com!news1.google.com!goblin1!goblin2!goblin.stu.neva.ru!news.karotte.org!uucp.gnuu.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Mon, 26 Mar 2012 23:47:17 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7;
 rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: My first compiler bug: work around or redesign?
References: <slrnjmp96d.1lme.lithiumcat@sigil.instinctive.eu>
 <slrnjn1ch7.1lme.lithiumcat@sigil.instinctive.eu>
In-Reply-To: <slrnjn1ch7.1lme.lithiumcat@sigil.instinctive.eu>
Message-ID: <4f70e3e5$0$6566$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 26 Mar 2012 23:47:17 CEST
NNTP-Posting-Host: e8f29435.newsspool4.arcor-online.net
X-Trace: 
 DXC=HUY96HbDYlGlU`@c^jLCbJ4IUK<Cl32<A4Fo<]lROoRA8kF<OcfhCOKFOi;j7TObNBPCY\c7>ejVH`7eiob\>5UCGP:F7h0DD7@
X-Complaints-To: usenet-abuse@arcor.de
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-03-26T23:47:17+02:00
List-Id: <comp.lang.ada>

On 26.03.12 20:15, Natasha Kerensikova wrote:

> Somewhere in parser internals I use another kind of callbacks, that I
> call lexers (but I'm not completely sure I use the word with its correct
> meaning, though it does refer to code that find token start and end in a
> given String). These callbacks match the following type:
>
>     type Element_Lexer is
>        access procedure
>          (State : in out Lexer_State_Type;
>           Source : String;
>           Position : in out Positive;
>           Renderer : in not null Element_Renderer;
>           Renderer_State : in out Renderer_State_Type;
>           Render_Param : in out Parameter_Map);
>
> At this point, it does not make sense for Renderer to be null, because
> as explained above, a null value would have disabled the element and the
> Element_Lexer would never be called. So I added the "not null"
> constrained.

Looks quite right to me to say "not null" when a parameter shouldn't
be null.  If this condition is checked at compile time, it avoids
the embarrassment that potential null pointers can cause :-) For ease
of software maintenance (in the presence of bugs in the compiler), one
might also define a null excluding subtype.  The workaround is
then easily turned on and off in the single declaration in case there
are more occurrences of "not null Element_Renderer".  Don't know if the
immediate presence of "not null" would be stylistically preferable,
on the other hand.

    subtype Valid_Element_Renderer is not null Element_Renderer;

(I have chosen Valid_ just to have a name for the subtype, with no
aspiration to quality of naming.)


> Is it really worth reporting?

Yes. An observable bug is a bug, whatever the laws are.