This is crazy.
People are actually advocating that thousands upon thousands of applications
need to be changed.
Yes, POSIX allows this particular idiotic behaviour. So what? It probably also
allows free() to do nothing, yet no-one in their right mind would want that. Or
maybe you would be upset if the code fragment
const char *s = "x";
int i = (s+1)-s;
formatted your hard drive. Yes, the C standard really does allow that
to happen.
(C99 section 6.5.6 #9, if you really want the details.) I don't
know about you,
but I would return the compiler with a big "Broken!" label if that happened.
The mere fact that a standard allows an idiotic implementation doesn't mean
we should play ball with it. The same standard also allows sane
implementations.
We could litter fsync() calls all over, but...
1. It describes a semantic that isn't really what we want. In fact,
there is no way
to get exactly the semantics we want with POSIX. We have to ask for the
please-wait-for-the-disk semantics we don't want. That's a sure
way of getting
sluggish programs.
2. Shell scripts, Makefiles, and other languages without explicit
fsync control will
kill really you. Instead of...
foo <file >file.new
mv file.new file
...you get to write...
foo <file >file.new
sync
mv file.new file
Performance might be affected.
3. Auditing and changing thousands of programs? Expect bugs.
We already break the strict letter of POSIX and the C standard in
fifty different ways.
If someone shows up with an environment that doesn't behave as we want, we
say "sorry, no ball". Just add stupid file systems to the list.
Morten
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
