xfreopen, xnanosleep: Improve module description

[Bruno Haible]

These two module descriptions don't really answer the questions
  "What do get by using this module?"
  "When should I use this module?"

==> xfreopen <==
Description:
a wrapper for freopen

==> xnanosleep <==
Description:
a more convenient interface to nanosleep


These patches provide a better description.


2021-06-15  Bruno Haible  

xnanosleep: Improve module description.
* modules/xnanosleep (Description): Improve.
* lib/xnanosleep.h: Add comment. Make includable from C++.
* lib/xnanosleep.c: Update comment.

2021-06-15  Bruno Haible  

xfreopen: Improve module description.
* modules/xfreopen (Description): Improve.
* lib/xfreopen.h: Add comments. Make includable from C++.
* lib/xfreopen.c: Update comment.

>From 8275fa2ec57ea275ca35b003866d62f817650961 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 15 Jun 2021 13:07:51 +0200
Subject: [PATCH 1/2] xfreopen: Improve module description.

* modules/xfreopen (Description): Improve.
* lib/xfreopen.h: Add comments. Make includable from C++.
* lib/xfreopen.c: Update comment.
---
 ChangeLog|  7 +++
 lib/xfreopen.c   |  2 +-
 lib/xfreopen.h   | 13 -
 modules/xfreopen |  2 +-
 4 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 4e8242a..fc91284 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2021-06-15  Bruno Haible  
+
+	xfreopen: Improve module description.
+	* modules/xfreopen (Description): Improve.
+	* lib/xfreopen.h: Add comments. Make includable from C++.
+	* lib/xfreopen.c: Update comment.
+
 2021-06-14  Paul Eggert  
 
 	idx: new printf/scanf length modifier macro
diff --git a/lib/xfreopen.c b/lib/xfreopen.c
index dd60f13..b9e3883 100644
--- a/lib/xfreopen.c
+++ b/lib/xfreopen.c
@@ -1,4 +1,4 @@
-/* a wrapper for freopen
+/* Open a file, reusing a given stream, with error checking.
Copyright (C) 2008-2021 Free Software Foundation, Inc.
 
This program is free software: you can redistribute it and/or modify
diff --git a/lib/xfreopen.h b/lib/xfreopen.h
index 945b9b9..adfb9b9 100644
--- a/lib/xfreopen.h
+++ b/lib/xfreopen.h
@@ -1,4 +1,5 @@
-/* Copyright (C) 2009-2021 Free Software Foundation, Inc.
+/* Open a file, reusing a given stream, with error checking.
+   Copyright (C) 2009-2021 Free Software Foundation, Inc.
 
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
@@ -15,4 +16,14 @@
 
 #include 
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Opens the file FILENAME with mode MODE, reusing the given stream FP.
+   Upon failure, emits an error message and exits the program.  */
 void xfreopen (char const *filename, char const *mode, FILE *fp);
+
+#ifdef __cplusplus
+}
+#endif
diff --git a/modules/xfreopen b/modules/xfreopen
index dfd3d9e..b71efde 100644
--- a/modules/xfreopen
+++ b/modules/xfreopen
@@ -1,5 +1,5 @@
 Description:
-a wrapper for freopen
+Open a file, reusing a given stream, with error checking.
 
 Files:
 lib/xfreopen.c
-- 
2.7.4

>From d2d3a61961e102125f7cd4262ebdbd849033670c Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Tue, 15 Jun 2021 13:14:58 +0200
Subject: [PATCH 2/2] xnanosleep: Improve module description.

* modules/xnanosleep (Description): Improve.
* lib/xnanosleep.h: Add comment. Make includable from C++.
* lib/xnanosleep.c: Update comment.
---
 ChangeLog  |  7 +++
 lib/xnanosleep.c   |  2 +-
 lib/xnanosleep.h   | 11 ++-
 modules/xnanosleep |  2 +-
 4 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index fc91284..b192beb 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
 2021-06-15  Bruno Haible  
 
+	xnanosleep: Improve module description.
+	* modules/xnanosleep (Description): Improve.
+	* lib/xnanosleep.h: Add comment. Make includable from C++.
+	* lib/xnanosleep.c: Update comment.
+
+2021-06-15  Bruno Haible  
+
 	xfreopen: Improve module description.
 	* modules/xfreopen (Description): Improve.
 	* lib/xfreopen.h: Add comments. Make includable from C++.
diff --git a/lib/xnanosleep.c b/lib/xnanosleep.c
index 3c4443e..4a52d1a 100644
--- a/lib/xnanosleep.c
+++ b/lib/xnanosleep.c
@@ -1,4 +1,4 @@
-/* xnanosleep.c -- a more convenient interface to nanosleep
+/* A variant of nanosleep that takes a 'double' argument and handles EINTR.
 
Copyright (C) 2002-2007, 2009-2021 Free Software Foundation, Inc.
 
diff --git a/lib/xnanosleep.h b/lib/xnanosleep.h
index 77b896b..7e38b4f 100644
--- a/lib/xnanosleep.h
+++ b/lib/xnanosleep.h
@@ -1,4 +1,5 @@
-/* Copyright (C) 2004-2021 Free Software Foundation, Inc.
+/* A variant of nanosleep that takes a 'double' argument and handles EINTR.
+   Copyright (C) 2004-2021 Free Software Foundation, Inc.
 
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published
@@ -13,4 +14,12 @@
You should have received a co

Re: Seeking input from developers: glibc copyright assignment policy.

[Eric Blake]

On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:
> A proposal to change the glibc copyright assignment policy is being
> circulated on libc-alpha. The email thread starts at
> , and the
> text of the email seeking input is at the end of this message.
> 
> I'm sending this to bug-gnulib because we copy some files directly from
> glibc and eventually I expect these files to be affected. The simplest
> approach I see for Gnulib is to adopt glibc's policy, at least for files or
> code copied from glibc.

I would like to make sure the FSF legal department doesn't see any
holes in the plan, but I'm certainly okay as going on record as being
in favor of the plan.  I recall how long it took for me to get
permission to sign assignment papers from my previous employer, for
work I was doing in my spare time, and being able to use the DCO
instead would have made my efforts easier at that time.  (My current
employer already has a blanket copyright assignment on file for all
employees, but not everyone has a company that willing to promote open
source involvement.)

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Re: Seeking input from developers: glibc copyright assignment policy.

[Paul Smith]

On Tue, 2021-06-15 at 07:03 -0500, Eric Blake wrote:
> I recall how long it took for me to get permission to sign assignment
> papers from my previous employer, for work I was doing in my spare
> time, and being able to use the DCO instead would have made my
> efforts easier at that time.

This is what concerns me (not necessarily in Eric's case per se but in
general).  I worry that people think that a DCO is a hassle-free
replacement for an employer's copyright assignment.  Maybe, in some
jurisdictions, it even can be.

But as far as I'm aware in the U.S. (and other countries) you can't
just declare that your employer doesn't have any copyright to work you
do, even on your own time.  Most employment contracts make this clear
and even when they don't spell it out I think there's a presumption
that it is the case, certainly for salaried employees.

So, I just worry people will simply sign the DCO and call it good when
they don't actually have legal rights to do that.  Sure, that may
reduce liability for copyright infringement on the project: an employer
would have to go after the individual instead, but that wouldn't
prevent the project from having to remove the infringing code and all
code that could be considered derivative from it, which could be an
enormous hassle.

Maybe I'm wrong about how the DCO works but it greatly concerns me that
we would lose this safety net: rather than doing the work up-front
directed by people who understand the law, we're distributing this work
to random individuals and relying on each of them to fully understand
the legal questions and get it right for their situation... and leave
the project holding the bag if they don't.

Have there been any opinions or whitepapers published by FOSS
organizations regarding DCOs vs. assignments, discussing their benefits
and risks?

pipe-filter-ii tests: Fix long-standing failure on native Windows

[Bruno Haible]

The test-pipe-filter-ii2.sh test never worked on native Windows, due
to CR-LF and even CR-CR-LF seequences in the output.


2021-06-15  Bruno Haible  

pipe-filter-ii tests: Fix long-standing failure on native Windows.
* tests/test-pipe-filter-ii2-main.c: Include binary-io.h.
(main): Avoid NL to CRLF conversion on standard output.
* tests/test-pipe-filter-ii2-child.c: Include , binary-io.h.
(main): Avoid NL to CRLF conversion on standard output.

diff --git a/tests/test-pipe-filter-ii2-child.c 
b/tests/test-pipe-filter-ii2-child.c
index 14c9863..2610988 100644
--- a/tests/test-pipe-filter-ii2-child.c
+++ b/tests/test-pipe-filter-ii2-child.c
@@ -20,10 +20,15 @@
 
 #include 
 #include 
+#include 
+
+#include "binary-io.h"
 
 int
 main ()
 {
+  set_binary_mode (STDOUT_FILENO, O_BINARY);
+
   /* Repeatedly: Read two integers i and j, then output all integers in the
  range i..j, one per line.  */
   for (;;)
diff --git a/tests/test-pipe-filter-ii2-main.c 
b/tests/test-pipe-filter-ii2-main.c
index 3674e01..aad0505 100644
--- a/tests/test-pipe-filter-ii2-main.c
+++ b/tests/test-pipe-filter-ii2-main.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+#include "binary-io.h"
 #include "full-write.h"
 #include "macros.h"
 
@@ -88,6 +89,8 @@ main (int argc, char **argv)
 
   ASSERT (argc == 2);
 
+  set_binary_mode (STDOUT_FILENO, O_BINARY);
+
   /* Test writing to a nonexistent program traps sooner or later.  */
   {
 struct locals l;

Re: Seeking input from developers: glibc copyright assignment policy.

[Bruno Haible]

Paul Smith wrote:
> I worry that people think that a DCO is a hassle-free
> replacement for an employer's copyright assignment.  Maybe, in some
> jurisdictions, it even can be.
> 
> But as far as I'm aware in the U.S. (and other countries) you can't
> just declare that your employer doesn't have any copyright to work you
> do, even on your own time.

Yes, it depends on the jurisdiction. In Germany, the law gives the
employee the copyright on works created on his own time (§ 15 UrhG,
§ 69b UrhG, § 2.1 GG); the employment contract can influence further
details. The situation appears to be very different in the U.S.

Bruno

Re: [PATCH] idx: new printf/scanf length modifier macro

[Paul Eggert]

On 6/14/21 5:55 PM, Bruno Haible wrote:

Note that this modifier is not supported in internationalized format strings.
gettext() supports only the modifier names from . [1]


I guess I'll just use plain "%td" then. Oh well.

Re: Seeking input from developers: glibc copyright assignment policy.

[Pádraig Brady]

On 15/06/2021 13:03, Eric Blake wrote:

On Mon, Jun 14, 2021 at 01:39:26PM -0700, Paul Eggert wrote:

A proposal to change the glibc copyright assignment policy is being
circulated on libc-alpha. The email thread starts at
, and the
text of the email seeking input is at the end of this message.

I'm sending this to bug-gnulib because we copy some files directly from
glibc and eventually I expect these files to be affected. The simplest
approach I see for Gnulib is to adopt glibc's policy, at least for files or
code copied from glibc.


I would like to make sure the FSF legal department doesn't see any
holes in the plan, but I'm certainly okay as going on record as being
in favor of the plan.


I am in favor of the plan also.
I feel copyright assignment is a significant _initial_ hurdle to contributions,
where the potential to deter contribution outweighs any potential advantages.


I recall how long it took for me to get
permission to sign assignment papers from my previous employer, for
work I was doing in my spare time, and being able to use the DCO
instead would have made my efforts easier at that time.  (My current
employer already has a blanket copyright assignment on file for all
employees, but not everyone has a company that willing to promote open
source involvement.)


Yes the fact that one needs to repeat this process
as one changes employers is very awkward.
(In my case it was the reverse, in going from a company with
blanket copyright assignment, to one where I needed to
navigate the internal processes to get an assignment.)

I do wonder how diligent people are in general in this regard anyway.
I.e. how valid all current assignments are given the
frequency of employer changes and the awkwardness involved.

thanks,
Pádraig