On Thu, 28 Feb 2008, SF Markus Elfring wrote: > > > Ntfs-3g is C code, not C++. > > It is easy in the C programming language to overlook error codes from > function > calls.
Not if you use a recent glibc which uses __attribute__((warn_unused_result)) and a recent gcc which turns on lots of unused value checking with -Wunused and you use -Wunused -Werror in the CFLAGS variable for building evertything. By compiling ntfs-3g with "-Wall -Wextra -Werror", I already came across this fchdir call. Because it is defined with __attribute__((warn_unused_result)), a cast to void does not silence this warning, I found this to be neccessay to turn it off: __attribute__((unused))int ignored_fchdir_status = I think that if ntfs-3g chooses not to ignore this return code, it needs to be carefull deciced what to do in this siutation. But I would like to ask you if you could follow this up with Miklos, the author of fuse. This code orignates from him. For ntfs-3g, it may be even better to to not enter a failure path if this fchdir fails, it really depends on how serious a failure on this fchdir is. In principle, you do not always want to stop ntfs-3g because some minor error occured: Filesystems should go to great lenghts (and ntfs-3g does so too) to not simply abort when an error occors but do the right thing, even if that means that the error is best ignored because the user is served better by continuning ntfs filesystem services instead of aborting which causes data loss if the user has unsafed data for the filesystem which you just aborted. > I imagine that there are more candidates for improved error and exception > handling in the source code. There might be, but ntfs-3g does not exactly have a bad reputation and neither has Skaza for his excellent and widely-used tool ntfsresize: http://en.wikipedia.org/wiki/Ntfsresize ntfsresize for example is used in __every__ Linux distribuition which I can think of which has support for this to shink NTFS partitions. And to my knowledge, there has never been any problem with ntfsresize so I rather disagree with your imagination here simply by using this as an example. If Szaka would not have given error handling very high priority ntfs-3g would not work as well as it does. If you want something changed, you have to provide your changes with good backup, which has to include a clear analysis that your change is really the right thing to do in this sitution. I didn'd see that so far for this fchdir change. Pointing at possible areas of possible improvements like the handling of this return value fchdir is easy (gcc does it automatically, so you do not even have to have human intelligence for it) but finding the right way to do handle it what separates your patch for it from a useful contribution, IMHO. If these things only were so easy as everyone would wish, doing software which you really have to be able to rely on would be easyer. BTW, I do not think that switching ntfs-3g to C++ is an option: ntfs-3g is used in embedded devices as well and I am not even sure if the companies which used them have fully-supported (cross) compiler toolchains for C++. You also have to be careful to not require additional big C++ libraries which are not standard in embedded systems. Embedded systems even use specially reduced libc versions like ulibc to mimimize size. Another consideration might be the possible future prospect of replacing the NTFS driver in the linux kernel with a futhre version of ntfs-3g. I would not bet that Linux kernel will not switch to C++ anytime soon and I would like to avoid any relious discussion like using C++ to use it's exception support. In my view, it's good that ntfs-3g is C, you can handle errors in C as well as in C++ and C certainly fits for the kernel and filesystems. These are just my two cent's and I'm not speaking for the ntfs-3g project here (which I am not a member), these are just my views. Bernhard ------------------------------------------------------------------------- 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
