TI83F header comment cutoff? about tilp_and_gfm HOT 10 OPEN

https://github.com/debrouxl/tilibs/blob/54ad18eaac9f2b7e52fda284acb2729f06bf18c4/libtifiles/trunk/src/comments.cc#L83

Probably a date string formatter somewhere

from tilp_and_gfm.

Indeed, the header comment can only be 42 bytes long. At the very least, the "dated " part should go away, which would save 6 bytes, but yeah, additionally, switching to one of the ISO8601 date formats in the direct or indirect clients of tifiles_comment_set_single_sn() can be done.

from tilp_and_gfm.

(This issue should probably be moved to tilibs)

Is it using localtime? I did a very quick search but I'm not sure where the time comment is actually being written. (Also, why are the files all C++ when the code looks exactly like C code? If it really is for a future port to C++, then I would say that energy should be spent on fixing some code smells)

from tilp_and_gfm.

• the main callers of tifiles_comment_set_single_sn(), which is the modern version of tifiles_comment_set_single(), are in libticalcs. I'll move this issue to tilibs later, even if there's a caller in GFM as well;
• the time comment is written by tifiles_comment_set_sn(), at the beginning of the file you linked;
• the files in tilibs are indeed C-like code compiled as C++ (well, except for the iconv... thing in libticonv), in order to benefit from the stricter typing of C++, at first. No plans for a full-blown port to C++;
• I've already fixed a number of code smells, in that very file and others (adding bounded versions of a number of APIs, removing many occurrences of TRYF & TRYC macros containing return, etc.), but I'm always all ears for suggestions :)

from tilp_and_gfm.

Oh my suspicion was right, it was using the obsolete and accursed ctime.

I can try to assist with cleaning up code, though admittedly I have no familiarity with the codebase and I may end up doing more harm than good (maybe I will lose interest in my calculator in a month)

from tilp_and_gfm.

What would you like to clean up ? I wouldn't want to restrain you, but it makes sense to avoid work duplication or collisions generating patch conflicts :)

Note that the experimental2 branch contains more cleanups and improvements, so that's where the work ought to happen. experimental3 doesn't work well for the time being.

from tilp_and_gfm.

from tilp_and_gfm.

from tilp_and_gfm.

Indeed :)
Sources of magic numbers include outsized buffers (e.g. 64 bytes for a 42-byte comment) and size bounds for a number of file types. Are these the ones which bother you ?

from tilp_and_gfm.

Yes. In fact there is enough room to even put the TILP / tilib version as a comment. Not sure if that is useful.

from tilp_and_gfm.