Re: [PATCH] dfa: narrow the scope of many local variables
Thanks.
Re: [PATCH] dfa: narrow the scope of many local variables
Hi Paul, > I found some more local vars whose scope could be narrowed, and > installed the attached followup patch. I think you can now remove the 'invert = true;' statement (line 1022). Bruno
Re: suggested improvements to parse-datetime's debug messages ('date --debug')
On 02/01/17 02:25, Assaf Gordon wrote: > Hello, > > Attached are four small bug fixes and two additions to the debug messages in > parse-datetime.y (used in 'date --debug'). > The commit message for each commit gives a detail example of how/when it is > used. > There are no changes to the parsing, only to the debug messages. > > Comments and suggestions welcomed, Excellent. Changes look good to me modulo a couple of typos: /timezome/timezone/ /arithmentics/arithmetic/ Please push. I presume there will be a corresponding coreutils commit to adjust/add test cases. thanks! Pádraig.
Re: Test-lock hang (not 100% reproducible) on GNU/Linux
On Saturday, December 24, 2016 6:52:07 PM CET Bruno Haible wrote: > Wow, a 30x speed increase by using a lock instead of 'volatile'! > > Thanks for the testing. I cleaned up the patch to do less > code duplication and pushed it. Thanks, that's nice speedup! And sorry for the delay.. I still see infinite hang on ppc64le (sometimes), as discussed in [1]. It looks like starvation of writers in test_rwlock(). Could we set PTHREAD_RWLOCK_PREFER_WRITER_NP (in test-lock.c) to avoid those issues? One thing I'm afraid of is that writers could finish too early. Could we could artificially slow them down? [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/PQD576JZLERFY6ROI3GF7UYXKZIRI33G/ Pavel
Re: Test-lock hang (not 100% reproducible) on GNU/Linux
Hi Pavel, > One thing I'm afraid of is that writers could finish too > early. Could we could artificially slow them down? In test_rwlock the test does this: /* Wait for the threads to terminate. */ for (i = 0; i < THREAD_COUNT; i++) gl_thread_join (threads[i], NULL); set_atomic_int_value (&rwlock_checker_done, 1); for (i = 0; i < THREAD_COUNT; i++) gl_thread_join (checkerthreads[i], NULL); It waits until all 10 mutator threads are terminated, then sets a lock-protected variable rwlock_checker_done to 1, that signals to the 10 checker thread that they can terminate at the next occasion, and then waits for them to terminate. Are you saying that the kernel will schedule the 10 checker threads with higher priority than the 10 mutator threads, although I have *not* specified anything about priorities? That would be a kernel bug, IMO. Especially since the problem occurs only on one architecture. > Could we set PTHREAD_RWLOCK_PREFER_WRITER_NP (in test-lock.c) to avoid > those issues? I disagree. The test is a minimal test of the kernel's multithreading support. If among 10 mutator threads and 10 checker threads, all started with the same priority, it has such a severe bias that the mutator threads never get to run, you have a kernel bug. I should not need a non-portable threading function in order to get 20 threads to run reasonably. Imagine what scenarios you would then get with an application server and 400 threads. Bruno
Re: Test-lock hang (not 100% reproducible) on GNU/Linux
On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote: > Hi Pavel, > > > One thing I'm afraid of is that writers could finish too > > early. Could we could artificially slow them down? > > In test_rwlock the test does this: > > /* Wait for the threads to terminate. */ > for (i = 0; i < THREAD_COUNT; i++) > gl_thread_join (threads[i], NULL); > set_atomic_int_value (&rwlock_checker_done, 1); > for (i = 0; i < THREAD_COUNT; i++) > gl_thread_join (checkerthreads[i], NULL); > > It waits until all 10 mutator threads are terminated, then sets a > lock-protected variable rwlock_checker_done to 1, that signals to the > 10 checker thread that they can terminate at the next occasion, and > then waits for them to terminate. > > Are you saying that the kernel will schedule the 10 checker threads > with higher priority than the 10 mutator threads, although I have *not* > specified anything about priorities? That would be a kernel bug, IMO. That's what I'm not sure about, as discussed in [1], POSIX says (for pthread_rwlock_wrlock()): Implementations may favor writers over readers to avoid writer starvation. But that's too far from 'shall favor' spelling. And when I had a look at my man pthread_rwlockattr_setkind_np(3), there's written: PTHREAD_RWLOCK_PREFER_READER_NP This is the default. A thread may hold multiple read locks; that is, read locks are recursive. According to The Single Unix Specification, the behavior is unspecified when a reader tries to place a lock, and there is no write lock but writers are waiting. Giving preference to the reader, as is set by PTHREAD_RWLOCK_PREFER_READER_NP, implies that the reader will receive the requested lock, even if a writer is waiting. As long as there are readers, the writer will be starved. > Especially since the problem occurs only on one architecture. I've been able to reproduce this on i686 in the meantime too, sorry -- I just reported what I observed :(. See [1]. > > Could we set PTHREAD_RWLOCK_PREFER_WRITER_NP (in test-lock.c) to avoid > > those issues? > > I disagree. The test is a minimal test of the kernel's multithreading > support. If among 10 mutator threads and 10 checker threads, all started > with the same priority, it has such a severe bias that the mutator threads > never get to run, you have a kernel bug. I should not need a non-portable > threading function in order to get 20 threads to run reasonably. > > Imagine what scenarios you would then get with an application server and > 400 threads. It might be bug in libpthread, too, but based on the POSIX specs and manual pages, I am not sure whether this might be actually considered a bug. [1] https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/PQD576JZLERFY6ROI3GF7UYXKZIRI33G/ Pavel
Re: [PATCH] dfa: narrow the scope of many local variables
Bruno Haible wrote:
I think you can now remove the 'invert = true;' statement (line 1022).
Thanks, done with the attached.
>From 89683adbc0b4c6c75727f25dcd417f0b15f3517f Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 2 Jan 2017 08:27:12 -0800
Subject: [PATCH] dfa: remove duplicate assignment
Problem reported by Bruno Haible in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg7.html
* lib/dfa.c (parse_bracket_exp): Simplify.
---
ChangeLog | 7 +++
lib/dfa.c | 1 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/ChangeLog b/ChangeLog
index 2b8cbc1..6ee2380 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2017-01-02 Paul Eggert
+
+ dfa: remove duplicate assignment
+ Problem reported by Bruno Haible in:
+ http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg7.html
+ * lib/dfa.c (parse_bracket_exp): Simplify.
+
2017-01-01 Paul Eggert
dfa: simplify constraint-dependency checking
diff --git a/lib/dfa.c b/lib/dfa.c
index cd600aa..6f0a12f 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -1019,7 +1019,6 @@ parse_bracket_exp (struct dfa *dfa)
if (invert)
{
FETCH_WC (dfa, c, wc, _("unbalanced ["));
- invert = true;
known_bracket_exp = dfa->simple_locale;
}
--
2.7.4
Re: Test-lock hang (not 100% reproducible) on GNU/Linux
On 01/02/2017 05:37 PM, Pavel Raiskup wrote: > On Monday, January 2, 2017 4:50:28 PM CET Bruno Haible wrote: >> Especially since the problem occurs only on one architecture. > > I've been able to reproduce this on i686 in the meantime too, sorry -- I just > reported what I observed :(. See [1]. ... or it is related to the KOJI environment? I've seen some of the gnulib tests in the coreutils-testsuite failing on several non-x86 archs on the openSUSE build service in the past (especially on newer like aarch64). But at least in the past year, the tests on all of i586, x86_64, ppc, ppc64, ppc64le, aarch64 and armv7l have been quite stable. https://build.opensuse.org/package/live_build_log/Base:System/coreutils-testsuite/openSUSE_Factory_PowerPC/ppc64le Have a nice day, Berny
Question about portability guidelines
Looking at the portability guidelines[1] there is some confusion; early on it says: > Currently we assume at least a freestanding C89 compiler But then later in that same section I see things like: > The GNU coding standards allow one departure from strict C99 and: > Hence Gnulib code should avoid using constructs (e.g., undeclared > functions return int) that do not conform to C99. etc. Are these references to C99 typos, and they should be C89 instead? Also, I see this: > Gnulib code can assume that standard internal types like size_t are no > wider than long. Is that right? On a 64bit system compiling with Microsoft Visual C, long is only a 32bit integer. Is it saying that gnulib is specifically not intended to work with MS Visual C? - [1] https://www.gnu.org/software/gnulib/manual/html_node/Portability-guidelines.html
[PATCH 1/2] dfa: narrow more local var scopes
* lib/dfa.c: Move more local decls to be more local.
---
ChangeLog | 3 +++
lib/dfa.c | 13 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 6ee2380..7a9edc1 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,8 @@
2017-01-02 Paul Eggert
+ dfa: narrow more local var scopes
+ * lib/dfa.c: Move more local decls to be more local.
+
dfa: remove duplicate assignment
Problem reported by Bruno Haible in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg7.html
diff --git a/lib/dfa.c b/lib/dfa.c
index 6f0a12f..f2a36d9 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -995,7 +995,6 @@ static token
parse_bracket_exp (struct dfa *dfa)
{
int c;
- charclass ccl;
/* This is a bracket expression that dfaexec is known to
process correctly. */
@@ -1013,6 +1012,7 @@ parse_bracket_exp (struct dfa *dfa)
wint_t wc1 = 0;
dfa->lex.brack.nchars = 0;
+ charclass ccl;
zeroset (&ccl);
FETCH_WC (dfa, c, wc, _("unbalanced ["));
bool invert = c == '^';
@@ -1255,7 +1255,6 @@ lex (struct dfa *dfa)
for (int i = 0; i < 2; ++i)
{
int c;
- charclass ccl;
FETCH_WC (dfa, c, dfa->lex.wctok, NULL);
switch (c)
@@ -1472,6 +1471,7 @@ lex (struct dfa *dfa)
goto normal_char;
if (dfa->canychar == (size_t) -1)
{
+ charclass ccl;
fillset (&ccl);
if (!(dfa->syntax.syntax_bits & RE_DOT_NEWLINE))
clrbit ('\n', &ccl);
@@ -1494,6 +1494,7 @@ lex (struct dfa *dfa)
goto normal_char;
if (!dfa->localeinfo.multibyte)
{
+ charclass ccl;
zeroset (&ccl);
for (int c2 = 0; c2 < NOTCHAR; ++c2)
if (isspace (c2))
@@ -1527,6 +1528,7 @@ lex (struct dfa *dfa)
if (!dfa->localeinfo.multibyte)
{
+ charclass ccl;
zeroset (&ccl);
for (int c2 = 0; c2 < NOTCHAR; ++c2)
if (dfa->syntax.sbit[c2] == CTX_LETTER)
@@ -1569,6 +1571,7 @@ lex (struct dfa *dfa)
if (dfa->syntax.case_fold && isalpha (c))
{
+ charclass ccl;
zeroset (&ccl);
setbit_case_fold_c (c, &ccl);
return dfa->lex.lasttok = CSET + charclass_index (dfa, &ccl);
@@ -2596,8 +2599,6 @@ dfaanalyze (struct dfa *d, bool searchflag)
static state_num
dfastate (state_num s, struct dfa *d, unsigned char uc, state_num trans[])
{
- leaf_set group; /* Positions that match the input char. */
- charclass label; /* The group's label. */
position_set follows; /* Union of the follows of the group. */
position_set tmp; /* Temporary space for merging sets. */
state_num state; /* New state. */
@@ -2608,9 +2609,13 @@ dfastate (state_num s, struct dfa *d, unsigned char uc,
state_num trans[])
fprintf (stderr, "build state %td\n", s);
#endif
+ /* Positions that match the input char. */
+ leaf_set group;
group.elems = xnmalloc (d->nleaves, sizeof *group.elems);
group.nelem = 0;
+ /* The group's label. */
+ charclass label;
fillset (&label);
for (size_t i = 0; i < d->states[s].elems.nelem; ++i)
--
2.7.4
[PATCH 2/2] dfa: prefer functions to FETCH_WC macro
* lib/dfa.c (FETCH_WC): Remove, replacing with ...
(fetch_wc, bracket_fetch_wc): ... new functions. These store the
wint_t result into DFA->lex.wctok instead of to a separate arg.
All callers changed. Move more local decls closer to where
they're used.
---
ChangeLog | 7
lib/dfa.c | 107 ++
2 files changed, 65 insertions(+), 49 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 7a9edc1..66ea430 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,12 @@
2017-01-02 Paul Eggert
+ dfa: prefer functions to FETCH_WC macro
+ * lib/dfa.c (FETCH_WC): Remove, replacing with ...
+ (fetch_wc, bracket_fetch_wc): ... new functions. These store the
+ wint_t result into DFA->lex.wctok instead of to a separate arg.
+ All callers changed. Move more local decls closer to where
+ they're used.
+
dfa: narrow more local var scopes
* lib/dfa.c: Move more local decls to be more local.
diff --git a/lib/dfa.c b/lib/dfa.c
index f2a36d9..4f65665 100644
--- a/lib/dfa.c
+++ b/lib/dfa.c
@@ -922,34 +922,33 @@ using_simple_locale (bool multibyte)
}
}
-/* Fetch the next lexical input character. Set C (of type int) to the
- next input byte, except set C to EOF if the input is a multibyte
- character of length greater than 1. Set WC (of type wint_t) to the
- value of the input if it is a valid multibyte character (possibly
- of length 1); otherwise set WC to WEOF. If there is no more input,
- report EOFERR if EOFERR is not null, and return lasttok = END
- otherwise. */
-# define FETCH_WC(dfa, c, wc, eoferr) \
- do { \
-if (! (dfa)->lex.left) \
- {\
-if ((eoferr) != 0) \
- dfaerror (eoferr); \
-else \
- return (dfa)->lex.lasttok = END; \
- }\
-else \
- {\
-wint_t _wc;\
-size_t nbytes = mbs_to_wchar (&_wc, (dfa)->lex.ptr, \
- (dfa)->lex.left, dfa); \
-(dfa)->lex.cur_mb_len = nbytes;\
-(wc) = _wc;\
-(c) = nbytes == 1 ? to_uchar ((dfa)->lex.ptr[0]) : EOF; \
-(dfa)->lex.ptr += nbytes; \
-(dfa)->lex.left -= nbytes; \
- }\
- } while (false)
+/* Fetch the next lexical input character from the pattern. There
+ must at least one byte of pattern input. Set DFA->lex.wctok to the
+ value of the character or to WEOF depending on whether the input is
+ a valid multibyte character (possibly of length 1). Then return
+ the next input byte value, except return EOF if the input is a
+ multibyte character of length greater than 1. */
+static int
+fetch_wc (struct dfa *dfa)
+{
+ size_t nbytes = mbs_to_wchar (&dfa->lex.wctok, dfa->lex.ptr, dfa->lex.left,
+dfa);
+ dfa->lex.cur_mb_len = nbytes;
+ int c = nbytes == 1 ? to_uchar (dfa->lex.ptr[0]) : EOF;
+ dfa->lex.ptr += nbytes;
+ dfa->lex.left -= nbytes;
+ return c;
+}
+
+/* If there is no more input, report an error about unbalanced brackets.
+ Otherwise, behave as with fetch_wc (DFA). */
+static int
+bracket_fetch_wc (struct dfa *dfa)
+{
+ if (! dfa->lex.left)
+dfaerror (_("unbalanced ["));
+ return fetch_wc (dfa);
+}
typedef int predicate (int);
@@ -994,8 +993,6 @@ find_pred (const char *str)
static token
parse_bracket_exp (struct dfa *dfa)
{
- int c;
-
/* This is a bracket expression that dfaexec is known to
process correctly. */
bool known_bracket_exp = true;
@@ -1007,22 +1004,20 @@ parse_bracket_exp (struct dfa *dfa)
Bit 3 = includes ranges, char/equiv classes or collation elements. */
int colon_warning_state;
- wint_t wc;
- wint_t wc2;
- wint_t wc1 = 0;
-
dfa->lex.brack.nchars = 0;
charclass ccl;
zeroset (&ccl);
- FETCH_WC (dfa, c, wc, _("unbalanced ["));
+ int c = bracket_fetch_wc (dfa);
bool invert = c == '^';
if (invert)
{
- FETCH_WC (dfa, c, wc, _("unbalanced ["));
+ c = bracket_fetch_wc (dfa);
+ invert = true;
known_bracket_exp = dfa->simple_locale;
}
-
+ wint_t wc = dfa->lex.wctok;
int c1;
+ wint_t wc1;
colon_warning_state = (c == ':');
do
{
@@ -1035,7 +1030,8 @@ parse_bracket_exp (struct dfa *dfa)
dfa is ever called. */
if (c == '[')
{
- FETCH_WC (dfa, c1, wc1, _("unbalanced ["));
+ c1 = bracket_fetch_wc (dfa);
+ wc1 = dfa->lex.wctok;
if ((c1 == ':' && (dfa->syntax.syntax_bits & RE_CHAR_CLASSES))
Re: Question about portability guidelines
Paul Smith wrote: > > Gnulib code can assume that standard internal types like size_t are no > > wider than long. > > Is that right? On a 64bit system compiling with Microsoft Visual C, > long is only a 32bit integer. Is it saying that gnulib is specifically > not intended to work with MS Visual C? You are right, on 64-bit native Windows (both mingw and MSVC), 'long' is only 32-bit and thus smaller than 'intptr_t'. Parts of gnulib do work on MSVC and mingw; for full coverage, there's still a lot of work to be done [1]. I would vote for removing this sentence "Gnulib code can assume that standard internal types like size_t are no wider than long." The fix is easy nowadays (since MSVC now has ): Use intptr_t or ptrdiff_t or size_t as appropriate. Bruno [1] http://lists.gnu.org/archive/html/bug-gnulib/2016-12/msg00112.html
[PATCH] maint.mk: support parallel execution of coverage
* top/maint.mk (coverage): Run dependencies serially, thus supporting parallel processing of each one, particularly build-coverage, which builds and runs tests. --- ChangeLog| 7 +++ top/maint.mk | 5 - 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 66ea430..b2fe194 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2017-01-02 Pádraig Brady + + maint.mk: support parallel execution of coverage + * top/maint.mk (coverage): Run dependencies serially, + thus supporting parallel processing of each one, + particularly build-coverage, which builds and runs tests. + 2017-01-02 Paul Eggert dfa: prefer functions to FETCH_WC macro diff --git a/top/maint.mk b/top/maint.mk index 874a7fc..28cb9db 100644 --- a/top/maint.mk +++ b/top/maint.mk @@ -1501,7 +1501,10 @@ gen-coverage: --highlight --frames --legend \ --title "$(PACKAGE_NAME)" -coverage: init-coverage build-coverage gen-coverage +coverage: + $(MAKE) init-coverage + $(MAKE) build-coverage + $(MAKE) gen-coverage # Some projects carry local adjustments for gnulib modules via patches in # a gnulib patch directory whose default name is gl/ (defined in bootstrap -- 2.5.5
copyright 2017 in synced files
As usual, the copyright year update included all synced files (including licenses), and so as usual everything is now out of sync. Can the changes in these files be reverted please? --thanks, karl. build-aux/config.guess Sun Jan 1 09:52:15 2017 build-aux/config.sub Sun Jan 1 09:52:15 2017 build-aux/ar-lib Sun Jan 1 09:52:15 2017 build-aux/compile Sun Jan 1 09:52:15 2017 build-aux/depcomp Sun Jan 1 09:52:15 2017 build-aux/mdate-sh Sun Jan 1 09:52:15 2017 build-aux/texinfo.tex Sun Jan 1 09:52:15 2017 doc/maintain.texi Sun Jan 1 09:52:15 2017 doc/standards.texi Sun Jan 1 09:52:15 2017 doc/make-stds.texi Sun Jan 1 09:52:15 2017 doc/gnu-oids.texi Sun Jan 1 09:52:15 2017 doc/fdl.texi Sun Jan 1 09:52:15 2017 doc/COPYING.LESSERv3 Sun Jan 1 09:52:15 2017 doc/COPYING.LESSERv2 Sun Jan 1 09:52:15 2017 doc/COPYINGv3 Sun Jan 1 09:52:15 2017 doc/COPYINGv2 Sun Jan 1 09:52:15 2017 doc/lgpl-2.1.texi Sun Jan 1 09:52:15 2017 doc/gpl-2.0.texi Sun Jan 1 09:52:15 2017 doc/agpl-3.0.texi Sun Jan 1 09:52:15 2017 doc/fdl-1.3.texi Sun Jan 1 09:52:15 2017 doc/gpl-3.0.texi Sun Jan 1 09:52:15 2017 doc/lgpl-3.0.texi Sun Jan 1 09:52:15 2017 m4/codeset.m4 Sun Jan 1 09:52:16 2017 m4/gettext.m4 Sun Jan 1 09:52:16 2017 m4/iconv.m4Sun Jan 1 09:52:16 2017 m4/intl.m4 Sun Jan 1 09:52:16 2017 m4/intldir.m4 Sun Jan 1 09:52:16 2017 m4/intlmacosx.m4 Sun Jan 1 09:52:16 2017 m4/lcmessage.m4Sun Jan 1 09:52:16 2017 m4/nls.m4 Sun Jan 1 09:52:16 2017 m4/po.m4 Sun Jan 1 09:52:16 2017
Re: Question about portability guidelines
Bruno Haible wrote:
I would vote for removing this sentence "Gnulib code can assume that standard
internal types like size_t are no wider than long." The fix is easy nowadays
(since MSVC now has ): Use intptr_t or ptrdiff_t or size_t as
appropriate.
It's not that easy for code that wants to print such integers, as %ld doesn't
suffice on MinGW and older POSIXish libraries don't support %jd etc. Perhaps
once Gnulib assumes C99-or-later libraries, and once somebody goes through all
the Gnulib code and checks it. In the meantime we should probably leave
something like that sentence in there, although we should warn people about the
MSVC issues. I installed the attached to try to do that, and to try to clarify
the issues about C89 vs C99 vs C11 that were in Paul's question.
From b7eca6196a6abd767971ccb360d0bbe4a60b247c Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 2 Jan 2017 16:05:14 -0800
Subject: [PATCH] doc: modernize for C11 etc.
* doc/gnulib-readme.texi (Portability guidelines): Modernize a bit
for C11, MinGW, etc. This responds to Paul Smith's question in:
http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00014.html
---
ChangeLog | 5 +
doc/gnulib-readme.texi | 59 +-
2 files changed, 44 insertions(+), 20 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 66ea430..76c7569 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,10 @@
2017-01-02 Paul Eggert
+ doc: modernize for C11 etc.
+ * doc/gnulib-readme.texi (Portability guidelines): Modernize a bit
+ for C11, MinGW, etc. This responds to Paul Smith's question in:
+ http://lists.gnu.org/archive/html/bug-gnulib/2017-01/msg00014.html
+
dfa: prefer functions to FETCH_WC macro
* lib/dfa.c (FETCH_WC): Remove, replacing with ...
(fetch_wc, bracket_fetch_wc): ... new functions. These store the
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index 256a289..ecd94c3 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -292,41 +292,57 @@ platforms; and @code{time_r} users need not worry about
@code{localtime_r} returning @code{int} (not @code{char@ *}) on some
platforms that predate POSIX 1003.1-2001.
-Currently we assume at least a freestanding C89 compiler, possibly
-operating with a C library that predates C89. The oldest environments
-currently ported to are probably HP-UX 10.20 and IRIX 5.3, though we
-are not testing these platforms very often.
-
-Because we assume a freestanding C89 compiler, Gnulib code can include
+Gnulib attempts to be portable to platforms that are still supported
+by their providers, even if these systems are not the latest version.
+Currently Gnulib assumes at least a freestanding C89 compiler,
+possibly operating with a C library that predates C89; with time this
+assumption will likely be strengthened to later versions of the C
+standard. Old platforms currently supported include AIX 6.1, HP-UX
+11i v1 and Solaris 10, though these platforms are rarely tested.
+Gnulib itself is so old that it contains contains many fixes for
+obsolete platforms, fixes that may be removed in the future.
+
+Because of the freestanding C89 assumption, Gnulib code can include
@code{}, @code{}, @code{}, and
@code{} unconditionally. It can also assume the existence
of @code{}, @code{}, @code{},
@code{}, @code{}, @code{},
@code{}, @code{}, and @code{}. Similarly,
many modules include @code{} even though it's not even in
-C99; that's OK since @code{} has been around nearly
+C11; that's OK since @code{} has been around nearly
forever.
-Even if the include files exist, they may not conform to C89.
+Even if the include files exist, they may not conform to the C standard.
However, GCC has a @command{fixincludes} script that attempts to fix most
C89-conformance problems. So Gnulib currently assumes include files
largely conform to C89 or better. People still using ancient hosts
should use fixincludes or fix their include files manually.
-Even if the include files conform to C89, the library itself may not.
+Even if the include files conform, the library itself may not.
For example, @code{strtod} and @code{mktime} have some bugs on some platforms.
You can work around some of these problems by requiring the relevant
modules, e.g., the Gnulib @code{mktime} module supplies a working and
conforming @code{mktime}.
-The GNU coding standards allow one departure from strict C99: Gnulib
-code can assume that standard internal types like @code{size_t} are no wider
-than @code{long}. POSIX 1003.1-2001 and the GNU coding standards both
-require @code{int} to be at least 32 bits wide, so Gnulib code assumes this
-as well. Gnulib code makes the following additional assumptions:
+The GNU coding standards allow one departure from strict C: Gnulib
+code can assume that standard internal types like @code{size_t} are no
+wider than @code{long}. POSIX requires implementations to support at
+least one programming envir
Re: copyright 2017 in synced files
Karl Berry wrote: Can the changes in these files be reverted please? Thanks, I wish the copyright-update script didn't do that. I reverted those changes.
[PATCH] parse-datetime: fix generated paths for coverage files
On 26/07/15 15:41, Rakesh Kumar wrote: > Hi All, > > While trying to generate HTML test coverage reports, I am facing an > error. Can anyone please advice on this. Help would be appreciated. > > > [00:36 rakesh@param > /home/rakesh/development/gnu_development/coreutils$] : > lcov -t coreutils -q -d lib -b `pwd` -o lib.lcov -c > > Cannot open source file parse-datetime.c `make coverage` gives a similar error for me saying that lib/lib/parse-datetime.y is not available. That looks to be due to parse-datetime.c being moved after being generated, thus having incorrect paths pertaining to parse-datetime.y. With the attached applied to gnulib I no longer see the issue. cheers, Pádraig. p.s. I see a similar error on hydra also with the doubled lib/lib, saying that lib/lib/c-ctype.h is not found. I've not looked into that, as `make coverage` doesn't give that here. From 6b662df1edcf71f442c6fe74bfe838e44d3b8503 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Tue, 3 Jan 2017 00:52:13 + Subject: [PATCH] parse-datetime: fix generated paths for coverage files * modules/parse-datetime: Adjust the paths for parse-datetime.y within parse-datetime.c, so that gcc generates appropriate .gcno files, allowing lcov to proceed without error. Previously it would error trying to find "lib/lib/parse-datetime.y". --- ChangeLog | 8 modules/parse-datetime | 4 +++- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index b2fe194..4dfa496 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2017-01-03 Pádraig Brady + + parse-datetime: fix generated paths for coverage files + * modules/parse-datetime: Adjust the paths for parse-datetime.y + within parse-datetime.c, so that gcc generates appropriate .gcno + files, allowing lcov to proceed without error. Previously it + would error trying to find "lib/lib/parse-datetime.y". + 2017-01-02 Pádraig Brady maint.mk: support parallel execution of coverage diff --git a/modules/parse-datetime b/modules/parse-datetime index dc25bec..e059d17 100644 --- a/modules/parse-datetime +++ b/modules/parse-datetime @@ -38,7 +38,9 @@ parse-datetime.c: parse-datetime.y y.output parse-datetime.output \ -- $(YACC) $(YFLAGS) $(AM_YFLAGS) && \ mv parse-datetime.c parse-datetime.c-t && \ - mv parse-datetime.c-t $(srcdir)/parse-datetime.c + $(SED) 's|".*/parse-datetime.y"|"parse-datetime.y"|' \ + < parse-datetime.c-t > $(srcdir)/parse-datetime.c && \ + rm -f parse-datetime.c-t lib_SOURCES += parse-datetime.y BUILT_SOURCES += parse-datetime.c MOSTLYCLEANFILES += parse-datetime.c-t -- 2.5.5
Re: [PATCH] parse-datetime: fix generated paths for coverage files
On 03/01/17 01:25, Pádraig Brady wrote: > On 26/07/15 15:41, Rakesh Kumar wrote: >> Hi All, >> >> While trying to generate HTML test coverage reports, I am facing an >> error. Can anyone please advice on this. Help would be appreciated. >> >> >> [00:36 rakesh@param >> /home/rakesh/development/gnu_development/coreutils$] : >> lcov -t coreutils -q -d lib -b `pwd` -o lib.lcov -c >> >> Cannot open source file parse-datetime.c > > `make coverage` gives a similar error for me saying > that lib/lib/parse-datetime.y is not available. > That looks to be due to parse-datetime.c being moved after being generated, > thus having incorrect paths pertaining to parse-datetime.y. > > With the attached applied to gnulib I no longer see the issue. Oops that messed up atomicity of the update. Update attached. cheers, Pádraig >From 24737dc740a365c68da9ebb84f57dea51bc5a629 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= Date: Tue, 3 Jan 2017 00:52:13 + Subject: [PATCH] parse-datetime: fix generated paths for coverage files * modules/parse-datetime: Adjust the paths for parse-datetime.y within parse-datetime.c, so that gcc generates appropriate .gcno files, allowing lcov to proceed without error. Previously it would error trying to find "lib/lib/parse-datetime.y". --- ChangeLog | 8 modules/parse-datetime | 3 ++- 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index b2fe194..4dfa496 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2017-01-03 Pádraig Brady + + parse-datetime: fix generated paths for coverage files + * modules/parse-datetime: Adjust the paths for parse-datetime.y + within parse-datetime.c, so that gcc generates appropriate .gcno + files, allowing lcov to proceed without error. Previously it + would error trying to find "lib/lib/parse-datetime.y". + 2017-01-02 Pádraig Brady maint.mk: support parallel execution of coverage diff --git a/modules/parse-datetime b/modules/parse-datetime index dc25bec..1e91441 100644 --- a/modules/parse-datetime +++ b/modules/parse-datetime @@ -37,7 +37,8 @@ parse-datetime.c: parse-datetime.y y.tab.h parse-datetime.h \ y.output parse-datetime.output \ -- $(YACC) $(YFLAGS) $(AM_YFLAGS) && \ - mv parse-datetime.c parse-datetime.c-t && \ + $(SED) 's|".*/parse-datetime.y"|"parse-datetime.y"|' \ + < parse-datetime.c > parse-datetime.c-t && \ mv parse-datetime.c-t $(srcdir)/parse-datetime.c lib_SOURCES += parse-datetime.y BUILT_SOURCES += parse-datetime.c -- 2.5.5
