ttmkfdir crashes when executing the following command: ttmkfdir -x 2 -e /usr/share/fonts/encodings/encodings.dir -o /usr/share/fonts/TTF/font.scale -d /usr/share/fonts/TTF/ Accidentally, I also figured, that it also crashes, when the argument given after the -d option is invalid - it would crash with a segfault. I've traced down the problem and attached a patch for it. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 38612 [details, diff] ttmkfdir-3.0.9 patch -Explicitly set the base with strtol -Give feedback whether directory exists
The other segfault has been amply covered in places such as bug #60470 and typically results from a bad encoding.
Please consider merging both patches. The reason why there was need for boundary-checking is, that the values don't get retreived properly, which is what my patch solves. Boundary-checking stops the crash, but doesn't guarantee that this does what it's supposed to. I would recommend as I said - merging both patches...
i applied this patch and the one from bug 60470 and after 2 recompiles of x forgot to remove the rm for the encodings first time... ^_^;; ttmkfdir works fine does what it should without blowing up i applyed the encoding patch first then this one after all the other patchs that ttmkfdir already has btw
Benjamin, This patch is really excellent, except for two changes: - int i1 = std::strtol (startptr, &endptr, 0); + int i1 = std::strtol (startptr, &endptr, 10); - int i2 = std::strtol (startptr, &endptr, 0); + int i2 = std::strtol (startptr, &endptr, 10); Simply changing the behavior of the code to be more strict about string to number conversion doesn't necessarily solve anything. I'm guessing that the bad encoding was being improperly interpreted as hex or octal resulting in out of range numbers for start_range and end_range. I believe the better way to solve this problem is to check start_range and end_range for proper boundaries, as is done in the second patch (patch for ttmkfdir, it now checks the bound, and we avoid segfault) from Bug 60470. Do you agree? As always, thank you for the contribution and we hope to merge it soon!
I know what you're pointing at... I'm not sure what I should respond. Currently, the strtol is broken. Adding boundary check for the loop sounds perfectly reasonable to me. But - you got it exactly right. The second strtol was actually broken - the first one was just fine. The second one, it hit a \0 (End of string). for some strange reason, it did not notice that. I'm not sure what you mean with bad encoding. But I think you guessed perfectly with hex/octal/decimal conversion. I don't know (and that's the important poart) whether there are hex or octal numbers to be converted. If so, then my solution is obviously broken and should not be taken. But if the encoding is always decimal, there is no reason not to use the more strict version. What do you think?
Just to be clear... I'm perfectly okay with removing that part. I just don't think it's the proper solution.
ttmkfdir-3.0.9-r2 has your fixes.