Hi, On 05/11/2014 19:48, Antonio Diaz Diaz wrote: > Hello Felix,
Just for the record: > There are two kinds of platform-specific code that people want to add to > ddrescue; code that compensates shortcomings in the POSIX implementation > of a given OS, and code that provides functionality beyond POSIX. > > Of the first kind I am only willing to accept trivial additions, like > the one for O_BINARY: > > #ifndef O_BINARY > #define O_BINARY 0 > #endif > > Haiku, for example, has chosen to be compatible with BeOS at both the > source and binary level, allowing software written and compiled for BeOS > to be compiled and run without modification on Haiku. Therefore the only So far it didn't prevent us to add enough POSIX to port all the things we needed. The only thing that can cause trouble is the very bad (and linux-only, it seems BSD never went this ugly) habit of doing "return -EFOO", which of course will end up quite bad in Haiku since as with BeOS we use negative error codes. This violates both POSIX and ANSI C, but well, it's not like POSIX made up their mind right in the first place (I recall at least one place where they had "non-zero" and then changed to "positive" about errno). Using such things as return -EFOO is both ugly and highly error-prone anyway, I've ported way too many things to Haiku to be proven wrong on that. :p POSIX should have been made with negative errors in the first place but well. > ways for ddrescue to run on Haiku are: > > a) Haiku implements properly the parts of POSIX that ddrescue needs. > b) Haiku maintains its own port of ddrescue, as it does with GCC[1]. We do intend to upstream gcc someday. Unlike BeOS, for which patches were rejected by redhat people (officially because of a hack to zero-out things when seeking beyond the file end, but likely also because well, who cares about !Linux), we fixed most shortcomings BeOS had. > It is not my fault that OS development has happened in total chaos (just > like most human enterprises). Well, it's not like POSIX itself isn't messy in some places, cf. above. > About the second kind of code additions (providing functionality beyond > POSIX), mi intention is to implement each feature just once, in the way > that is best and most probable to be eventualy included in POSIX (by > default the one working on GNU/Linux). "best" of course is point-of-view-dependant... but I digress. There are several things I could list on Linux that are neither the best nor the first to be implemented. :D One way to deal with platform discrepancies, which are bound to happen anyway if you claim portability, and since you use C++, is to have a Platform class that can be subclassed to override default (POSIX or stub) behavior... See BZFlag for a (probably overengineered) example: http://sourceforge.net/p/bzflag/code/HEAD/tree/trunk/bzflag/src/platform/ I'm sending a revised patch separately with only the device_id() since I added support for lseek(SEEK_END) on devices in Haiku. I'll leave the Platform class as a 3rd party opportunity :D François. _______________________________________________ Bug-ddrescue mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-ddrescue
