$MINSTACKSIZE unexpected behavior without warning lazarus / 67-Windows ---------------------------------------------------------------------- 440bx · 2024-02-17 11:12 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 · 2024-02-17 11:29 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 · 2024-02-17 11:41 Quote from: MarkMLl on February 17, 2024, 12:29:19 pmBut 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 · 2024-02-17 11:54 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 · 2024-02-17 16:05 Quote from: MarkMLl on February 17, 2024, 12:54:06 pmThis 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:QuoteThe {$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 · 2024-02-17 18:27 Quite frankly, I'm through picking fights with the language custodians. MarkMLl ---------------------------------------------------------------------- Thaddy · 2024-02-17 19:26 Quote from: 440bx on February 17, 2024, 12:12:29 pmHello, 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$macro on}{$define size:=7*1024*1024}{$minstacksize size}program testme2;begin  writeln(size);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 · 2024-02-17 20:07 Quote from: 440bx on February 17, 2024, 12:12:29 pmHello, 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: QuoteThe {$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 · 2024-02-17 20:11 - 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 · 2024-02-17 20:37 Quote from: Thaddy on February 17, 2024, 09:11:57 pm- 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. Quote- 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  QuoteGood 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 · 2024-02-17 20:51 Quote from: ccrause on February 17, 2024, 09:07:47 pmIt 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 · 2024-02-17 22:27 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 · 2024-02-17 22:37 File a bugreport against the documentation (in the fpc documentation bugtracker). Bart ---------------------------------------------------------------------- MarkMLl · 2024-02-17 23:00 Quote from: 440bx on February 17, 2024, 11:27:58 pmA 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 · 2024-02-17 23:05 Quote from: MarkMLl on February 18, 2024, 12:00:32 am 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) ---------------------------------------------------------------------- 440bx · 2024-02-17 23:20 Quote from: Bart on February 17, 2024, 11:37:30 pmFile a bugreport against the documentation (in the fpc documentation bugtracker). Bart I filed a bugreport but, honestly I have no idea where Gitlab chose to put it.  I tried to find the bug report immediately after creating it and couldn't.   This is more likely to be a result of my being a gitlab ignorant than anything else. ---------------------------------------------------------------------- dsiders · 2024-02-17 23:52 Quote from: 440bx on February 18, 2024, 12:20:18 amQuote from: Bart on February 17, 2024, 11:37:30 pmFile a bugreport against the documentation (in the fpc documentation bugtracker). Bart I filed a bugreport but, honestly I have no idea where Gitlab chose to put it.  I tried to find the bug report immediately after creating it and couldn't.   This is more likely to be a result of my being a gitlab ignorant than anything else. And what roughly was the title you gave it? ---------------------------------------------------------------------- Thaddy · 2024-02-17 23:56 Quote from: 440bx on February 18, 2024, 12:20:18 amQuote from: Bart on February 17, 2024, 11:37:30 pmFile a bugreport against the documentation (in the fpc documentation bugtracker). Bart I filed a bugreport but, honestly I have no idea where Gitlab chose to put it.  I tried to find the bug report immediately after creating it and couldn't.   This is more likely to be a result of my being a gitlab ignorant than anything else. No there is a problem. I can not submit anything either. Well, I can submit but not find it. (which on the forum is sometimes correct, but my behaviour on the bug tracker is very different) This is max 48 hours as far as I can tell. No clue. ---------------------------------------------------------------------- 440bx · 2024-02-18 01:17 Quote from: dsiders on February 18, 2024, 12:52:58 amAnd what roughly was the title you gave it? I don't remember the exact wording but, I do remember that the word "MINSTACKSIZE" is in the title.  That would normally be enough to find it (at least I think so.) ---------------------------------------------------------------------- dsiders · 2024-02-18 01:21 Quote from: 440bx on February 18, 2024, 02:17:55 amQuote from: dsiders on February 18, 2024, 12:52:58 amAnd what roughly was the title you gave it? I don't remember the exact wording but, I do remember that the word "MINSTACKSIZE" is in the title.  That would normally be enough to find it (at least I think so.) I found it in the FPC Source issue tracker: https://gitlab.com/freepascal.org/fpc/source/-/issues/40649 ---------------------------------------------------------------------- 440bx · 2024-02-18 02:00 Quote from: dsiders on February 18, 2024, 02:21:41 amI found it in the FPC Source issue tracker: https://gitlab.com/freepascal.org/fpc/source/-/issues/40649 Thank you. I find the "resolution" to be rather poor but, that is a different issue. Thank you again for taking the time to find it and posting a link to it.  I appreciate it. ---------------------------------------------------------------------- MarkMLl · 2024-02-18 08:06 Quote from: Thaddy on February 18, 2024, 12:05:07 amMark, even you can not fault such effort. The official documentation is exceptional but few realize that. The manuals are exceptional. The stuff which is machine-generated from the RTL etc. is far from it. MarkMLl