[Pawn] YSI INI_Load and Command_ReProcess const correctness

[Jarnokai]

Hi, I have asked about this same problem about a year ago but got no answers.

Yesterday I decided to check back on my script and found the same issue still presists, so I ask now:



I use the y_commands function "Command_ReProcess" to call commands from the script, as in "to fake commands". This means that when a player does something, I might call the command "/quitrace" for example, to make sure the player's actions don't interfere with the ongoing race they are participating.



I can no longer pass literal strings into this function, as the compiler comes up with warnings. How can I keep using the function like this while keeping the warnings away? Or am I misusing the function in some way?



Another, seemingly obvious (to me) false positive comes from using INI_Load with a pre-determined file - I load my server's saved information from a file with a static filename in the server files, but now by passing a literal string as the filename I get const correctness errors.



Any ideas to fix this?





I used sampctl ensure to check that all dependencies are at their newest version, but maybe I am doing something wrong. I never really had time to learn to use sampctl.

[Jarnokai]

Tuns out the problem with y_ini had been already fixed, my sampctl just wouldn't update YSI no matter how many ensures and other trickery I did. Command_ReProcess however has been discussed in this pull request: https://github.com/pawn-lang/YSI-Includes/pull/489

I quote Y_Less:

So the other advantage of the current error is that it makes the wrong thing harder to do. This:

Code:

Command_ReProcess(playerid, "/help");

Will give a warning, which is good, because you should never be calling commands like that. If you have some common code you want to call from multiple places, you put that in a separate function and call it from multiple places. Calling another command to do something is never the correct solution when you know the exact command. Command_ReProcess is for calling commands indirectly by name, for cases like /help <command> where you don't know the command name in advance, hence it will already be coming from a variable. If you know the command name at compile-time, you should just be calling a normal function normally, avoid all the overhead of string-based lookups and indirection.

TL:DR INI_Load no longer causes these issues, using Command_ReProcess in this way is not good practice.



I have since adapted my code around this issue by following Y_Less's advice and created functions out of commonly needed commands.