Re: [PATCH] Use a hash rather than a linked-list for cycle check in cp
> Hi Bo, > > Thanks for that patch. > > However, let's see if Cai Xianchao and Li Zefan > are still working on rewriting cp to use openat-style functions. > I am sorry for replying so late. :-[ I am busy recently, so the development speed is very slow. I have finished the work as follows: 1, Find out which functions need rewrited using *at and fts function. 2, Design the method to copy directory. > http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12041 > > Because once cp is rewritten the way I outlined later in > that thread, there will be no need for your patch. > > By the way, I do still plan to add a --total option to df. > Li Zefan revived an old patch to that effect, but it needs > some work and perhaps a test or two. > > > ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
probleme
Bonjour; j'ai deux principaux problèmes qui me dérangent: -pilote de carte graphique non détecté : aucune accélération graphique et Kubuntu ignore ma carte graphique Nvidia Ge Force7100 Gs -pas de son : je ne peus pas avoir du son. Merci. J'attend votre Réponse. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Feature request - base64 Filename Safe Alphabet
After being burned by using `head -c6 /dev/urandom | base64` as part of a directory name, I realised that it would be useful if base64 had an option to generate URL and Filename safe encodings, as specified in RFC 3548 section 4. This would make cat FILE | base64 --filename-safe equivalent to cat FILE | base64 | tr '+/' '-_' using the current coreutils tools. signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
chcon, runcon: --help output did not include bug reporting address
I noticed that chcon and runcon were exempted from some of the tests in misc/help-version. That exemption (probably back from when I added preliminary versions) was hiding this small defect: >From bbc0cb0f37641b1779170b3e15bd3479fb250fed Mon Sep 17 00:00:00 2001 From: Jim Meyering <[EMAIL PROTECTED]> Date: Sat, 26 Apr 2008 09:14:55 +0200 Subject: [PATCH] chcon, runcon: make --help print the bug-reporting address * src/chcon.c (usage): Use emit_bug_reporting_address. * src/runcon.c (usage): Likewise. * tests/misc/help-version: Don't exempt chcon and runcon. * NEWS: Mention this. Signed-off-by: Jim Meyering <[EMAIL PROTECTED]> --- NEWS|2 ++ src/chcon.c |1 + src/runcon.c|1 + tests/misc/help-version |2 -- 4 files changed, 4 insertions(+), 2 deletions(-) diff --git a/NEWS b/NEWS index 18d9851..faf2b1d 100644 --- a/NEWS +++ b/NEWS @@ -4,6 +4,8 @@ GNU coreutils NEWS-*- outline -*- ** Bug fixes + chcon, runcon: --help output now includes the bug-reporting address + id with no options now prints the SELinux context only when invoked with no USERNAME argument. diff --git a/src/chcon.c b/src/chcon.c index 4f091a3..01bb4ad 100644 --- a/src/chcon.c +++ b/src/chcon.c @@ -400,6 +400,7 @@ one takes effect.\n\ "), stdout); fputs (HELP_OPTION_DESCRIPTION, stdout); fputs (VERSION_OPTION_DESCRIPTION, stdout); + emit_bug_reporting_address (); } exit (status); } diff --git a/src/runcon.c b/src/runcon.c index 85e5f59..4188601 100644 --- a/src/runcon.c +++ b/src/runcon.c @@ -85,6 +85,7 @@ With neither CONTEXT nor COMMAND, print the current security context.\n\ "), stdout); fputs (HELP_OPTION_DESCRIPTION, stdout); fputs (VERSION_OPTION_DESCRIPTION, stdout); + emit_bug_reporting_address (); } exit (status); } diff --git a/tests/misc/help-version b/tests/misc/help-version index 25364df..f383fa6 100755 --- a/tests/misc/help-version +++ b/tests/misc/help-version @@ -47,8 +47,6 @@ for lang in C fr da; do # Skip `test'; it doesn't accept --help or --version. test $i = test && continue; -test $i = chcon && continue; -test $i = runcon && continue; # false fails even when invoked with --help or --version. if test $i = false; then -- 1.5.5.1.68.gbdcd8 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Christopher Kerr wrote: > After being burned by using `head -c6 /dev/urandom | base64` as part of a > directory name, I realised that it would be useful if base64 had an option to > generate URL and Filename safe encodings, as specified in RFC 3548 section 4. > > This would make > cat FILE | base64 --filename-safe > equivalent to > cat FILE | base64 | tr '+/' '-_' Not a bad idea. I've needed stuff like that before: http://www.pixelbeat.org/libs/base64.c Perhaps `tr '+/' '._'` would be better so that you don't need to worry about "-" at the start of a filename? Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Christopher Kerr wrote: > After being burned by using `head -c6 /dev/urandom | base64` as part of a > directory name, I realised that it would be useful if base64 had an option to > generate URL and Filename safe encodings, as specified in RFC 3548 section 4. > > This would make > cat FILE | base64 --filename-safe > equivalent to > cat FILE | base64 | tr '+/' '-_' > using the current coreutils tools. Hi, lib/base64.c looks fairly easy to pull apart so that current functions base64_encode and base64_decode become wrappers around internal functions that take an additional argument describing the alphabet. New functions base64_encode_filesafe and base64_decode_filesafe could then be added without breaking the pre-existing interface or duplicating a lot of code. B ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Pádraig Brady on 4/29/2008 6:59 AM: | Perhaps `tr '+/' '._'` would be better so that | you don't need to worry about "-" at the start of a filename? Which is worse - a file that can be confused with an option, or a file that is hidden by default from fnmatch? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgXHW4ACgkQ84KuGfSFAYD33wCgzj9rA1X48T1AHMoxWRtoCDRT AfsAn1jesOXoe3gkWszZiMxnmOD/av/y =OBbi -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Pádraig Brady wrote: > Perhaps `tr '+/' '._'` would be better so that > you don't need to worry about "-" at the start of a filename? I'm think `.' at the beginning of a filename also has the potential to give users unexpected behavior. Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Bo Borgerson <[EMAIL PROTECTED]> wrote: > Christopher Kerr wrote: >> After being burned by using `head -c6 /dev/urandom | base64` as part of a >> directory name, I realised that it would be useful if base64 had an option to >> generate URL and Filename safe encodings, as specified in RFC 3548 section 4. >> >> This would make >> cat FILE | base64 --filename-safe >> equivalent to >> cat FILE | base64 | tr '+/' '-_' >> using the current coreutils tools. > > Hi, > > lib/base64.c looks fairly easy to pull apart so that current functions > base64_encode and base64_decode become wrappers around internal > functions that take an additional argument describing the alphabet. > > New functions base64_encode_filesafe and base64_decode_filesafe could > then be added without breaking the pre-existing interface or duplicating > a lot of code. Beware: there are two versions of base64.c. The one in gnulib and another in coreutils/gl/lib. Simon and I have been thinking about how to merge these two for some time, but I haven't found time since our last exchange. Volunteers welcome ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Christopher Kerr <[EMAIL PROTECTED]> wrote: > After being burned by using `head -c6 /dev/urandom | base64` as part of a > directory name, I realised that it would be useful if base64 had an option to > generate URL and Filename safe encodings, as specified in RFC 3548 section 4. > > This would make > cat FILE | base64 --filename-safe > equivalent to > cat FILE | base64 | tr '+/' '-_' > using the current coreutils tools. Christopher, In case you read via means other than direct mail, [because my reply to you bounced] this is to inform you that your mail server (Cambridge's) is *still* rejecting mail from my static IP based on a single bogus MAPS RBL entry that includes the entire 82.230.0.0/16 network: <[EMAIL PROTECTED]>: host mx.cam.ac.uk[131.111.8.149] said: 550-82.230.74.64 is listed at rbl-plus.mail-abuse.ja.net; See 550 http://mail-abuse.com/cgi-bin/lookup?82.230.74.64 (in reply to RCPT TO command) I've encountered/reported the same problem numerous times for your domain over the last year or so. Maybe you can help someone understand that this is not good for the University's reputation. Jim ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Bo Borgerson wrote: > Pádraig Brady wrote: >> Perhaps `tr '+/' '._'` would be better so that >> you don't need to worry about "-" at the start of a filename? > > > I'm think `.' at the beginning of a filename also has the potential to > give users unexpected behavior. Doh! never thought of that :) tr '+/' '._' => hidden files tr '+/' '-_' => awkward option clashes tr '/' '_' => not POSIX portable ho hum, the awkward option clashes is probably best. cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI, 11 mostly-test-related patches
Jim Meyering meyering.net> writes: > > ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4 > > Undefined subroutine &Test::test_vector called at tests/mk-script line 44. > > ./bootstrap: aclocal --force -I m4 ... > > Thanks for reporting that. > Would you please pull the latest to see if Bo's patch fixed it? > Yes, the warning went away with a ./bootstrap on the latest pull. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: FYI, 11 mostly-test-related patches
Eric Blake <[EMAIL PROTECTED]> wrote: > Jim Meyering meyering.net> writes: >> > ./bootstrap: m4/xsize.m4 overrides ._bootmp2/m4/xsize.m4 >> > Undefined subroutine &Test::test_vector called at tests/mk-script line 44. >> > ./bootstrap: aclocal --force -I m4 ... >> >> Thanks for reporting that. >> Would you please pull the latest to see if Bo's patch fixed it? > > Yes, the warning went away with a ./bootstrap on the latest pull. Good. Thanks! ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Pádraig Brady draigBrady.com> writes: > tr '+/' '._' => hidden files > tr '+/' '-_' => awkward option clashes > tr '/' '_' => not POSIX portable > > ho hum, the awkward option clashes is probably best. You can always use ./ prefix to avoid option clashes, and for most tools, you can also use -- strategically. Also, while '+' is not allowed in short 8.3 DOS file names, these days, all practical platforms that target FAT file systems also support long file names where '+' is perfectly fine: http://www.gnu.org/software/autoconf/manual/autoconf.html#File-System- Conventions Besides, think of 'g++', as an example of using + in file names. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Pádraig Brady wrote: > tr '+/' '._' => hidden files > tr '+/' '-_' => awkward option clashes > tr '/' '_' => not POSIX portable > > ho hum, the awkward option clashes is probably best. Yeah, there's no really ideal option, is there... It almost might be nice to have a totally user-configurable alphabet. Something like: $ base64 --62=- --63=_ Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
On 04/29/2008 4:47:53 PM +0200, Bo Borgerson <[EMAIL PROTECTED]> wrote: Pádraig Brady wrote: tr '+/' '._' => hidden files tr '+/' '-_' => awkward option clashes tr '/' '_' => not POSIX portable AFAIK, POSIX filenames allow any character except the slash character and the null byte. ho hum, the awkward option clashes is probably best. Especially when this is the RFC recommanded translation. This would avoid confusing people with multiple translation sets and stick to the RFC (considered by many as the authoritative translation) Yeah, there's no really ideal option, is there... it is very easy to escape a dash character, either manually (the tab key makes it very easy with some shells), or in scripts (all languages have a shell escape function). It almost might be nice to have a totally user-configurable alphabet. IMHO this is a bad idea because this would confuse even more people trying to use it. We could end with dozen of incompatible, non-portable shell scripts, with none using the same translation set. A totally user-configurable alphabet is always possible with "base64 | tr" which is designed to do that. Gabriel ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Gabriel Barazer wrote: > AFAIK, POSIX filenames allow any character except the slash character > and the null byte. > > Especially when this is the RFC recommanded translation. This would > avoid confusing people with multiple translation sets and stick to the > RFC (considered by many as the authoritative translation) > > it is very easy to escape a dash character, either manually (the tab key > makes it very easy with some shells), or in scripts (all languages have > a shell escape function). > > IMHO this is a bad idea because this would confuse even more people > trying to use it. We could end with dozen of incompatible, non-portable > shell scripts, with none using the same translation set. > > A totally user-configurable alphabet is always possible with "base64 | > tr" which is designed to do that. Yes, you're absolutely right. All very good points. I do still think the original poster's suggestion of a `--filename-safe' option is worth considering. As you mentioned the inclusion of such a base64 alphabet in the RFC means it's likely to be a widely accepted alternative. Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Feature request - base64 Filename Safe Alphabet
Gabriel Barazer <[EMAIL PROTECTED]> writes: > On 04/29/2008 4:47:53 PM +0200, Bo Borgerson <[EMAIL PROTECTED]> wrote: >> Pádraig Brady wrote: >>> tr '+/' '._' => hidden files >>> tr '+/' '-_' => awkward option clashes >>> tr '/' '_' => not POSIX portable > > AFAIK, POSIX filenames allow any character except the slash character and > the null byte. That is actually a Unix property. For a portable POSIX file name the alphabet is much more restricted: [A-Za-z0-9_.-], without leading hyphen. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils test coverage
If you're reading this list, you probably noticed that some kind souls at Stanford uncovered a surprising number of bugs in coreutils recently. Part of their analysis was coverage-related, and they produced these coverage reports: http://keeda.stanford.edu/~cristic/coreutils-dev-tests/src/ In case anyone is interested in improving test coverage, that gives some obvious starting points. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils test coverage
Jim Meyering wrote: > If you're reading this list, you probably noticed that some kind > souls at Stanford uncovered a surprising number of bugs in coreutils > recently. Part of their analysis was coverage-related, and they > produced these coverage reports: > > http://keeda.stanford.edu/~cristic/coreutils-dev-tests/src/ > > In case anyone is interested in improving test coverage, > that gives some obvious starting points. How cool! That's a really useful tool. I wonder if it might be possible to include some instructions for producing a coverage report like that in the project somewhere... maybe in the HACKING file? Bo ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils test coverage
Bo Borgerson <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> If you're reading this list, you probably noticed that some kind >> souls at Stanford uncovered a surprising number of bugs in coreutils >> recently. Part of their analysis was coverage-related, and they >> produced these coverage reports: >> >> http://keeda.stanford.edu/~cristic/coreutils-dev-tests/src/ >> >> In case anyone is interested in improving test coverage, >> that gives some obvious starting points. > > How cool! > > That's a really useful tool. I wonder if it might be possible to > include some instructions for producing a coverage report like that in > the project somewhere... maybe in the HACKING file? I've only just learned of this, too: http://ltp.sourceforge.net/coverage/lcov.php I was just waiting for you to volunteer ;-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils test coverage
Hi, > How cool! > > That's a really useful tool. I wonder if it might be possible to > include some instructions for producing a coverage report like that in > the project somewhere... maybe in the HACKING file? It is fairly straightforward, although lcov has some quirks resolving path names which I haven't really looked into. I have also noticed it get very unhappy if stray .gcov files are lying around, but haven't debugged this issue. Here is the process I use for generating those results. First, generate the coverage information: -- # configure with coverage information ./configure CFLAGS="-g -fprofile-arcs -ftest-coverage" make # run whatever tests you want, i.e.: make check -- Second, generate lcov output. I use the following unpolished script, which takes an optional argument for keeping separate .info files (lcov's internal parsing of the gcov data) and output -html directories. The script expects to be run from the top level coreutils directory so that the lcov genhtml script resolves pathnames appropriately. -- #!/bin/sh if [ [EMAIL PROTECTED] -eq 0 ]; then PREFIX="lcov" elif [ [EMAIL PROTECTED] -eq 1 ]; then PREFIX="$1" else echo "Usage: $0 [prefix]" exit 1 fi # prevent stray gcov files find . -name '*.gcov' | xargs rm -f rm -rf $PREFIX-*.info $PREFIX-html if (! lcov -t coreutils -q -d lib -b lib -o $PREFIX-lib.info -c); then echo "ERROR: lcov failed" exit 1 fi if (! lcov -t coreutils -q -d src -b src -o $PREFIX-src.info -c); then echo "ERROR: lcov failed" exit 1 fi genhtml -p `pwd` -t coreutils -q --output-directory $PREFIX-html $PREFIX-lib.info $PREFIX-src.info -- I also have an additional script which munges the lcov output to make the tables sortable but this is pretty gross. When I get a chance I would prefer to push this back to lcov as an extra option, although if you really want it I can pass it on. - Daniel ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
speed up getndelim2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Wow! Check out the speedup with this patch, comparing an -O2 /bin/cut
pre-patch against an unoptimized -g cut post-patch, and that's even with
running /bin/cut second so it benefits from any file system caching effects.
$ dd count=20k data
20480+0 records in
20480+0 records out
10485760 bytes (10 MB) copied, 2.83 s, 3.7 MB/s
$ time (~/coreutils/src/cut -f 2-3 < data > data2)
real0m4.168s
user0m3.952s
sys 0m0.109s
$ time (/bin/cut -f 2-3 < data > data1)
real0m6.194s
user0m6.109s
sys 0m0.108s
$ cmp data1 data2
$
And all I did was make getndelim2 smarter to process data in blocks
instead of bytes, by exploiting freadptr and memchr2, and cut is roughly
40% faster.
- --
Don't work too hard, make some time for fun as well!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkgX+YcACgkQ84KuGfSFAYDM6QCfaPNXI3S29gizPBmMc91mX+05
XMYAn0iWeiBoIVOgkn/8ClJMHJD4bcHR
=fmzx
-END PGP SIGNATURE-
>From 032b1ce80ba621afc4f241570e0ae6716a59ce60 Mon Sep 17 00:00:00 2001
From: Eric Blake <[EMAIL PROTECTED]>
Date: Tue, 29 Apr 2008 11:59:35 -0600
Subject: [PATCH] Optimize getndelim2 to use block operations when possible.
* modules/getndelim2 (Depends-on): Add stdbool, freadptr,
freadseek, and memchr2.
* lib/getndelim2.c (getndelim2): Use them for block reads.
Signed-off-by: Eric Blake <[EMAIL PROTECTED]>
---
ChangeLog |7
lib/getndelim2.c | 79 +++
modules/getndelim2 |4 ++
3 files changed, 71 insertions(+), 19 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index ab0e292..5cf1dd3 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2008-04-29 Eric Blake <[EMAIL PROTECTED]>
+
+ Optimize getndelim2 to use block operations when possible.
+ * modules/getndelim2 (Depends-on): Add stdbool, freadptr,
+ freadseek, and memchr2.
+ * lib/getndelim2.c (getndelim2): Use them for block reads.
+
2008-04-29 Bruno Haible <[EMAIL PROTECTED]>
* m4/inet_ntop.m4 (gl_INET_NTOP): Require gl_USE_SYSTEM_EXTENSIONS.
diff --git a/lib/getndelim2.c b/lib/getndelim2.c
index 8930a5b..be34e40 100644
--- a/lib/getndelim2.c
+++ b/lib/getndelim2.c
@@ -23,8 +23,10 @@
#include "getndelim2.h"
-#include
+#include
#include
+#include
+#include
#if USE_UNLOCKED_IO
# include "unlocked-io.h"
@@ -41,6 +43,10 @@
#include
#include
+#include "freadptr.h"
+#include "freadseek.h"
+#include "memchr2.h"
+
#ifndef SSIZE_MAX
# define SSIZE_MAX ((ssize_t) (SIZE_MAX / 2))
#endif
@@ -63,6 +69,7 @@ getndelim2 (char **lineptr, size_t *linesize, size_t offset,
size_t nmax,
ssize_t bytes_stored = -1;
char *ptr = *lineptr;
size_t size = *linesize;
+ bool done = false;
if (!ptr)
{
@@ -81,23 +88,62 @@ getndelim2 (char **lineptr, size_t *linesize, size_t
offset, size_t nmax,
if (nbytes_avail == 0 && nmax <= size)
goto done;
+ /* Normalize delimiters, since memchr2 doesn't handle EOF. */
+ if (delim1 == EOF)
+delim1 = delim2;
+ else if (delim2 == EOF)
+delim2 = delim1;
+
flockfile (stream);
- for (;;)
+ while (!done)
{
/* Here always ptr + size == read_pos + nbytes_avail. */
int c;
+ const char *buffer;
+ size_t buffer_len;
+
+ buffer = freadptr (stream, &buffer_len);
+ if (buffer)
+ {
+ if (delim1 != EOF)
+ {
+ const char *end = memchr2 (buffer, delim1, delim2, buffer_len);
+ if (end)
+ {
+ buffer_len = end - buffer + 1;
+ done = true;
+ }
+ }
+ }
+ else
+ {
+ c = getc (stream);
+ if (c == EOF)
+ {
+ /* Return partial line, if any. */
+ if (read_pos == ptr)
+ goto unlock_done;
+ else
+ break;
+ }
+ if (c == delim1 || c == delim2)
+ done = true;
+ buffer_len = 1;
+ }
/* We always want at least one byte left in the buffer, since we
always (unless we get an error while reading the first byte)
NUL-terminate the line buffer. */
- if (nbytes_avail < 2 && size < nmax)
+ if (nbytes_avail < 1 + buffer_len && size < nmax)
{
size_t newsize = size < MIN_CHUNK ? size + MIN_CHUNK : 2 * size;
char *newptr;
+ if (newsize < buffer_len)
+ newsize = buffer_len + size;
if (! (size < newsize && newsize <= nmax))
newsize = nmax;
@@ -118,25 +164,20 @@ getndelim2 (char **lineptr, size_t *linesize, size_t
offset, size_t nmax,
read_pos = size - nbytes_avail + ptr;
}
- c = getc (stream);
- if (c == EOF)
+
