[physfs] PHYSFS_stat/HG & Numerical Errorcode

Ryan C. Gordon icculus at icculus.org
Thu Mar 18 15:59:57 EDT 2010

> As you take this work so lightly could you please take a look at my
> ErrorCode branch and tell me if you like the idea? It's a work in
> progress and i've made a few new files so i have a clearer work area,
> they can be merged later.

Here are my thoughts:

I sort of want to ditch the language stuff. Localization has been a 
giant hassle, and I don't know that I really want to formalize it into 
the API.

My counter-proposal:
- PhysicsFS will report error codes as enums. Your work here is 
basically what I'm looking for, I think.
- PHYSFS_getLastError() has always claimed that you can't trust the 
strings it supplies (in that they aren't machine-readable, they can 
change without warning, and they might be in any human language anyhow). 
I think we should deprecate this function. It will remain but only 
supply english (or perhaps just stringified error codes, like 
"ERR_OUT_OF_MEMORY"). The theory is that those that care can hook this 
up to their app's localization routines, and these strings will be 
consistent for translating, if they like.
- Things that currently generate a dynamic error message (like 
win32strerror() or zlib_error_string) will be changed to use some 
generic, static error code (a generic "operating system error" or 
whatever makes sense, if it's not reasonable to obtain a more 
informative error message for a given operation).

The original thinking behind PHYSFS_getLastError() is that all errors 
are basically fatal, so you should dump the error message to stdout and 
quit, and let the user sort it out...this isn't a robust approach, so 
cleaning this up is a good idea.


More information about the physfs mailing list