<div dir="auto"><div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Michael Van Canneyt via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am So., 15. Dez. 2024, 18:25:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Sun, 15 Dec 2024, Adriaan van Os via fpc-pascal wrote:<br>
<br>
> Michael Van Canneyt via fpc-pascal wrote:<br>
>> <br>
>> <br>
>> On Sat, 14 Dec 2024, Adriaan van Os via fpc-pascal wrote:<br>
>> <br>
>> It's not because something is in the pascal standard, that FPC has it.<br>
><br>
> It is. Appendix D6 of the Programmer's Reference says<br>
><br>
>       "This mode is selected by the $MODE ISO switch. On the command line, <br>
> this mode is selected by<br>
> the -Miso switch. In this mode, the compiler complies with the requirements <br>
> of level 0 and level 1<br>
> of ISO/IEC 7185."<br>
<br>
Let's examine that statement for a second.<br>
<br>
In my copy of the standard, section "6.1.3 Identifiers" starts with: <br>
"Identifiers can be of any length."<br>
<br>
This is not implemented in FPC: identifiers are max 255 chars.<br>
<br>
Section "6.1.4 Directives" states:<br>
"The only directive shall be the required directive 'forward'"<br>
<br>
But you can also pefectly compile in ISO mode<br>
<br>
procedure a; cdecl; forward;<br>
<br>
One can use semantic tricks and say that 'cdecl' is a modifier,<br>
unfortunately then still the above violates the syntax diagram in section 6.6.2, <br>
which leaves no room for 'modifiers'.<br>
<br>
But either FPC follows the standard to the letter (that is why it is a standard), or<br>
it does not.<br>
<br>
Both examples show that in the strict sense, FPC does not follow the<br>
standard, even in ISO mode. Probably more examples can be found.<br>
<br>
For the quoted text to be painstakingly correct, the manual text should <br>
better be phrased as "The compiler tries to comply with..."<br>
<br>
The alternative is that we're a little more flexible in our interpretation of<br>
standards and manuals or messages on this list, and then we accept that there <br>
may be extra or missing things in either standard and/or implementation.<br>
<br>
Which I paraphrased loosely as: <br>
"It's not because something is in the pascal standard, that FPC has it."<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">As with any of the language dialect compatibility modes the point is that FPC can compile code in that dialect, but *not* that code that compiles in that dialect mode in FPC does also compile in another compiler that supports that dialect. </div><div dir="auto"><br></div><div dir="auto">For example FPC allows global generic functions in mode Delphi while Delphi itself does not support them. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>