Re: My first compiler bug: work around or redesign?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

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.