Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

print format string on error/warning #4

Open
maddinat0r opened this issue Jun 16, 2016 · 3 comments
Open

print format string on error/warning #4

maddinat0r opened this issue Jun 16, 2016 · 3 comments
Assignees

Comments

@maddinat0r
Copy link
Collaborator

Like it has been written here.
Adding a whole OnError callback would be overkill though.
Hell, I could even use my log library to log that stuff (however that's probably overkill too).

@maddinat0r maddinat0r self-assigned this Jun 16, 2016
@maddinat0r
Copy link
Collaborator Author

Printing the format string will very likely only help in cases where the format string is long and complicated, e. g. distinguishable/unique. Most sscanf calls are likely to have only a few format specifiers.
I'll use my log-core library for that when it's ready, as it reports at which line exactly a faulty sscanf call is.

@NexiusTailer
Copy link

NexiusTailer commented Jun 20, 2020

I'll use my log-core library for that when it's ready, as it reports at which line exactly a faulty sscanf call is.

That exactly what is needed to do now when log-core is done. Do you still maintain this and have an opportunity to finally add this functionality of logging a specific line from pawn script on which sscanf is faced with a problem? This is still very relevant and several people asked me to create a similar issue here, but it seems you did it much earlier 😄

@Y-Less
Copy link
Owner

Y-Less commented Mar 28, 2022

OnError (or OnSSCANFError is an option. The other option is the true (secret hidden) meaning of the sscanf return values. 0 has always meant "no error", but in the first pawn version of sscanf any other value returned was actually the index (+ 1) of the specifier that caused the error. I should re-introduce that feature.

I also have file and line information on errors now, so when you do get an error you can at least read more detailed information in the console on where it came from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants