3/24/2023 0 Comments Gnucash backupFor the most part, this is fairly trivial to do. I am currently looking at removing all of the pointer arithmetics from this function. The error is just too critical to rely on "only" one test if we know several sane tests instead. But I can clearly see how anyone might change the other parts, overlooking any dangerous condition which might then still be caught by your test. I would not remove your test even though it appears redundant *at this point in time*. > The alternative would be of course to simply go with the pointer arithmetics The test is completely non-critical compared to the actual loading of a file. > too much negative impact on performance ? > family of routines without any pointer arithmetic. > the future ? I guess the required tests could all be done with the g_str* > Would it make sense to replace the pointer logic altogether by string logic in But seeing how tricky pointer arithmetic can be, I'm not too in favour of that. The alternative would be of course to simply go with the pointer arithmetics only and remove my now redundant test. Or would such change have too much negative impact on performance ? Would it make sense to replace the pointer logic altogether by string logic in the future ? I guess the required tests could all be done with the g_str* family of routines without any pointer arithmetic. That was the only reason I could think of as well. > enough to use pointer arithmetic without bugs".) > pointer arithmetic are a nuisance, even though I would have thought "I'm clever > propose to add the patch into trunk as well. > wording already implies, we better add that check explicitly. > your addition, this invariant shouldn't be violated now anymore, but as this > patch), and I think this part should be applied to trunk as well. The patch here added one such invariant ("(len > pathlen)" in the > this problem should be guarded with the assumed invariants as closely as > think the pointer arithmetic ("name + len" currently) which was the source of > Indeed the error scenario should be caught by your addition. The data/log file rollover code in Gnucash itself rather than anything else. In any other regard, wasn't shut down uncleanly, etc., so I currently suspect I can only say that my system hasn't been behaving unusually I appreciate that this will be hard to track down. Rather than the more-recent file, which was What is strange is that the log entries I needed to replay were in that file, Weirdly, this file only contained transactions up to. (~/Documents/gnucash) it is no longer there. and sure enough, if I go to the directory it is supposed to be in, I have twice recently launched gnucash to have it tell me that my data file is
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |