"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? > Are you sure fdopen on Cygwin > sets ENOMEM? Are you suggesting not to use errno because it won't contain useful information on Mingw32? >> 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. > (which actually isn't a developers tool, but very common) will return. > >> > (Yes, I do think that "duplicate standard output" is useless, >> > except for debugging. Exactly as strerror is, but that is shorter). >> >> I like to include *something* in the diagnostic so that when someone >> sees it and reports it developers have an easier time finding where it >> comes from in the code. Especially with something as unlikely (and hard >> to reproduce) as this, that might be useful. > > Then put file name and the line number in! Surely you're playing devil's advocate, now... If you go that route, you might as well use assert() for both conditions, and we all know *that* is silly. - 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
