Free42 state file switching, export, and import

[Thomas Okken]

(08-18-2019 12:45 PM)SammysHP Wrote:  Regarding the warning: An unknown -Wno-* option should not produce an error.

https://gcc.gnu.org/wiki/FAQ#wnowarning Wrote:Since GCC 4.4, and as explained in the GCC manual: when an unrecognized warning option is requested (-Wunknown-warning), GCC emits a diagnostic stating that the option is not recognized. However, if the -Wno- form is used, the behavior is slightly different: no diagnostic is produced for -Wno-unknown-warning unless other diagnostics are being produced. This allows the use of new -Wno- options with old compilers, but if something goes wrong, the compiler warns that an unrecognized option is present.

Sweet! I did not know that. Even my Ubuntu 12.04 build VM has a sufficiently recent gcc for that (4.6.3 -- whew).
It doesn't mind the redundant -lX11, either. OK, I'll clean up those two things in the Makefile (and fix the indentation where appropriate).

(08-18-2019 12:45 PM)SammysHP Wrote:  

(08-18-2019 11:37 AM)Thomas Okken Wrote:  I don't think it's an issue in practice, because who actually uses directories nested that deep and filenames that long that you end up with absolute paths of more than 255 characters? My main reason for using snprintf is that in the unlikely event of such extremely long paths occurring, the code would at least fail gracefully rather than crash.

Here I like to disagree. First, "who actually…" caused a lot of trouble in computer history.

Sure, but consider the specific situation at hand. Free42 is not a backup daemon that traverses entire filesystems and thus would absolutely have to be able to handle long paths. Free42 is an interactive program, and all the files it deals with are in $HOME/.free42 or in whatever directory the user specifically chooses. Honestly, who is going to exceed 255 characters that way?

(08-18-2019 12:45 PM)SammysHP Wrote:  Second, you know that this part of the source does not work with valid input in some circumstances, but you ignore it. You don't even check the return value of snprintf(). The code silently fails and (hopefully) an error is produced at different place (when the program tries to read the file). Such long paths are unlikely, but allowed.
In the end this is not a big issue that can cause all kinds of problems (except that loading of the file might fail sometimes), it is just not clean code which could have been avoided.

As I said before, the rationale for using snprintf is to avoid crashes, not to make sure extremely long paths actually work. The Windows version doesn't even use snprintf, because it's not provided in Visual C++, at least not the versions I've used. The better is always the enemy of the good, and I'd rather have a program that can be made to malfunction or even crash when trying to use it in extremely remote corners of the filesystem, than not have the program at all.