Re: [fpc-devel] wrong result for abs(low(int64))
Ahoy, hoy, On 2024‑04‑04 15:14:38 +0200, Martin Frb via fpc-devel wrote: > The below writes: -9223372036854775808 > > Shouldn't absolute return a positive number? No, see https://wiki.freepascal.org/Integer#characteristics -- Sincerely yours, Kai Burghardt signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question about "Default()"
Hello everyone! On 2024‑02‑22 14:27:01 +0100, Martin Frb via fpc-devel wrote: > [...] So is that a bug in Default? [...] I wondered about that, too: https://gitlab.com/freepascal.org/fpc/source/-/issues/34972 Resolution: It's not a bug. -- Sincerely yours, Kai Burghardt signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Policy regarding SHL/SHR under x86
Hi there: On 2022‑10‑24 11:51:32 +0100, J. Gareth Moreton via fpc-devel wrote: > [...] I've come across one situation that I need clarity on... how > are SHL and SHR instructions handled if the shift value exceeds the word > size? About a half year ago I raised a documentation issue regarding that: https://gitlab.com/freepascal.org/fpc/documentation/-/issues/39304 Bottom line: The behavior is _undefined_. Explanation by Jonas Maebe: > Such behaviour is indeed undefined (it's not implementation-defined > because when evaluating at compile time you may get different results > compared to when it gets evaluated at run time due to architecture > peculiarities). -- Sincerely yours, Kai Burghardt signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] New feature announcement: constant parameters for generics
Hey folks! On Sun, Apr 26, 2020 at 03:09:43PM +0700, Ryan Joseph via fpc-devel wrote: > It was meant for a pretty narrow use of array types. [...] If so, can I finally have my Extended Pascal schemata? https://wiki.freepascal.org/Extended_Pascal#Schemata_.28not_yet_implemented.29 It's basically the same, isn't it? Just a different syntax. [For reference: http://www.pascal-central.com/docs/iso10206.pdf (§ 6.4.7, PDF page 53)] -- Sincerely yours Kai Burghardt signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copyrighted material in bugtracker?
Ahoy! On Fri, Oct 04, 2019 at 10:23:34PM +0200, Bart wrote: > It appears that this is coe copied from some Delphi version. In general, I side with the FSF. Citing code - i.e. a /small/ excerpt _naming_ the source - is legit. No software patents! -- Sincerely yours Kai Burghardt signature.asc Description: PGP signature ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic
Nihao,
On Sat, Jul 13, 2019 at 01:52:46PM +0200, Michael Van Canneyt wrote:
> On Sat, 13 Jul 2019, Jonas Maebe wrote:
> > On 13/07/2019 13:28, J. Gareth Moreton wrote:
> > [...]
> >
> > Declare your enumation types so that the lowest and highest valid value
> > comprise the lowest and highest value representable by its storage:
> >
> > {$mode delphi}
> > {$z1}
> > type
> > tmyenum = (ea, eb, ec, emax = 255);
> >
> > That behaves the same both in FPC and in Delphi.
>
> This is a completely pointless definition, since for effective use you still
> need to add code to check that the value is a named one.
Not to mention, that this is the job of the {$PACKENUM} directive,
ensuring an enumeration type reserves a minimum amount of space.
--
Sincerely yours
Kai Burghardt
signature.asc
Description: PGP signature
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
