$MINSTACKSIZE unexpected behavior without warning

[440bx]

Hello,

including a simple expression in $MINSTACKSIZE such as {$MINSTACKSIZE 7 * 1024 * 1024} causes its value to be set to 7 instead of 7,000,000 without a warning, note or any indication that the value used is nowhere near the value specified.

The documentation does not state whether or not an expression is valid but, when using one, the compiler doesn't complain giving the impression that using an expression is valid when it really is not.

Comments welcome.

[MarkMLl]

But is this really unexpected? $endif etc. ignore anything after the first space so it's reasonable to assume that that's the default behaviour: are there any pragmata where an expression, particularly one not parenthesised, is evaluated?

MarkMLl

[440bx]

But is this really unexpected?

What I consider unexpected is the lack of any warning or note about the compiler ignoring the remainder of the expression.  Whatever routine is parsing that directive must be looking for the closing brace "}" therefore it is aware of all the characters in between yet says nothing about ignoring them.   That's just not the way a normal parser behaves.

[MarkMLl]

But pragamata and comments aren't parsed, they're generally handled by the lexer (which is why a conditionally-compiled fragment doesn't have to be valid Pascal, and why nested comments are an issue). You don't expect a warning from either

{$endif WINDOWS } <-- "Appended string WINDOWS ignored"

or

{$endif } <-- "Missing closing identifier"

This might be something which could benefit from being explicitly mentioned in the documentation: when doing this stuff myself I've sometimes put a box at the top of a documentation section with checkboxes for "Parameter invalid", "numeric parameter expected", "expression parameter expected" and so on.

But I would say that there's so many places where things aren't spelled out explicitly that you really would be opening the floodgates...

MarkMLl

[440bx]

This might be something which could benefit from being explicitly mentioned in the documentation:

I think that is something that _must_ be mentioned in the documentation.  Ignoring characters in what is not documented as a comment area is _not_ expected behavior in a compiler. 

You brought up a good example in {$ENDIF}, here how it's documented:

The {$ENDIF} directive ends the conditional compilation initiated by the last {$IFxxx} directive. Any text after the ENDIF keyword but before the closing brace is ignored:

{$ENDIF some ignored text}
is the same as

{$ENDIF}

any implicit "comment area" should most definitely be documented.  A programmer should never have to guess whether what he/she typed is honored by the compiler.  That should always be known without any doubts.

[MarkMLl]

Quite frankly, I'm through picking fights with the language custodians.

MarkMLl

[Thaddy]

Hello,

including a simple expression in $MINSTACKSIZE such as {$MINSTACKSIZE 7 * 1024 * 1024} causes its value to be set to 7 instead of 7,000,000 without a warning, note or any indication that the value used is nowhere near the value specified.

The documentation does not state whether or not an expression is valid but, when using one, the compiler doesn't complain giving the impression that using an expression is valid when it really is not.

This is documented behavior and not undocumented as suggested. Additional info after an {$ifdef}/{$else}/{$endif}, etc directive is completed ignored and treated as comment, not processed. So a calculation will be ignored too, even if with literals. Maybe you can work with {$if defined()}} or a macro. That has more possibilities. But equally that will also ignore extra info that needs processing. Again, ignored and not processed. It is simply treated ad verbatum.

Although I find the current feature already helpful, it would be nice if a calculation with literals would be allowed. Due to parsing complexity issues -none vs quite a lot extra - , I think it is not very likely this will be implemented though. But you can always try.

Suggestion:

Code: Pascal  [Select][+][-]

1. {$macro on}{$define size:=7*1024*1024}
2. {$minstacksize size}
3. program testme2;
4. begin
5.   writeln(size);
6. end.

That does work...since the macro interpreter can perform such calculations.
(But is also not without limitations)
Also, $MINSTACKSIZE is Windows specific and not cross platform.
And the calculation renders 7_340_032, of course (more exotics)

[ccrause]

Hello,

including a simple expression in $MINSTACKSIZE such as {$MINSTACKSIZE 7 * 1024 * 1024} causes its value to be set to 7 instead of 7,000,000 without a warning, note or any indication that the value used is nowhere near the value specified.

The documentation does not state whether or not an expression is valid but, when using one, the compiler doesn't complain giving the impression that using an expression is valid when it really is not.

Comments welcome.

From the documentation:

The {$MINSTACKSIZE} sets the minimum stack size for an executable on Windows-based systems. It needs an argument, the size (in bytes) of the stack. This must be a number larger than 1024.

No mention of an expression.

It would however be useful if the parser could generate a hint if a number argument is followed by text that is ignored. It seems like a reasonable assumption that a numeric expression would be valid in this context, so an indication to the contrary would be quite useful. I also thought that the original expression appear acceptable to the compiler.  Good catch!

[Thaddy]

- It is documented that extra info is treated as comment.
- The macro feature can help, as per demo above

Good luck to you both trying to do a feature request..
I will support it, though 

[ccrause]

- It is documented that extra info is treated as comment.

Reference? The only mention of ignoring text is for IFDEF/IFNDEF/ENDIF, this doesn't mean that it is also true for other directives. There is also no mention of ignoring text in the Introduction to compiler directives.

- The macro feature can help, as per demo above

Indeed, but not immediately obvious to the unwary why one needs the indirection of a macro 

Good luck to you both trying to do a feature request..
I will support it, though 

I also support this, but I don't have enough free time to pursue this right now.

[MarkMLl]

It would however be useful if the parser could generate a hint if a number argument is followed by text that is ignored. It seems like a reasonable assumption that a numeric expression would be valid in this context, so an indication to the contrary would be quite useful. I also thought that the original expression appear acceptable to the compiler.  Good catch!

As I see it, there's four existing possibilities:

* A pragma (e.g. $endif) takes no parameters, anything unexpected is ignored.

* A pragma (e.g. $ifdef) takes a single parameter, non-parenthesised and non-quoted, with the handling of anything that follows undefined.

* A pragma (e.g. $if) takes a (whitespace-separated) expression that evaluates to a boolean up to the close of the comment.

* A pragma (e.g. $define) takes everything  up to the close of the comment.

My preference would have been to add an explicit eval() for arithmetic expressions. However this (a) adds a fifth possibility and (b) is troubling if $define really does already evaluate a numeric expression as suggested by Thaddy.

The logical solution would be to add eval(), to require that both $if and $minstacksize etc. either took a single token or an eval(), and that $define reproduced the tokens that followed unchanged unless enclosed in an eval(), plus of course a way of escaping eval() so that $define output it unchanged.

That would, of course, be a breaking change to the $if pragma (which could be easily identified by the compiler). The devs have done far worse to us.

But as I've said: this is not my fight.

MarkMLl

[440bx]

At the very least, the fact that MINSTACKSIZE ignores everything past the first number it finds should be documented.

The fact that similar behavior is documented for _other_ directives is irrelevant.  A programmer who is looking at the MINSTACKSIZE documentation is not and should not be expected to read the documentation for all other directives in the off-chance that something about other directives also applies to it.  Expecting that is absurd.

It's not a fight, it's about completeness and accuracy. 

[Bart]

File a bugreport against the documentation (in the fpc documentation bugtracker).

Bart

[MarkMLl]

A programmer who is looking at the MINSTACKSIZE documentation is not and should not be expected to read the documentation for all other directives in the off-chance that something about other directives also applies to it.  Expecting that is absurd.

Fundamental question: is the documentation a PDF mimicking a paper manual to be read sequentially from start to end, or an indexed collection of "trails" with no implication that one reads (or retains) anything other than the current query?

I'm not entirely happy with either possibility there. But the last time I criticised anything in this area Thaddy chose to interpret it as an ad-hominem attack on MvC, so again: this isn't my fight.

MarkMLl

[Thaddy]

But the last time I criticised anything in this area Thaddy chose to interpret it as an ad-hominem attack on MvC, so again: this isn't my fight.

MarkMLl

And please note I will defend his Magnum Opus, which is much better than the rival(s)... It is a labour of love in his case and took over 25 years and counting to achieve such accuracy.

Omissions are often fixed within an hour.
Who else is working on that documentation apart from MvC?
NOBODY.
Which is actually something to be ashamed about. At least I am.

Mark, even you can not fault such effort.
The official documentation is exceptional but few realize that.

(And Mark, we should stop using Latin, we both know we know)