[fpc-devel] Constants in generics patch
I’m not sure the issue is being monitored so I wanted to mention that another user was kind enough to update my last patch so it’s more mergeable now (https://bugs.freepascal.org/view.php?id=35140). Does the patch need to go through more review first before it’s ready to apply? I believe I got it all tested and it’s fully functional now (another user has been tested it also as you’ll see in the notes). Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Language Specification
On 20/05/2019 09:44, Michael Van Canneyt wrote: On Mon, 20 May 2019, J. Gareth Moreton wrote: While there is documentation online that can easily explain all of this, I find it's only truly useful if you are looking up details on a specific feature - for example, the standard of expanding intermediate expressions to the CPU word size has caught many programmers off-guard. Having it in a single specification means that the curious can read through it in its entirety to learn of these nuances before falling foul of them. What are your thoughts? Maybe start from the official ISO pascal or extended pascal specs and rewrite that to match the compiler implementation. Michael. Normally it doesn't quite work that way. It's more about what we expect and desire the language to do from a design perspective - it is allowed to change with implementation considerations, but normally it's not the first point of consideration. To give the example of case blocks, since that's been a point of contention lately, do we specify that all possible input values have a valid branch and enumerated inputs aren't range-checked, or do we just go by the implementation and say "it's not a bug, it's a feature" if something looks different? There's also the point that we may desire the language to behave a certain way, but a subtle bug in the implementation means that it doesn't under certain circumstances? I suppose going by the implementation is better than nothing, but normally it's not taken to be the definitive authoritive guide. And for new features like *pure* functions, I much rather have something written down and locked before I blindly start programming them and making it up as I go along. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected behaviour of bit operators
On Fri, 17 May 2019 18:06:13 +0200 Ondrej Pokorny wrote: > On 17.05.2019 10:47, Marco Borsari via fpc-devel wrote: > > Does this is an effect of some multiplication overflow, or is it a bug? > > Both the bit operations and the arithmetic opretaions return integers as > results and not words: > https://www.freepascal.org/docs-html/ref/refsu46.html > https://www.freepascal.org/docs-html/ref/refsu45.html#x148-1712.8.1 > > The c:=... overflows - you get a range check error: > > c:=(a XOR b)*(a SHL 5+b SHR 2); // range check error > > Just add a couple of word() casts where you need the integer-result to > be casted to word: I tested it (the hash is used for a contest selector in a data compressor), but it seems that the results are bit identical with or without the cast. Do you point it out to suppress false positives in a debug phase? Anyway, thank you. -- Simplex sigillum veri ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC Language Specification
On Mon, 20 May 2019, J. Gareth Moreton wrote: While there is documentation online that can easily explain all of this, I find it's only truly useful if you are looking up details on a specific feature - for example, the standard of expanding intermediate expressions to the CPU word size has caught many programmers off-guard. Having it in a single specification means that the curious can read through it in its entirety to learn of these nuances before falling foul of them. What are your thoughts? Maybe start from the official ISO pascal or extended pascal specs and rewrite that to match the compiler implementation. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
