Warning on identifier usage ?

[Thaddy]

The problem isn't really rare.  The .h headers are peppered with conditionals to change a definition to account for a particular Windows version.

But that is what I already pointed out.

[Martin_fr]

The presence of "deprecated" is misleading.  That's what I really don't like about using "deprecated".

in the case of APIs, that's controlled by the Lazarus/FPC developers,

Well, yes, if it is in the RTL (or LCL) then the deprecated would be misleading indeed.

But that was the major part of my point. I really very strongly do not want such a hint/note/warning to be triggered by the RTL/LCL. Abso-f*-lutely not. (excuse my French)


At least, if someone does build their code, and does not explicitly state, that he needs to support minimum version ...., then it should be assumed that the person using that function wants to only support targets supporting that. Otherwise everyone will get those warnings, if they want to use newer features.

If you build with gtk-n or qt-n, then the compiler does not tell you either: "Your app will not run if those libs are not installed on the target".

In theory if there was a switch --build-target-min-version and the warning could be "require 'min version' 'message';" then it wouldn't bother me.
In reality it is not worth such an option. And even more important, such an option itself raises the need to explain to the user what it does to his app (nothing, but show hints, or give errors)

An IFDEF wouldn't work, since the RTL/LCL are pre-compiled, so the IFDEF already decided.

[440bx]

But that was the major part of my point. I really very strongly do not want such a hint/note/warning to be triggered by the RTL/LCL. Abso-f*-lutely not. (excuse my French)

I excuse your French but, imagine that by mistake VirtualAlloc2 is used in FPC's Windows version of the RTL, wouldn't it be great for the programmer who made that mistake to get a message stating that using that function requires Windows version xxxx or higher ?

That information would allow the programmer to fix the mistake immediately.  Of course, this example is too obvious to happen but, there are many more subtle cases where a message would definitely be extremely useful, e.g, when a constant value that is used only by a newer version of Windows is mistakenly used, that error will usually go unnoticed for some time.

Of course, the facility should be used with appropriate care so it does not become another "var must be initialized" thing.  Supposedly, that care would be applied by the Lazarus and FPC teams.

One place (among many) where such messages would be extremely useful is in the definitions associated with winsock.  Not even the C .h definitions are complete and correct when it comes to dependencies, e.g, ADDRINFOEX6 doesn't simply require Windows 10 as the .h header says, it requires Windows 10 build 22000 or above which I'm not sure if it is 21H1 or 21H2.  It would be really nice to know that stuff when using GetAddrInfoEx.   The definitions of ADDRINFOEXn all seem to require a different build of Windows and not even the .h headers are specific enough.  It takes trial and error and having multiple versions of Windows installed to figure out which structure can go with what version then, only the person who went through all the pain has the information and has no convenient means to provide the information to other programmers because, in the case of FPC, there is no facility to provide it.

To really make the situation more sad than it already is, the compiler already implements a facility that provides the messaging function, i.e, "deprecated", all that's needed are very minor changes to implement the same facility for something that simply isn't deprecated.

Your concern about getting a message that causes you to speak French can already happen using "deprecated".  It is as unlikely to happen with an equivalent as it does with what's already available.  You can be fairly confident you won't be practicing your French very often for that reason

[Martin_fr]

wouldn't it be great for the programmer who made that mistake to get a message stating that using that function requires Windows version xxxx or higher ?

Only, if we knew beforehand that the programmer wanted to support older versions.

Its simply weighing the 2 case against each other.
- The benefit for the case you describe
- The harm to everyone else, who also gets the new warning.

It would be ok, if there was an option "Check if my code is compatible with ..." => but that would not be part of the compilation. Probably would not need to be part of the compiler either.

Besides, adding those warnings might for some cause a flood of warnings, hiding other issues from them. And "well you can turn it off" is not an argument in this case.
I consider this a feature that should require explicit turning on. ("consider" = My opinion, not an argument for debate)

Your concern about getting a message that causes you to speak French can already happen using "deprecated".  It is as unlikely to happen with an equivalent as it does with what's already available.  You can be fairly confident you won't be practicing your French very often for that reason

Not remotely the same. All my statements above are about what would/should be for indented use-cases.  Non of my concerns is about abuse of any of those features.

If I get a deprecated message, I assume that the item will be removed in future, and I need to deal with it. (sure some deprecated feature lived a long time already, but still, they may come to an end).

If I would get a "requires win11" message, I would equally consider that to be the truth.

The difference is, that when I use TSomeClass.GonnaBeOutdated, it may not be outdated now, when I write the code. So I have no chance at this time to check and know this. I need to get the info when this will change.

When I use VirtualAlloc2 then I can check it at the time of using it. And its not likely to disappear from older Windows versions. (And if it did, how would the compiler know which update I target....)

[440bx]

It would be ok, if there was an option "Check if my code is compatible with ..." => but that would not be part of the compilation. Probably would not need to be part of the compiler either.

Then why aren't you complaining that there is no option to control "deprecated" ?

The point is, while those informational messages would be more common than those emitted due to deprecated functions, they would still be a small percentage of the total identifiers available (likely quite a bit less than 1%.)  That small percentage doesn't merit "special attention" but the consequences of using them do.

My question is: why isn't there an option to tell FPC to stop emitting messages about "var" not being initialized ??  That's incorrect.  It violates logic and the Pascal standard, yet FPC programmers  have to put up with it, like it or not.  Why aren't you complaining about that ?  That's something definitely valid to complain about.  Amazing how things that are _blatantly wrong_ endure.  That's something worth some choice French words.

Besides, adding those warnings might for some cause a flood of warnings, hiding other issues from them. And "well you can turn it off" is not an argument in this case.

The "var" thing already does that and no one is doing anything about it and, lo and behold, it has not caused you to speak French.    There is NO reason for the feature I'd like to see to create the same problem since the inclusion/exclusion of messages is controlled by the Lazarus and FPC teams, therefore the only way that problem can happen is with the "cooperation" of those two teams.

I consider this a feature that should require explicit turning on. ("consider" = My opinion, not an argument for debate)

I consider that very reasonable.  I have no problem with that.

When I use VirtualAlloc2 then I can check it at the time of using it. And its not likely to disappear from older Windows versions. (And if it did, how would the compiler know which update I target....)

The point isn't to inform the compiler, the point is to inform the programmer.  That's why I have stated time and again that the message is strictly informational.  It is not like in the C headers that its presence would cause the compiler to include or exclude something.  Nothing can be included or excluded without explicit programmer action which is ideally caused by having all the necessary information to make the decision.

There are thousands upon thousands of identifiers in the Windows API, programmers rarely check beforehand what version of Windows is required for the identifier to be valid.  In the case of FPC, they rely mostly on the FPC definitions, if it's not there many simply won't use it even if it is present since Win16.

The above said, not much chance of VirtualAlloc2 being used in an FPC program since it is not present in the current Windows definitions.

Now the question is: will VirtualAlloc2 be added to the definitions or is it going to remain undeclared to prevent programmers from using a function that requires Win 10 or later ?



@marco,

How about it marco ?  Are you going to include VirtualAlloc2 or is that function out of luck ?

[Martin_fr]

Well, yes all messages have cases when they need to be seen and when to be hidden.

I have simply stated my opinion on the new proposed message. I do not thing it should be compiler generated. And I explained why I see it as different from deprecated.

But even if it was compiler generated, I think it should be "opt in" (for the reasons given in its difference to deprecated, among others).

Yes, everyone will have there own favourite list of what should be opt-in and what opt-out.
On my list, this is a definite "opt in". Not to be seen, unless demanded. (like range checks need to be turned on / though they are much more useful, but that is off topic)


Also all messages can be toggled by command line opts. And I have used that for some, not for others.

But that is not the point. And it's also not the point if existing messages have the right opt-in/out, or should have been compiler or not...  Well, not stopping you from starting discussions on those. But I might not join any such discussion.

It's about the new one proposed. And to that I have said all that I have to say.

[marcov]

I don't entering tons of legacy OS info in headers is a good solution for the rare case that somebody is developing complicated new software that must run on unsupported Windows.

The problem isn't really rare.  The .h headers are peppered with conditionals to change a definition to account for a particular Windows version.

But calls that differ in supported versions of Windows are usually already quite specialised. Some new calls for console I/O in later win10.

Yes, of course there will be a handful of people in the world that make new software for win7 (rather than recompile), usually because of specialised cards (and more importantly, drivers). Maybe even XP, but new compatible hardware is getting very rare. Even Windows 10 will start to drop in the coming year.....

But as said, OS specific compiler extensions, the need extremely fine grained Windows unit modifications, finely grained configuration (selecting version to trigger warnings, and turn off in general), I don't see it happening for such limited use.

Or do you just want to maintain some patches for own use?

[440bx]

@Martin,

As I stated before, I feel giving the option to opt-in or opt-out, either way, to be perfectly fine.  I have no issue with that either way.

The point I want to reinforce is that, it is impossible for the feature to be abused without the assistance of the Lazarus and FPC teams, which I find extremely unlikely to happen.   Therefore, it should be all good, specifically, it is rather unlikely that the RTL would end up triggering one of those messages and if it does it would be nothing but helpful for the programmer who inadvertently included something that is too "fragile" to be part of the RTL.


@marco,

It's more complicated than that.  There are enumerations that are available all the way back to Win16 but, some of them include identifiers that can only be used (and recognized) by Windows versions as late as Win 10 21H2.  A similar problem also occurs with structure definitions. It is currently too easy to inadvertently use one of those identifiers because even the C headers will allow some of the values in inappropriate cases.  FPC has no safeguards of any kind against that.

As far as developing new software, some programmers (and companies) like to make their software compatible with older Windows versions if doing so is reasonably easy.  Personally, I have not found a function in Win8, 8.1 and 10 that does something I cannot fairly easily implement using Win 7 API functions.  IOW, I find it rather simple to make software that is compatible with Win 7 and given that not everyone in the world is running Win 10 (much less Win 11 which is not exactly well accepted), being able to produce a program that does not require an inadvertently unexpected version of Windows is something that is definitely convenient and nice to have.


There are two reasons I won't use "deprecated" to emit the informational message I'd like to output.

1. It is incorrect since the message is not about something that is deprecated.
2. It would cause genuinely deprecated facilities to be mixed with non-deprecated ones, causing the deprecated ones to no longer be identifiable (since they are mixed with non-deprecated ones.)

Anyway, the answer to my original question is: no there is currently no way to do that and, the possibility of having one in the future doesn't look very good.  oh well...

[Khrys]

How about a "sibling" directive to  deprecated  that essentially works the same, but can be seperately toggled on/off and allows for more concise warnings (advice)?

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

1. program Test;
2.  
3. procedure BogoSort(); advice 'NEVER USE IN PRODUCTION CODE';
4. begin
5.   // (bad code)
6. end;
7.  
8. begin
9.  
10.   BogoSort(); // #1
11.  
12.   {$push}
13.   {$warn symbol_advice off}
14.   BogoSort(); // Silenced
15.   {$pop}
16.  
17.   BogoSort(); // #2
18.  
19. end.

Code: Text  [Select][+][-]

1. Free Pascal Compiler version 3.3.1 [2025/03/28] for x86_64
2. Copyright (c) 1993-2025 by Florian Klaempfl and others
3. Target OS: Linux for x86-64
4. Compiling test.pas
5. test.pas(10,3) Warning: Symbol "BogoSort": "NEVER USE IN PRODUCTION CODE"
6. test.pas(17,3) Warning: Symbol "BogoSort": "NEVER USE IN PRODUCTION CODE"
7. Linking test
8. 18 lines compiled, 0.3 sec, 146528 bytes code, 62208 bytes data
9. 2 warning(s) issued

Those who are interested can apply the attached patch onto  f8f54dcbcfa27eafd4fa8593601c692e1bb1a13e   

[440bx]

@Khrys,

Personally, I find your implementation to be rather nice.  I like the use of the word "advice", it's quite appropriate.