| |||||||||||||
Optimizations and undefined behaviorOptimizations and undefined behaviorPosted Jul 22, 2009 3:28 UTC (Wed) by BrucePerens (guest, #2510)In reply to: Optimizations and undefined behavior by mjg59 Parent article: Fun with NULL pointers, part 1 Sigh. Good developers are still going to do create temp, write, fsync file, link to permanent name, unlink temp. Fsync on the directory, though, shouldn't be necessary.
(Log in to post comments)
Optimizations and undefined behavior Posted Jul 22, 2009 4:16 UTC (Wed) by mjg59 (subscriber, #23239) [Link]
Good developers aren't going to have to - good operating systems will provide guarantees above and beyond POSIX. Operating systems that don't will end up poorly supported and gradually become irrelevant.
Optimizations and undefined behavior Posted Jul 23, 2009 5:07 UTC (Thu) by johnflux (subscriber, #58833) [Link]
I hope not. Good developers will realize that fsync is a complete overkill there. They don't need wait for the changes to actually be made to disk before continuing - they only need to make sure that the changes happen in the right order.
Optimizations and undefined behavior Posted Jul 30, 2009 13:38 UTC (Thu) by forthy (guest, #1525) [Link] The problem with fsync() is that it's semantics resemble whery much the one of "PLEASE" in INTERCAL, which means it is a joke. fsync() basically has no semantics, except "make it so" (make it persistent now). Now, all file system operations are persistent, anyway, just not made persistent now. You can't properly test (that is: automated), because to test if there's a missing fsync(), you have to force an unexpected reboot, and then check if there's any missing data. What's worse: A number of popular Unix programming languages don't even have fsync(), starting with all kinds of shell scripts. fsync() is a dirty hack introduced into Unix because of broken (but extremely fast) file system implementations. We know that Unix is a joke for quite some time, but parts of the API like fsync() show that this is not so far away from the truth ;-). From the kernel development side it is always "easier" to maintain a sloppy specification and blame the loser, but that's the wrong thinking. You are providing a service. Same thing for GCC: Compiler writers provide a service. Using a sloppy specification for questionable "optimizations" is wrong, as well. If the compiler writer can't know that the code really will break when accessing the NULL pointer, then he can't take the test out after having accessed an object. I remember GCC taking out tests like if(x+n>x), because overflows are said to be unspecified in the C language, but compiling code to a machine where overflows were very specifically handled as wraparounds in two's complement representation. This is all wrong thinking.
Optimizations and undefined behavior Posted Jul 30, 2009 15:04 UTC (Thu) by foom (subscriber, #14868) [Link]
> I remember GCC taking out tests like if(x+n>x)
Still does. You can use -fwrapv if you want to tell it that you want signed number overflow to be
Optimizations and undefined behavior Posted Jul 30, 2009 21:31 UTC (Thu) by nix (subscriber, #2304) [Link]
fsync(), brought to you by the same people who thought up 'volatile',
another equally impossible-to-define-except-by-reference-to-implementation feature.
|
|||||||||||||