Document in more detail what's going on here.

1 files changed, 21 insertions, 1 deletions

diff --git a/regress/sys/kern/dup2_self/dup2_self.c b/regress/sys/kern/dup2_self/dup2_self.c
index 3b0a3936ae7..08a4cd4a94c 100644
--- a/regress/sys/kern/dup2_self/dup2_self.c
+++ b/regress/sys/kern/dup2_self/dup2_self.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: dup2_self.c,v 1.1 2002/02/08 18:47:46 art Exp $	*/
+/*	$OpenBSD: dup2_self.c,v 1.2 2002/02/18 13:32:08 art Exp $	*/
 /*
  *	Written by Artur Grabowski <art@openbsd.org> 2002 Public Domain.
  */
@@ -8,6 +8,26 @@
 #include <err.h>
 #include <fcntl.h>
 
+/*
+ * We're testing a small tweak in dup2 semantics. Normally dup and dup2
+ * will clear the close-on-exec flag on the new fd (which appears to be
+ * an implementation mistake from start and not some planned behavior).
+ * In todays implementations of dup and dup2 we have to make an effort
+ * to really clear that flag. But all tested implementations of dup2 have
+ * another tweak. If we dup2(old, new) when old == new, the syscall
+ * short-circuits and returns early (because there is no need to do all
+ * the work (and there is a risk for serious mistakes)). So although the
+ * docs say that dup2 should "take 'old', close 'new' perform a dup(2) of
+ * 'old' into 'new'" the docs are not really followed because close-on-exec
+ * is not cleared on 'new'.
+ *
+ * Since everyone has this bug, we pretend that this is the way it is
+ * supposed to be and test here that it really works that way.
+ *
+ * This is a fine example on where two separate implementation fuckups
+ * take out each other and make the end-result the way it was meant to be.
+ */
+
 int
 main()
 {