[fpc-devel] bug: Inc(v,i)/Dec(v,i)

[Gerhard Scholz]

----- Original Message -----
From: "Marco van de Voort" <marcov at stack.nl>
To: "FPC developers' list" <fpc-devel at lists.freepascal.org>
Sent: Friday, July 08, 2005 11:52 AM
Subject: Re: [fpc-devel] bug: Inc(v,i)/Dec(v,i)


> > Solution 1 of course would be:
> >
> >     if delta < 0
> >         then dec ( v, -delta )
> >         else inc ( v, delta ) ;
>
> inc(longint(v),delta);

Interesting, I didn't know typecasts on the left side of assignment yet.
Doesn't look very portable.

Beside, v is word or byte, depending on a compiler-$if elsewhere, so I would
have to write:

inc ( {$ifdef big} smallint {$else} shortint {$endif }v, delta ) ;

Not very clear readable.

...
> This doesn't fix the problem that you are mixing types. v:=v+d is flawed
from
> that perspective too, the compiler even complains
>
> smbg.pp(9,7) Warning: Mixing signed expressions and longwords gives a
64bit result
>
> on a line like
>
>   v:=v+-5;

I'm sorry, v IS unsigned, delta IS signed, and the computation has to be
done. Besides, v and d are 8-bit or 16-bit, and the result WILL fit in v
(that is checked before for other reasons).

Of course, I could convert both v and d to some signed int first, do the
computation, and store it back to v, but that just elongates the code and
should produce the same result.

And I prefer to develop programs with $r+,q+,etc.-checks on and with ranges
(I seldom declare "v : integer"; more often I declare "v : 0..99" or
similar) [this was one of the major benefits of Pascal against other
languages when it was invented] and this saves a good part of testing time.
And while testing I do not mind speed as a major factor, but stability.

Gerhard