Compiler: {$INCLUDE %DATE%} turns on IO Checking? lazarus / 21-General ---------------------------------------------------------------------- AlanTheBeast · 2022-07-02 18:54 Hope nobody has tried to test my earlier assertion.  Editing goofs led me down a path.... I have a section of code set to {$I-} as I check IOResult. I added the line:       S := {$INCLUDE %DATE%}+'::'+{$INCLUDE %TIME%}; to be able to print out the program compiled date/time. And IOChecking is turned on again! (Added {$I-} after the above to mitigate, but this seems like a doozy of an error in the compiler...?) FPC: Free Pascal Compiler version 3.2.0 [2020/05/31] for x86_64 ---------------------------------------------------------------------- MarkMLl · 2022-07-02 20:03 I've not seen that but I usually put them in constants first, like 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 CONST   manifestDate= (*$I %DATE% *) ;        manifestTime= (*$I %TIME% *) ;  MarkMLl ---------------------------------------------------------------------- AlanTheBeast · 2022-07-02 20:22 Good idea. I'll implement it that way. But - I was wrong about my earlier assertion of it the $INCLUDE causing IO checking to be turned on ---------------------------------------------------------------------- MarkMLl · 2022-07-02 20:50 Yes, but /why/? What had happened? It does raise the interesting question about whether the state of any particular setting can be checked: ISTR that there is an IFOPT for some but not all, and $I is sufficiently overloaded that it could be problematic. MarkMLl ---------------------------------------------------------------------- AlanTheBeast · 2022-07-02 22:11 Quote from: MarkMLl on July 02, 2022, 10:50:24 pmYes, but /why/? What had happened? I was changing some of the top of the file options and testing LOOPUNROLL for S&G (looking at the generated assembler - it is, in some instances, well worth it).  At some point I clobbered the existing {$I-} w/o realizing it. Quote from: MarkMLl on July 02, 2022, 10:50:24 pmIt does raise the interesting question about whether the state of any particular setting can be checked: ISTR that there is an IFOPT for some but not all, and $I is sufficiently overloaded that it could be problematic. I personally wouldn't be offended if all pragmas were in long form only from some point in the compiler evolution.  Force everyone to update their code too (or have a competition to write the best auto-fixer). It is now officially beer time.  G'night. ---------------------------------------------------------------------- PascalDragon · 2022-07-03 12:25 Quote from: AlanTheBeast on July 03, 2022, 12:11:53 amQuote from: MarkMLl on July 02, 2022, 10:50:24 pmIt does raise the interesting question about whether the state of any particular setting can be checked: ISTR that there is an IFOPT for some but not all, and $I is sufficiently overloaded that it could be problematic. I personally wouldn't be offended if all pragmas were in long form only from some point in the compiler evolution.  Force everyone to update their code too (or have a competition to write the best auto-fixer). First of they aren't called pragmas, they're compiler directives (or simply directives). Second new directives don't receive a single letter directive except where required by compatibility with other compilers. Third existing directives will not be changed, except to fix bugs. Thus the overloading of $I will stay. ---------------------------------------------------------------------- AlanTheBeast · 2022-07-03 13:22 Quote from: PascalDragon on July 03, 2022, 02:25:51 pmQuote from: AlanTheBeast on July 03, 2022, 12:11:53 amQuote from: MarkMLl on July 02, 2022, 10:50:24 pmIt does raise the interesting question about whether the state of any particular setting can be checked: ISTR that there is an IFOPT for some but not all, and $I is sufficiently overloaded that it could be problematic. I personally wouldn't be offended if all pragmas were in long form only from some point in the compiler evolution.  Force everyone to update their code too (or have a competition to write the best auto-fixer). First of they aren't called pragmas, they're compiler directives (or simply directives). Second new directives don't receive a single letter directive except where required by compatibility with other compilers. Third existing directives will not be changed, except to fix bugs. Thus the overloading of $I will stay. 1. Pardon me. 2. Good and exceptional pity. 3. Pitier. ---------------------------------------------------------------------- MarkMLl · 2022-07-03 13:35 Frankly I have nothing against the use of /pragma/ in the context of ALGOL-derived languages, particularly in cases discussing multiple implementations and portability. Provided, of course, that they are correctly pluralised as /pragmata/ :-) MarkMLl ---------------------------------------------------------------------- Thaddy · 2022-07-03 14:53 πράγμα and it it is just shorthand. ---------------------------------------------------------------------- MarkMLl · 2022-07-03 15:34 It's Greek to me :-) MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-07-04 11:47 Quote from: MarkMLl on July 03, 2022, 03:35:52 pmFrankly I have nothing against the use of /pragma/ in the context of ALGOL-derived languages, particularly in cases discussing multiple implementations and portability. We should use the same terminology as the documentation and there they are named directives.