[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Sven Barth]

Pierre Muller <pierre at freepascal.org> schrieb am Fr., 5. Juli 2019, 17:51:

>
>
> Le 05/07/2019 à 17:42, J. Gareth Moreton a écrit :
> >
> > On 05/07/2019 15:51, Pierre Muller wrote:
> >> Just one point from current compiler implementation:
> >>
> >> in trunk/fpcsrc/compiler/ninl.pas (around line 3180)
> >>
> >>                in_pred_x,
> >>                in_succ_x:
> >>                  begin
> >>                     set_varstate(left,vs_read,[vsf_must_be_valid]);
> >>                     resultdef:=left.resultdef;
> >>                     if is_ordinal(resultdef) or is_typeparam(resultdef)
> then
> >>                       begin
> >>                         if (resultdef.typ=enumdef) and
> >>                            (tenumdef(resultdef).has_jumps) and
> >>                            not(m_delphi in
> current_settings.modeswitches) and
> >>                            not(nf_internal in flags) then
> >>
>  CGMessage(type_e_succ_and_pred_enums_with_assign_not_possible);
> >>                       end
> >>
> >>
> >> This means that using pred() or succ() intrinsics on enumerated types
> with
> >> holes will generate a Compile Time Error.
> >>
> >>    To be consistent, I would propose that we also generate
> >> a Compile Time Error if 'is' or 'as' keyword is used on such a type,
> >> unless there is a code that really check that the value is not in
> >> one of the holes ...
> >>
> >> Pierre
> >
> > That seems fair.  The main problem is what happens if, when allowed,
> > Prec or Succ are used on such a type on an element that is adjacent to
> > one of these holes.  Should it skip to the first element at the other
> > end of the hole or raise an exception? Granted, what happens if you use
> > Prec or Succ on the first or last element respectively?
> >
> > I can theoretically design an algorithm to cover these gaps with Boolean
> > conditions for the sake of "is", but it's a little bit complex.
> >
> > Sorry to bring you in on this particular point, Pierre, but if you call
> > "Value is TEnum" and Value is of type TEnum but contains an invalid
> > value (due to being read from an external stream, for example), should
> > it return True or False?
>
>   My answer would be:
>
> in FPC modes, simply generate a CompileTimeError as above,
>
> in Delphi mode, as Delphi states stat the holes are also valid values of
> the range,
> then indeed, pred() and succ() can do the simple thing they do when there
> are no holes,
> and 'is' or 'as' should then also do the same, i.e. only check that the
> value is inside
> the range defined by the lowest and highest values!
>
>   But on course this means that in Delphi mode,
> even after validating with 'is' you could still have a valid enum value
> that has no
> name, i.e. that is in one of those black holes ...
>
>   I don't need to tell you that I do have a preference for the ordinary
> Free Pascal way!
>

I think Gareth meant his question for enums without holes ;)

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190705/4019cf22/attachment.html>