> The former generates somewhat smaller text segments, I would like to get more details about the dependencies. I imagine that this coding style would mean that a pointer should be allocated additional to the string literal. I am unsure if it will be optimised away by the compiler or linker. So it might make a noticeable difference in generated object code if an array specification is used.
> so the otherwise expensive context switches (which is the biggest bottleneck > during metadata operations and on low-end CPUs, especially on ARM where > a 50x context switch speedup wasn't accepted into the mainline kernel) > could be cheaper due to less TLB misses. Do you refer to an other discussion on the Linux mailing list here? > 1. abort() should never be used. I have got the opposite opinion. It might be the only valid reaction for specific or unexpected program conditions. > And for instance a temporary OOM can't justify a total system crash. Would you like to work with "std::bad_alloc" exceptions? > 2. fprintf() failures are typically never a fatal error. I suggest to avoid unchecked function calls. Would you like to detect every error situation as early as possible? > However in all the cases you fixed the return value can be safely ignored > since it's irrelevant in the given contexts. I recommend to be more careful with "ignorance" in source files. Unexpected behaviour will not be detected in corner cases if "too much" error codes are ignored. > Failure to raise the privilege is not fatal here and things > could still work fine unprivileged. Why is the instruction used at all if you do not want to be completely sure that this function call succeeded? Do you imagine that a log message about a failure might be enough in this use case? Regards, Markus ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
