"Alex Riesen" <raa.lkml@xxxxxxxxx> wrote: > On 6/27/07, Jim Meyering <jim@xxxxxxxxxxxx> wrote: >> "Alex Riesen" <raa.lkml@xxxxxxxxx> wrote: >> >> > On 6/27/07, Jim Meyering <jim@xxxxxxxxxxxx> wrote: >> >> "Alex Riesen" <raa.lkml@xxxxxxxxx> wrote: >> >> > Check if this works in some exotic but common >> >> > environments (like MacOSX, Cygwin or HP-UX). >> >> >> >> What do you mean? >> >> I know that dup and fdopen work in those environments. >> > >> > Exactly as you described? >> >> No, but why does that matter? > > Your code will need additional tweaking on this > systems. Why bother? The only undesirable side effect you'd see on a buggy system would be a meaningless strerror(errno) in that very unusual error situation: when git-format-patch (without --stdout) runs out of file descriptors or memory. >> > Are you sure fdopen on Cygwin >> > sets ENOMEM? >> >> Are you suggesting not to use errno because >> it won't contain useful information on Mingw32? > > Yes. Mingw32 is just one example. > >> >> It's ok, but for the fact that when dup fails, all you get >> >> is the uninformative EINVAL from fdopen. >> > >> > EBADF on Cygwin, 0 on Mingw32. Can't even imagine what msvc >> >> EBADF is fine. Setting errno to 0 upon error is a bug. >> Don't cater to buggy systems. > > It is my system at work. What should I do, throw it out of window? Perhaps you misunderstood? My saying "don't cater to buggy systems", means don't pollute or dumb-down application code to accommodate them. Instead, code to some best-case standard (Linux, POSIX, whatever) and if necessary, use wrappers that work around the deficiencies of less-well-endowed systems. For example, coreutils assumes that functions like fchdir and openat work properly. Even though some really crufty systems have no fchdir syscall, and many relatively modern systems lack openat, fstatat, etc., all of the coreutils programs work fine in spite of that: they rely on gnulib's emulation of those underlying functions. This lets applications keep free of the dirty underlying portability details and concentrate on algorithms. Then there are the all of the wrappers for functions like stat, lstat, rename, etc. that misbehave on certain losing (but still in use) systems. I've been "accommodating" deficient systems for a very long time, so know from experience that it can be done cleanly. If this little corner of portability matters to you, it wouldn't be hard to write dup and/or fdopen wrappers that do the right thing on whatever buggy system you find you have to use. Incidentally, one nice (essential) thing about the gnulib framework is that full-featured systems usually incur *absolutely no* overhead, because they don't even use the wrapper functions. >> > Then put file name and the line number in! >> >> Surely you're playing devil's advocate, now... > > No, I'm just thinking aloud about whether I should start preparing > a reverting commit for your changes just to be able to continue > using Git on that mismanaged, stupid, slow and very real No need to go to such an extreme... Unless that particular diagnostic really matters to you. > system I have to work with. It is a Win2k laptop, in a Novell > network and with Cygwin on (actually 2 cygwins at least, which > cygwin does not support), and without a chance to _EVER_ use > anything else. You have my sympathy :-/ - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
