On Thu, 28 Feb 2008, SF Markus Elfring wrote:
> > 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.
See objdump(1), size(1), etc.
> > 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?
No, I don't have time to read mailing lists.
> > 1. abort() should never be used.
>
> I have got the opposite opinion.
abort() must not be used in ntfs-3g. I didn't mean you shouldn't use it
anywhere.
> > And for instance a temporary OOM can't justify a total system crash.
>
> Would you like to work with "std::bad_alloc" exceptions?
Ntfs-3g is C code, not C++.
> > 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?
Of course not when it's irrelevant.
> > 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.
There is no ignorance and unexpected behavior. The outcome is the same
independently of the result.
> > 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?
It's forward compatibility when the kernel will support unprivileged mount,
probably in 4-8 months.
> Do you imagine that a log message about a failure might be enough in this use
> case?
No, that could be misleading and redundant.
Szaka
-------------------------------------------------------------------------
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
