Re: [PATCH] maint.mk: prohibit common grammar error: all these
Paul Eggert wrote: On 06/10/2012 12:56 PM, Jim Meyering wrote: Can anyone think of a common way to use all these that is not in error? Yes, lots: Tired with all these, for restful death I cry -- Shakespeare, Sonnet 66, line 1 But Mary kept all these things, and pondered them in their heart. -- Luke 2:19 (King James Version) The complaint ... about modern steel furniture, modern glass houses, modern red bars and modern streamlined trains and cars is that all these _objets modernes_, while adequate and amusing in themselves, tend to make the people who use them look dated. -- E.B. White, Fitting In, The New Yorker, 1934-06-09 I keep picturing all these little kids playing some game in this big field of rye and all. -- J.D. Salinger, The Catcher in the Rye, 1951 All these examples are perfectly good English, and there's no need to remove all those instances of all these from gnulib. Hi Paul, I'm not convinced. I suspect that some those (sic) instances are exercising poetic license (Shakespeare, surely) or merely demonstrate that this error is common in informal speech (Salinger's narrative). In your opinion, do any those uses in gnulib sound better without the of? What do you think about correcting some those instances? Yes, there *are* some uses that are ok: All these people need is ... I did a quick search and found this in response to a question: http://grammar.ccc.commnet.edu/grammar/grammarlogs2/grammarlogs339.htm What is the correct way to use all? Should a person say all or all of? He moved all the books. He moved all of the books. All of these files belong to her. All these files belong to her. - In most constructions, we dispense happily with the of. However, when there is another pronoun (such as those, those) following the all, it's probably a good idea to include the of. Authority: The New Fowler's Modern English Usage edited by R.W. Burchfield. Clarendon Press: Oxford, England. 1996. Used with the permission of Oxford University Press. (under all)
Re: [PATCH] maint.mk: prohibit common grammar error: all these
() Jim Meyering j...@meyering.net () Mon, 11 Jun 2012 10:05:29 +0200 In your opinion, do any those uses in gnulib sound better without the of? For short pronouncements, of doesn't flow quite as nicely: https://en.wikipedia.org/wiki/2010_Odyssey_Two. FWIW, same goes for Italian: https://it.wikipedia.org/wiki/2010:_Odissea_due_(romanzo) (tutti questi == all these). (end unsolicited opinion, back to lurking...)
Re: [PATCH] maint.mk: prohibit common grammar error: all these
Thien-Thi Nguyen wrote: () Jim Meyering j...@meyering.net () Mon, 11 Jun 2012 10:05:29 +0200 In your opinion, do any those uses in gnulib sound better without the of? For short pronouncements, of doesn't flow quite as nicely: https://en.wikipedia.org/wiki/2010_Odyssey_Two. Hi Thien-Thi, Thanks for chiming in (seriously). HAL begins repeatedly broadcasting the message: ALL THESE WORLDS ARE YOURS—EXCEPT EUROPA. ATTEMPT NO LANDINGS THERE. IMHO, this relates to the spoken/common usage I already mentioned. FWIW, same goes for Italian: https://it.wikipedia.org/wiki/2010:_Odissea_due_(romanzo) (tutti questi == all these). (end unsolicited opinion, back to lurking...) I admit that in some situations, the lack of of does not sound bad, and inserting it doesn't add anything, and may even detract a little, but given the formal tone of most of the affected comments and documentation (and in particular, the many instances in automake documentation that prompted this), it seemed worthwhile. Obviously, if even a few people find reason to object, I'll be happy to remove the check.
Re: [PATCH] maint.mk: prohibit common grammar error: all these
On 06/11/2012 01:05 AM, Jim Meyering wrote: I suspect that some those (sic) instances are exercising poetic license (Shakespeare, surely) or merely demonstrate that this error is common in informal speech (Salinger's narrative). Sorry, but that's not what's happening here. Certainly E.B. White was not using informal speech in The New Yorker. And I can easily find hundreds of other examples in formal English that is carefully edited and is similarly unlikely to contain grammatical errors. For example: Foremost among the reasons for all these changes in family structure are the gains of the women’s movement. -- Kate Bolick, All the Single Ladies, The Atlantic, Nov. 2011 http://www.theatlantic.com/magazine/archive/2011/11/all-the-single-ladies/8654/ But all these dramas were facilitated by the F.B.I. -- David K. Shipler, Terrorist Plots, Hatched by the F.B.I., New York Times, April 28, 2012 http://www.nytimes.com/2012/04/29/opinion/sunday/terrorist-plots-helped-along-by-the-fbi.html All these decisions lie in our own hands. -- David Cameron, in a prepared formal speech at the World Economic Forum, January 26, 2012 http://www.thetimes.co.uk/tto/public/davos/article3300564.ece There's nothing grammatically wrong with any of these examples, and more generally, the notion that all these is grammatically incorrect is just wrong. On the contrary, the traditional form uniformly omits the of: there are dozens of instances of all these in the King James Version and in Shakespeare, and zero instances of all of these. The form all of these is relatively recent, and is probably due to form-association with some of these, most of these, etc. Although all of these is now grammatically correct, it has by no means supplanted the traditional form all these; both forms are OK. I did a quick search and found this in response to a question: http://grammar.ccc.commnet.edu/grammar/grammarlogs2/grammarlogs339.htm ... In most constructions, we dispense happily with the of. However, when there is another pronoun (such as those, those) following the all, it's probably a good idea to include the of. Authority: The New Fowler's Modern English Usage edited by R.W. Burchfield. Clarendon Press: Oxford, England. 1996. Used with the permission of Oxford University Press. (under _all_) I'm afraid you've been had. That web page is bogus. I have a copy of Burchfield and it advises the opposite of what that web page claims it says. Here's a direct quote from Burchfield: _of_ can normally be dispensed with in nominal phrases: e.g. _all those years ago_ -- Burchfield, p. 41, under all do any those uses in gnulib sound better without the of? Clearly of is required after any. Any and all are grammatically different, which is why all the time is fine but any the time is not. But to get back to your question, all the examples in http://lists.gnu.org/archive/html/bug-gnulib/2012-06/msg00074.html work just as well, if not better, without the of. Often the optional of wastes the reader's time and wastes space. Sometimes the of adds clarity or regularity, but I don't see any such cases in those examples.
Re: gnulib portability issues
On 06/10/2012 07:47 PM, Rich Felker wrote:
If you think it matters, __freading could be used instead.
That doesn't sound right, since Solaris/glibc __freading returns 1
on read-only streams, whereas we want to know whether
the stream has a nonempty input buffer; this is not
the same thing.
They're purposefully opaque so that they can be changed if an
alternate implementation proves better.
Dragonfly BSD attacked this problem by supplying a
function __sreadahead that returns the value in question.
Perhaps musl could do something similar? That would fix
the problem while preserving opacity.
Another possibility is something like the following patch,
which may fix this particular problem, though I expect that there are
other problems with the opacity that would still be in
there somewhere.
Also, I don't like this patch because it adds runtime overhead
in the non-musl case, but presumably this could be fixed.
(Right now I'm just trying to think through possible solutions.)
diff --git a/lib/freadahead.c b/lib/freadahead.c
index 2ba8b34..db6b68b 100644
--- a/lib/freadahead.c
+++ b/lib/freadahead.c
@@ -84,10 +84,7 @@ freadahead (FILE *fp)
if (fp-state == 4 /* WR */ || fp-rp = fp-wp)
return 0;
return fp-wp - fp-rp;
-#elif defined SLOW_BUT_NO_HACKS /* users can define this */
- abort ();
- return 0;
#else
- #error Please port gnulib freadahead.c to your platform! Look at the
definition of fflush, fread, ungetc on your system, then report this to
bug-gnulib.
+ return -1;
#endif
}
diff --git a/lib/freadahead.h b/lib/freadahead.h
index d874602..ea0aac7 100644
--- a/lib/freadahead.h
+++ b/lib/freadahead.h
@@ -26,6 +26,8 @@ extern C {
This includes both the bytes that have been read from the underlying input
source and the bytes that have been pushed back through 'ungetc'.
+ Return (size_t) -1 if the number of bytes is not known.
+
If this number is 0 and the stream is not currently writing,
fflush (STREAM) is known to be a no-op.
diff --git a/lib/freadseek.c b/lib/freadseek.c
index 4145173..66318f7 100644
--- a/lib/freadseek.c
+++ b/lib/freadseek.c
@@ -78,6 +78,8 @@ freadseek (FILE *fp, size_t offset)
/* Seek over the already read and buffered input as quickly as possible,
without doing any system calls. */
total_buffered = freadahead (fp);
+ if (total_buffered == (size_t) -1)
+total_buffered = 0;
/* This loop is usually executed at most twice: once for ungetc buffer (if
present) and once for the main buffer. */
while (total_buffered 0)
Re: [PATCH] maint.mk: fix VPATH issues
Hi Jim! Maybe my question below was not visible. I'd like to know what option you prefer. Le 8 juin 2012 à 14:59, Akim Demaille a écrit : Hi! Le 8 juin 2012 à 14:20, Jim Meyering a écrit : One question: ... @@ -89,15 +110,23 @@ trap 'exit $?' 1 2 13 15 # We must build using sources for which --version reports the # just-released version number, not some string like 7.6.18-20761. # That version string propagates into all documentation. +set -e git checkout -b $tmp_branch v$version -ok=0 -./bootstrap ./configure make make web-manual ok=1 -test $ok = 1 || exit 1 - -tmp=$(mktemp -d --tmpdir=. web-doc-update.XX) || exit 1 +git submodule update --recursive +./bootstrap I like to avoid using pwd, because it can fail (admittedly unlikely, but...). Did you consider just doing the cd and those four commands in a sub-shell, instead? Actually I lost trust in subshells :( It's too hard to have a shell script fail from a subshell (calling your die does not suffice). #! /bin/sh set -e ( set -e exit 42 echo end ) echo done ($?) $ sh /tmp/subsh.sh done (42) I would have expected the outer set -e to be effective. But I can check $? at the end if you prefer, and go with (). Right above. Should I stick to pwd (my preference), or do you prefer a sub-shell? (Also, in some of my scripts I issue GNU Make-like entering messages for sake of Emacs, so using cd $cwd became more natural to me than relying on subshells) +srcdir=$(pwd) +cd $builddir + ./config.status --recheck + ./config.status + make + make web-manual +cd $srcdir +set +e + +tmp=$(mktemp -d web-doc-update.XX) || exit 1 ( cd $tmp \ cvs -d $u...@cvs.sv.gnu.org:/webcvs/$pkg co $pkg ) -rsync -avP doc/manual/ $tmp/$pkg/manual +rsync -avP $builddir/doc/manual/ $tmp/$pkg/manual
Re: gnulib portability issues
On 06/09/2012 10:25 PM, Rich Felker wrote: While fixing the underlying freadahead function would be nice, it might be better to make sense of WHY it's needed/wanted, if it's even actually useful, and how to avoid the need for it in the first place. GNU M4 (at least the master branch, although it has not yet been released as m4 2.0) _wants_ to use freadahead, because it provides at least a 10% speedup in operation. It _really is_ more efficient to peek at the current buffer in one function call than it is to call multiple fgetc_unlocked(), in order to rapidly search for the next character of interest. If nothing else, you would be wise following the lead of Dragonfly and providing an internal __freadahead function with the semantics that gnulib wants, if you don't want gnulib messing around with FILE* internals directly, because it really does provide noticeable improvements. Furthermore, I'm considering writing a proposal for the next version of POSIX to standardize several of the stdio functions currently provided by gnulib, along with rationale why they are useful and how they can be used to speed up programs. The fact that gnulib is an existing implementation on top of multiple stdio implementations should be reason enough to treat it as something worth making standard. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] maint.mk: fix VPATH issues
Akim Demaille wrote: Hi Jim! Maybe my question below was not visible. I'd like to know what option you prefer. ... I like to avoid using pwd, because it can fail (admittedly unlikely, but...). Did you consider just doing the cd and those four commands in a sub-shell, instead? Actually I lost trust in subshells :( It's too hard to have a shell script fail from a subshell (calling your die does not suffice). #! /bin/sh set -e ( set -e exit 42 echo end ) echo done ($?) $ sh /tmp/subsh.sh done (42) I would have expected the outer set -e to be effective. But I can check $? at the end if you prefer, and go with (). Right above. Should I stick to pwd (my preference), or do you prefer a sub-shell? Hi Akim, You're welcome to use pwd. set -e is in effect, so pwd failure will be caught, and changing the working directory in a script like this is not a problem. (Also, in some of my scripts I issue GNU Make-like entering messages for sake of Emacs, so using cd $cwd became more natural to me than relying on subshells) +srcdir=$(pwd) +cd $builddir + ./config.status --recheck + ./config.status + make + make web-manual +cd $srcdir +set +e + +tmp=$(mktemp -d web-doc-update.XX) || exit 1 ( cd $tmp \ cvs -d $u...@cvs.sv.gnu.org:/webcvs/$pkg co $pkg ) -rsync -avP doc/manual/ $tmp/$pkg/manual +rsync -avP $builddir/doc/manual/ $tmp/$pkg/manual
Re: gnulib portability issues
On 06/10/2012 06:43 AM, Rich Felker wrote: Come to think of it, a variant might even work for seekable files. Use dup2 to move the file descriptor somewhere else. Close the fd. Keep reading until error, and count the bytes read. Then ungetc all the bytes that you read, in reverse order, and restore the file descriptor. Of course ISO C doesn't guarantee this, but it should be fairly portable in practice. No, ungetc normally can only unget one character. musl is fairly unique in allowing you to unget more, Wrong. Pretty much every libc out there lets you ungetc() more than one byte. It's just that no one exploits that fact, because ISO C99 doesn't guarantee that it will work, and POSIX hasn't added any wording to require it to work either. In fact, most implementations of fscanf() use more than one ungetc() when encountering multi-byte ambiguous inputs. For example, when parsing %g against the partial input 1.e+, whether you push back the multiple character sequence e+ or consume it in addition to the next byte depends on whether the 5th byte is numeric. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gnulib portability issues
On Mon, Jun 11, 2012 at 06:10:02AM -0600, Eric Blake wrote: On 06/09/2012 10:25 PM, Rich Felker wrote: While fixing the underlying freadahead function would be nice, it might be better to make sense of WHY it's needed/wanted, if it's even actually useful, and how to avoid the need for it in the first place. GNU M4 (at least the master branch, although it has not yet been released as m4 2.0) _wants_ to use freadahead, because it provides at least a 10% speedup in operation. It _really is_ more efficient to peek at the current buffer in one function call than it is to call multiple fgetc_unlocked(), in order to rapidly search for the next character of interest. Can you explain how knowing the _number_ of buffered characters helps you find the next character of interest efficiently? If you're going to have to read them into an application-side buffer anyway to inspect them, whether they were already buffered in stdio is fairly unimportant.. I'm not criticizing your claim, but asking in the interest of whether there's perhaps an equally efficient, portable way to do this. If nothing else, you would be wise following the lead of Dragonfly and providing an internal __freadahead function with the semantics that gnulib wants, if you don't want gnulib messing around with FILE* internals directly, because it really does provide noticeable improvements. Since (correct me if I'm wrong on this) the goal of gnulib seems to be making programs that use it extremely portable, there needs to be a portable fallback solution regardless of what solution ends up being best with musl. So far there are the options of the ugly dup/dup2 mess to implement a pseudo-freadahead (that only returns 0/1) or (I think this might be better) having other interfaces (and application programs) avoid using freadahead when it's not available. As for musl, would adding __freadahead be sufficient to make it use __freadahead, or does gnulib hard-code knowledge about which systems have which stdio extension functions? Rich
Re: gnulib portability issues
On Mon, Jun 11, 2012 at 06:13:03AM -0600, Eric Blake wrote: On 06/10/2012 06:43 AM, Rich Felker wrote: Come to think of it, a variant might even work for seekable files. Use dup2 to move the file descriptor somewhere else. Close the fd. Keep reading until error, and count the bytes read. Then ungetc all the bytes that you read, in reverse order, and restore the file descriptor. Of course ISO C doesn't guarantee this, but it should be fairly portable in practice. No, ungetc normally can only unget one character. musl is fairly unique in allowing you to unget more, Wrong. Pretty much every libc out there lets you ungetc() more than one byte. It's just that no one exploits that fact, because ISO C99 doesn't guarantee that it will work, and POSIX hasn't added any wording to require it to work either. I've seen at least one implementation (can't remember which now; uclibc perhaps?) that actually went to some trouble to prevent you from ungetting more than one character. In any case, the reason you cannot unget multiple characters is not just arbitrary; it's that you can't make assumptions about whether/how the implementation is using the buffer, and whether there's space in the buffer for additional characters. For instance an implementation that wants to keep the buffer unmodified (to allow seek-in-buffer, or if the buffer is a read-only mapping of the underlying file) will need additional space outside the main buffer to store unget, and you have no idea how much additional space is available. Other implementations (musl included) will put the characters directly back into the buffer (musl reserves some extra space just before the buffer for unget on an empty buffer), but you still can't be sure how much is available at any given time. Fortunately ungetc does not invoke UB if you try to unget too much, though; it reports the error. In fact, most implementations of fscanf() use more than one ungetc() when encountering multi-byte ambiguous inputs. For example, when parsing %g against the partial input 1.e+, whether you push back the multiple character sequence e+ or consume it in addition to the next byte depends on whether the 5th byte is numeric. The behavior you are describing is a bug in glibc. scanf cannot push back the e+. Per the C standard, if the next character is not a digit, you must push back only that next character (consuming the e+) and return with a matching failure. The relevant language (from 7.19.6.2) is: An input item is read from the stream, unless the specification includes an n specifier. An input item is defined as the longest sequence of input characters which does not exceed any specified field width and which is, or is a prefix of, a matching input sequence.251) The first character, if any, after the input item remains unread. 251) fscanf pushes back at most one input character onto the input stream. Therefore, some sequences that are acceptable to strtod, strtol, etc., are unacceptable to fscanf. Or, you can hear it from Fred J. Tydeman, Vice-chair of PL22.11: http://newsgroups.derkeiler.com/Archive/Comp/comp.std.c/2009-09/msg00045.html There is an open glibc bug report on this that has a chance of finally getting fixed now that Drepper is gone: http://sourceware.org/bugzilla/show_bug.cgi?id=12701 Rich
Re: gnulib portability issues
On 06/11/2012 06:54 AM, Rich Felker wrote: GNU M4 (at least the master branch, although it has not yet been released as m4 2.0) _wants_ to use freadahead, because it provides at least a 10% speedup in operation. It _really is_ more efficient to peek at the current buffer in one function call than it is to call multiple fgetc_unlocked(), in order to rapidly search for the next character of interest. Actually, m4 uses freadptr(), not freadahead(), and _does_ fall back to slower code when freadptr() returns NULL. But as noted in the gnulib code for the two functions, freadahead() can be as simple as whether freadptr() returns a non-NULL value. I think a 0/1 freadahead() would work, but the speedup comes from providing an freadptr() that actually reads ahead. Can you explain how knowing the _number_ of buffered characters helps you find the next character of interest efficiently? It doesn't. Rather, the speedup comes from the ability to peek into that buffer in advance, using freadptr(), so that you can use strchr(), strstr(), or other search functions on the buffer, followed by an fread() of the appropriate size, all in order to minimize the number of function calls without reading past the ISO C99 1-byte ungetc() portability limit. Hence the SLOW_BUT_NO_HACKS definition that loses out on the speedup if freadptr() always returns NULL (at which point freadahead() could be treated as always returning 0, implying that there is no read-ahead buffer). As for musl, would adding __freadahead be sufficient to make it use __freadahead, or does gnulib hard-code knowledge about which systems have which stdio extension functions? Depending on the function name you choose, we would have to add an m4 check to see if __freadahead() is defined; but once we know the name of the function to check for at configure time, then it is quite simple to code up gnulib's freadahead.c to call into the internal __freadahead() function of libc, when one exists. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: gnulib portability issues
On Mon, Jun 11, 2012 at 07:14:56AM -0600, Eric Blake wrote: On 06/11/2012 06:54 AM, Rich Felker wrote: GNU M4 (at least the master branch, although it has not yet been released as m4 2.0) _wants_ to use freadahead, because it provides at least a 10% speedup in operation. It _really is_ more efficient to peek at the current buffer in one function call than it is to call multiple fgetc_unlocked(), in order to rapidly search for the next character of interest. Actually, m4 uses freadptr(), not freadahead(), and _does_ fall back to OK that makes a lot more sense. But if your goal is to read up until the next character in a particular set of special characters, why not fscanf(f, %100[^xyz], ...) with 100 replaced by your buffer size and xyz replaced by the specials? If fscanf is too slow, it seems like this is a QOI bug in fscanf (I'll admit mine is too slow here), but it seems like the right way to do this operation in a way that _can_ be fast if the underlying library handles it well. Can you explain how knowing the _number_ of buffered characters helps you find the next character of interest efficiently? It doesn't. Rather, the speedup comes from the ability to peek into that buffer in advance, using freadptr(), so that you can use strchr(), strstr(), or other search functions on the buffer, followed by an fread() of the appropriate size, all in order to minimize the number of function calls without reading past the ISO C99 1-byte ungetc() BTW if you're going to propose something to POSIX, I think a variant of getdelim with a scanset rather than a single delimiter character might be a cleaner proposal.. Note that it could be implemented in terms of fscanf and %m[...] on systems that don't have it but which already conform to POSIX 2008. As for musl, would adding __freadahead be sufficient to make it use __freadahead, or does gnulib hard-code knowledge about which systems have which stdio extension functions? Depending on the function name you choose, we would have to add an m4 check to see if __freadahead() is defined; but once we know the name of the function to check for at configure time, then it is quite simple to code up gnulib's freadahead.c to call into the internal __freadahead() function of libc, when one exists. So right now, for DragonFly, it's just hard-coded? If you're willing to put in a test for it, I'm willing to add the function. Rich
Re: gnulib portability issues
On 06/11/2012 07:19 AM, Rich Felker wrote: But if your goal is to read up until the next character in a particular set of special characters, why not fscanf(f, %100[^xyz], ...) with 100 replaced by your buffer size and xyz replaced by the specials? Because fscanf() is broken by design. M4 refuses to use it, because there is no portable way to use it on numeric parsing while still detecting overflow, and because gnulib refuses to implement an fscanf() replacement that works around the many different libc bugs in fscanf() compliance because *scanf is so broken by design. Depending on the function name you choose, we would have to add an m4 check to see if __freadahead() is defined; but once we know the name of the function to check for at configure time, then it is quite simple to code up gnulib's freadahead.c to call into the internal __freadahead() function of libc, when one exists. So right now, for DragonFly, it's just hard-coded? If you're willing to put in a test for it, I'm willing to add the function. Yes, we are willing to do a configure-time link test for any internal function name you are willing to give us. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Slight typographical improvements to README-release
On 29 May 2012 16:01, Paul Eggert egg...@cs.ucla.edu wrote: On 05/29/2012 06:11 AM, Reuben Thomas wrote: I find UTF-8 to be a great boon precisely for making plain text more legible. UTF-8 is sometimes necessary and usually works, but even today it fails often enough that I'd rather avoid it if it's merely a minor style issue such as arrows. Fair enough. Revised patch: --- a/top/README-release +++ b/top/README-release @@ -73,11 +73,16 @@ Once all the builds and tests have passed, announcement link in the email message. From here: + https://savannah.gnu.org/projects/@PACKAGE@/ - click on submit news, then write something like the following: + + click on Submit news, then write something like the following: (If there is no such button, then enable News for the project via - the Main - Select Features menu item, or via this link: - https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=@PACKAGE@) + the Main-Select Features menu item, or via this link: + + https://savannah.gnu.org/project/admin/editgroupfeatures.php?group=@PACKAGE@ + + ) Subject: @PACKAGE@-X.Y released [stable] +verbatim+ @@ -85,6 +90,7 @@ Once all the builds and tests have passed, -verbatim- Then go here to approve it: + https://savannah.gnu.org/news/approve.php?group=@PACKAGE@ * Send the announcement email message. -- 1.7.9.5 -- http://rrt.sc3d.org
Re: Why require SLOW_BUT_NO_HACKS for stubs?
On Sun, 10 Jun 2012 19:00:54 -0700 Paul Eggert egg...@cs.ucla.edu wrote: On 06/09/2012 11:05 PM, Isaac Dunham wrote: Is there any reason not to merge Performance, surely. But if there's consensus that performance does not matter that much with musl, perhaps we should default to the slow version with musl. The test as it stands is error out on unsupported platforms unless user specifies to use slow method. My proposal is On unsupported platforms, use the slow method instead of erroring out. All supported platforms are unaffected. Is there any simple way to tell at compile-time, or at configure-time, that musl is being used? That would help us distinguish musl (where being slow is acceptable) from other platforms (which may not want that). First, the proposal is Run slow anywhere current code would #error, not default to slow code. Second, officially, no. musl is designed for standards conformance, and the maintainer takes the perspective that #ifdef should be reserved for non-standard-conformant libc versions. Unofficially, I can think of a few oddities: strl* are supported with -D_BSD_SOURCE, while __linux__ will be defined; almost all symbols use the function name; only SUSv4 is supported with _XOPEN_SOURCE (so -D_XOPEN_SOURCE=600 with unistd.h still gives _XOPEN_VERSION=700). None of these are guaranteed to stay the same, though no _XOPEN_VERSION less than 700 is likely to be supported. Isaac Dunham
