Re: [PATCH] New fallocate module

[Pádraig Brady]

Paul Eggert wrote:
> Pádraig Brady  writes:
> 
>> Well libc, kernel or filesystem could return ENOSYS
>> so code using fallocate() has to handle it anyway.
> 
> If memory serves, ordinarily gnulib tries to catch such situations,
> and to substitute a working function when the kernel just has a stub
> that returns ENOSYS.  However, I suppose fallocate is different
> because it can succeed on one filesystem, but fail on the other.  (Is
> that right?)

right.

> If so, then you are right that fallocate-using apps must
> check for ENOSYS always, and it may make sense to do it the way you
> did it, i.e., simply have a stub that returns ENOSYS always.

good.

> However, in this case I suggest having the .h file make it clear that
> fallocate always returns ENOSYS, rather than doing it in the .c file.
> That way, the compiler can optimize out not only the call to
> fallocate, but also the run-time check and error message that is
> printed when fallocate fails due to running out of disk space.  I
> suggest using an inline function for this rather than a macro, if
> possible, as that's a bit cleaner.

good point

> Once support is added for Solaris 10 and earlier then this would get a
> bit more complicated, since an inline function might be a bit
> unwieldy, but that's OK; the optimization would still work on all
> non-Solaris older platforms.


> 
>>> - glibc declares fallocate() in . Therefore gnulib should do the 
>>> same.
>>>   There is no use in creating a file "fallocate.h"; instead, put the 
>>> declarations
>>>   into fcntl.in.h.
>> hmm. I was wondering about that. The reason I chose fallocate.h was
>> for platform independence. Also  needs to be handled
>> independently then.
> 
> I agree with Bruno.  Gnulib should do things the glibc way unless
> there's a good reason otherwise; that simplifies GNU code overall.

OK agreed. I wish FALLOC_FL_KEEP_SIZE was defined in fcntl.h :(
Currently linux/falloc.h has only this define in it.

I'll leave the onus on applications to do:

#if HAVE_LINUX_ALLOC_H
#include 
#endif

Since there is now no fallocate.[ch] I'll figure out how to add
all this to fcntl.in.h

> 
> Looking at the patch I see a few problems with the use of fallocate in
> coreutils/src/copy.c.
> 
> * If HAVE_STRUCT_STAT_ST_BLOCKS, then fallocate can be called even
> when make_holes is nonzero, which surely is a bug.

good catch. Should be "else if" within that ifdef
(should have been originally anyway for performance reasons).

> 
> * I don't see why copy.c bothers to round the destination file size to
> the next multiple of the block size, as fallocate already does that.

Well because with fallocate() in the picture the source file
could have a large allocation (nblocks) but small size.
So the copy would maintain this allocation which I thought
was a desired feature. I should add a comment in any case.

> 
> * Suppose the source file shrinks while it's being copied.  Shouldn't
> copy.c do another fallocate() call after copying is finished, to
> discard the space that was allocated but not needed?

Good point. It would need to do an ftruncate() in that case.

> * copy.c should fall back on a native posix_fallocate if fallocate
> isn't available.

I don't think so, as this will fall back to writing zeros to the disk
in the case where the filesystem/kernel does not support fallocate().
This is a different higher level functionality IMHO.
There was talk of adding a --allocate option to `truncate`,
and that would call posix_fallocate().

> * A possible optimization if HAVE_FALLOCATE || HAVE_POSIX_FALLOCATE:
> copy.c can easily cache whether the most-recently-used file system
> supports fallocate (or posix_fallocate), to avoid using system calls
> that it knows will fail due to ENOSYS.

Seems like a worthwhile optimisation.

thanks!
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] New fallocate module

[Paul Eggert]

Pádraig Brady  writes:

> Well libc, kernel or filesystem could return ENOSYS
> so code using fallocate() has to handle it anyway.

If memory serves, ordinarily gnulib tries to catch such situations,
and to substitute a working function when the kernel just has a stub
that returns ENOSYS.  However, I suppose fallocate is different
because it can succeed on one filesystem, but fail on the other.  (Is
that right?)  If so, then you are right that fallocate-using apps must
check for ENOSYS always, and it may make sense to do it the way you
did it, i.e., simply have a stub that returns ENOSYS always.

However, in this case I suggest having the .h file make it clear that
fallocate always returns ENOSYS, rather than doing it in the .c file.
That way, the compiler can optimize out not only the call to
fallocate, but also the run-time check and error message that is
printed when fallocate fails due to running out of disk space.  I
suggest using an inline function for this rather than a macro, if
possible, as that's a bit cleaner.

Once support is added for Solaris 10 and earlier then this would get a
bit more complicated, since an inline function might be a bit
unwieldy, but that's OK; the optimization would still work on all
non-Solaris older platforms.

>> - glibc declares fallocate() in . Therefore gnulib should do the 
>> same.
>>   There is no use in creating a file "fallocate.h"; instead, put the 
>> declarations
>>   into fcntl.in.h.
>
> hmm. I was wondering about that. The reason I chose fallocate.h was
> for platform independence. Also  needs to be handled
> independently then.

I agree with Bruno.  Gnulib should do things the glibc way unless
there's a good reason otherwise; that simplifies GNU code overall.

Looking at the patch I see a few problems with the use of fallocate in
coreutils/src/copy.c.

* If HAVE_STRUCT_STAT_ST_BLOCKS, then fallocate can be called even
when make_holes is nonzero, which surely is a bug.

* I don't see why copy.c bothers to round the destination file size to
the next multiple of the block size, as fallocate already does that.

* Suppose the source file shrinks while it's being copied.  Shouldn't
copy.c do another fallocate() call after copying is finished, to
discard the space that was allocated but not needed?

* copy.c should fall back on a native posix_fallocate if fallocate
isn't available.

* A possible optimization if HAVE_FALLOCATE || HAVE_POSIX_FALLOCATE:
copy.c can easily cache whether the most-recently-used file system
supports fallocate (or posix_fallocate), to avoid using system calls
that it knows will fail due to ENOSYS.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

[Pádraig Brady]

Ondřej Vašík wrote:
> Pádraig Brady wrote:
>> So that would not run skip(STDOUT_FILENO,...) if count==0.
>> Would this break existing scripts that for example used
>> this command to position a non seekable device?
>>
>>   dd count=0 of=/dev/tape seek=1234
> 
> Thanks for objection, you are right, my patch seems to be not correct
> way as it doesn't run that part and could break something. However - for
> many cases (when file_size && offset < OFF_T_MAX and file seekable)
> buffer allocation is not required in skip(), so it could be handled
> somehow for those cases even without buffer allocation...

Definitely possible to alloc the buffer closer to the actual read().
More invasive though, so I'll let you decide if it's worth it.

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

[Ondřej Vašík]

Pádraig Brady wrote:
> So that would not run skip(STDOUT_FILENO,...) if count==0.
> Would this break existing scripts that for example used
> this command to position a non seekable device?
> 
>   dd count=0 of=/dev/tape seek=1234

Thanks for objection, you are right, my patch seems to be not correct
way as it doesn't run that part and could break something. However - for
many cases (when file_size && offset < OFF_T_MAX and file seekable)
buffer allocation is not required in skip(), so it could be handled
somehow for those cases even without buffer allocation...

Greetings,
 Ondřej


signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] New fallocate module

[Pádraig Brady]

Bruno Haible wrote:
> Hello Pádraig,
> 
> The documentation files you sent document the status before any 'fallocate'
> module is added to gnulib. So I committed them for you:
> 
> 2009-05-21  Pádraig Brady  
> 
>   * doc/glibc-functions/fallocate.texi: New file.
>   * doc/gnulib.texi: Include it.

Thanks a million for looking at this Bruno!

> The fallocate.texi will need a modification that goes along with the
> 'fallocate' module.
> 
>> This is my first gnulib module
> 
> Ok, here are detail comments:
> 
> - fallocate.c should have a GPLv3 copyright header.

oops

> - A rpl_fallocate function that always returns ENOSYS makes no sense for 
> gnulib.
>   In gnulib, we enable a function when we have working code for it. If the
>   replacement can be implemented only on some platforms, we make sure the .h 
> file
>   defines an indicator that users can test with #if or #ifdef.

Well libc, kernel or filesystem could return ENOSYS
so code using fallocate() has to handle it anyway.
I did it like that so gnulib users can call fallocate() unconditionally
for the common optional optimization use case.
Or they can also #if HAVE_FALLOCATE  #endif if desired.

> 
>   In coreutils, the policy is different: coreutils at some places has dummy
>   stubs, and is willing to compile in function calls to these dummy stubs on
>   platforms that lack the particular functionality. Other projects that use
>   gnulib prefer to use a #if around the code that uses the functionality.
> 
> - In fallocate.c, the "#undef fallocate" should go away. It makes it 
> impossible
>   to make a namespace-clean library by adding a
>   #define fallocate libfoo_private_fallocate
>   to config.h.

ok

> - glibc declares fallocate() in . Therefore gnulib should do the 
> same.
>   There is no use in creating a file "fallocate.h"; instead, put the 
> declarations
>   into fcntl.in.h.

hmm. I was wondering about that. The reason I chose fallocate.h was
for platform independence. Also  needs to be handled
independently then.

> - In fallocate.m4 you are doing
> AC_DEFINE([fallocate], [rpl_fallocate], [replacement stub])
>   This define is better done in the .h file (fcntl.in.h in this case).
>   Otherwise you get problems when a platform has an 'fallocate' function.
>   We used that mix of config.h and *.in.h idiom in the beginning, but it
>   turned out to be more maintainable to put the entire replacement code
>   into the *.in.h file.

ok

> 
> - In fallocate.m4 the invocation of AC_TRY_LINK takes some time (it runs
>   the compiler and linker) and therefore should be protected by a cache
>   variable. AC_CACHE_CHECK is your friend.

ok

> 
>> Note also "fallocate()" functionality is available on
>> solaris using the fcntl(fd, F_ALLOCSP, ...) interface.
>> Hopefully this can be wrapped by this fallocate() at
>> some stage.
> 
> Yes, sure, please do this. F_ALLOCSP and F_ALLOCSP64. The more platforms
> a replacement supports, the better.

ok I'll try and get opensolaris to test this

>> Note fallocate() is unfortunately not available on 32 bit
>> fedora 11 at least when AC_SYS_LARGEFILE is used due to:
>> https://bugzilla.redhat.com/show_bug.cgi?id=500487
> 
> IMO this is not worth working around, because it's likely to be fixed
> quickly in glibc.

My thoughts also.

thanks again!
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] New fallocate module

[Bruno Haible]

Hello Pádraig,

The documentation files you sent document the status before any 'fallocate'
module is added to gnulib. So I committed them for you:

2009-05-21  Pádraig Brady  

* doc/glibc-functions/fallocate.texi: New file.
* doc/gnulib.texi: Include it.

The fallocate.texi will need a modification that goes along with the
'fallocate' module.

> This is my first gnulib module

Ok, here are detail comments:

- fallocate.c should have a GPLv3 copyright header.

- A rpl_fallocate function that always returns ENOSYS makes no sense for gnulib.
  In gnulib, we enable a function when we have working code for it. If the
  replacement can be implemented only on some platforms, we make sure the .h 
file
  defines an indicator that users can test with #if or #ifdef.

  In coreutils, the policy is different: coreutils at some places has dummy
  stubs, and is willing to compile in function calls to these dummy stubs on
  platforms that lack the particular functionality. Other projects that use
  gnulib prefer to use a #if around the code that uses the functionality.

- In fallocate.c, the "#undef fallocate" should go away. It makes it impossible
  to make a namespace-clean library by adding a
  #define fallocate libfoo_private_fallocate
  to config.h.

- glibc declares fallocate() in . Therefore gnulib should do the same.
  There is no use in creating a file "fallocate.h"; instead, put the 
declarations
  into fcntl.in.h.

- In fallocate.m4 you are doing
AC_DEFINE([fallocate], [rpl_fallocate], [replacement stub])
  This define is better done in the .h file (fcntl.in.h in this case).
  Otherwise you get problems when a platform has an 'fallocate' function.
  We used that mix of config.h and *.in.h idiom in the beginning, but it
  turned out to be more maintainable to put the entire replacement code
  into the *.in.h file.

- In fallocate.m4 the invocation of AC_TRY_LINK takes some time (it runs
  the compiler and linker) and therefore should be protected by a cache
  variable. AC_CACHE_CHECK is your friend.

> Note also "fallocate()" functionality is available on
> solaris using the fcntl(fd, F_ALLOCSP, ...) interface.
> Hopefully this can be wrapped by this fallocate() at
> some stage.

Yes, sure, please do this. F_ALLOCSP and F_ALLOCSP64. The more platforms
a replacement supports, the better.

> Note fallocate() is unfortunately not available on 32 bit
> fedora 11 at least when AC_SYS_LARGEFILE is used due to:
> https://bugzilla.redhat.com/show_bug.cgi?id=500487

IMO this is not worth working around, because it's likely to be fixed
quickly in glibc.

Bruno


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Human readable sort

[Jim Meyering]

Pádraig Brady wrote:
>>From 75bb07bb620d37d26467ab86ffcf73d47479b358 Mon Sep 17 00:00:00 2001
> From: Michael Speer 
> Date: Mon, 27 Apr 2009 14:51:29 +0100
> Subject: [PATCH] sort: new --human-numeric-sort option to sort KiB MB etc.
>
> * NEWS: Document the new option
> * doc/coreutils.texi (sort invocation): ditto
> * src/sort.c (main): handle the new -human-numeric-sort option (-h).

Please make one small change to that log message:

s/ -human/ --human/

And in the documentation,

  +Sort numerically, as per the @option{--numeric-sort} option,
  +and in addition handle IEC or SI suffixes like MiB, MB etc.
  +Note a mixture of these suffixes is not supported and will
  +be flagged as an error. Also the numbers must be abbreviated unambiguously.
  +I.E. 5000K and 6M will be sorted incorrectly for example.

Eventually, it'd be nice to explain in detail why those
would cause trouble.

Maybe s/unambiguously/consistently/
or   /uniformly/
and mention that it's the inconsistent precision that causes trouble.

Hmm actually those two *are* sorted properly for me:

$ printf '%s\n' 5000K 6M| src/sort --human
5000K
6M

However, these two are not:

$ printf '%s\n' 7000K 6M| src/sort --human
7000K
6M


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

[Pádraig Brady]

Ondřej Vašík wrote:
> Hello,
> as reported in https://bugzilla.redhat.com/show_bug.cgi?id=502026, in dd
> is an unnecessary memory allocation for input block even if input block
> buffer is not needed (skip and count set to 0). Attached patch should
> prevent memory exhaustion error in that very special case. I guess
> mentioning in NEWS is not required in that case...

> diff --git a/src/dd.c b/src/dd.c
> index 3ba616b..be6d544 100644
> --- a/src/dd.c
> +++ b/src/dd.c
> @@ -1553,6 +1553,10 @@ dd_copy (void)
>int exit_status = EXIT_SUCCESS;
>size_t n_bytes_read;
>
> +  /* Do not unnecessarily allocate memory */
> +  if (max_records == 0 && skip_records == 0)
> +return exit_status;

So that would not run skip(STDOUT_FILENO,...) if count==0.
Would this break existing scripts that for example used
this command to position a non seekable device?

  dd count=0 of=/dev/tape seek=1234

cheers,
Pádraig.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Human readable sort

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady wrote:
>> Eric Blake wrote:
>>> Pádraig Brady  draigBrady.com> writes:
> ...
>>> +static int
>>> +find_unit_order (const char *number)
>>> +{
>>> +  static const char orders [UCHAR_LIM] = {
>>> +['K']=1, ['M']=2, ['G']=3, ['T']=4, ['P']=5, ['E']=6, ['Z']=7, ['Y']=8,
>>> +['k']=1,
>>> +  };
>>>
>>> This assumes more of C99 than we have previously required.  Are we sure that
>>> all compilers out there will support this syntax?
>> Designated Initializers were a GNU C C89 extension.
>> So I thought they were both elegant and not too new.
>> I've not got access to older machines to test unfortunately.
> 
> Since we've been requiring declaration-after-statement support
> for some time now, using a feature like the above should be safe.
> I think it is worthwhile, too.

I did a lot off googling last night to confirm
that designated initializers are very widely supported.
In fact we've been using them since coreutils 7.1 (0889381c)

Attached is an updated version with 2 new tests.

cheers,
Pádraig.
>From 75bb07bb620d37d26467ab86ffcf73d47479b358 Mon Sep 17 00:00:00 2001
From: Michael Speer 
Date: Mon, 27 Apr 2009 14:51:29 +0100
Subject: [PATCH] sort: new --human-numeric-sort option to sort KiB MB etc.

* NEWS: Document the new option
* doc/coreutils.texi (sort invocation): ditto
* src/sort.c (main): handle the new -human-numeric-sort option (-h).
(human_numcompare): A new function to compare SI and IEC suffixes
before falling back to the standard --numeric comparison.
(find_unit_order): A new helper function to find the order
of magnitude of a number string as determined by its suffix.
(check_mixed_SI_IEC): A new helper function to exit with error
if both SI and IEC suffixes are presented.
* tests/misc/sort: Add 8 tests to test the new functionality.
* THANKS: Update
---
 NEWS   |5 ++
 THANKS |1 +
 doc/coreutils.texi |   14 ++
 src/sort.c |  115 
 tests/misc/sort|   18 
 5 files changed, 145 insertions(+), 8 deletions(-)

diff --git a/NEWS b/NEWS
index 31f1b1a..f28097d 100644
--- a/NEWS
+++ b/NEWS
@@ -2,6 +2,11 @@ GNU coreutils NEWS-*- outline -*-
 
 * Noteworthy changes in release ?.? (-??-??) [?]
 
+** New features
+
+  sort accepts a new option, --human-numeric-sort (-h): sort numbers
+  while honoring human readable suffixes like KiB and MB etc.
+
 ** Bug fixes
 
   truncate -s failed to skip all whitespace in the option argument in
diff --git a/THANKS b/THANKS
index cf801c5..4392f04 100644
--- a/THANKS
+++ b/THANKS
@@ -396,6 +396,7 @@ Michael J. Croghan  mcrog...@usatoday.com
 Michael McFarland   sid...@yahoo.com
 Michael McLagan mmcla...@invlogic.com
 Michael Piefel  pie...@informatik.hu-berlin.de
+Michael Speer   knome...@gmail.com
 Michael Steffensmichael.steff...@s.netic.de
 Michael Stone   mst...@debian.org
 Michael Stutz   st...@dsl.org
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 1a3075f..ae5c577 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3785,6 +3785,20 @@ Use this option only if there is no alternative; it is much slower than
 @option{--numeric-sort} (@option{-n}) and it can lose information when
 converting to floating point.
 
+...@item -h
+...@itemx --human-numeric-sort
+...@itemx --sort=human-numeric
+...@opindex -h
+...@opindex --human-numeric-sort
+...@opindex --sort
+...@cindex human numeric sort
+...@vindex LC_NUMERIC
+Sort numerically, as per the @option{--numeric-sort} option,
+and in addition handle IEC or SI suffixes like MiB, MB etc.
+Note a mixture of these suffixes is not supported and will
+be flagged as an error. Also the numbers must be abbreviated unambiguously.
+I.E. 5000K and 6M will be sorted incorrectly for example.
+
 @item -i
 @itemx --ignore-nonprinting
 @opindex -i
diff --git a/src/sort.c b/src/sort.c
index 6dea2ff..32cd200 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -176,6 +176,8 @@ struct keyfield
   bool random;			/* Sort by random hash of key.  */
   bool general_numeric;		/* Flag for general, numeric comparison.
    Handle numbers in exponential notation. */
+  bool human_numeric;		/* Flag for sorting by human readable
+   units with either SI xor IEC prefixes. */
   bool month;			/* Flag for comparison by month name. */
   bool reverse;			/* Reverse the sense of comparison. */
   bool version;			/* sort by version number */
@@ -337,6 +339,9 @@ Ordering options:\n\
   -M, --month-sortcompare (unknown) < `JAN' < ... < `DEC'\n\
 "), stdout);
   fputs (_("\
+  -h, --human-numeric-sortcompare human readable numbers (e.g., 2K 1G)\n\
+"), stdout);
+  fputs (_("\
   -n, --numeric-sort  compare according to string numerical value\n\
   -R, --random-sort   sort 

Re: Human readable sort

[Jim Meyering]

Pádraig Brady wrote:
> Eric Blake wrote:
>> Pádraig Brady  draigBrady.com> writes:
...
>> +static int
>> +find_unit_order (const char *number)
>> +{
>> +  static const char orders [UCHAR_LIM] = {
>> +['K']=1, ['M']=2, ['G']=3, ['T']=4, ['P']=5, ['E']=6, ['Z']=7, ['Y']=8,
>> +['k']=1,
>> +  };
>>
>> This assumes more of C99 than we have previously required.  Are we sure that
>> all compilers out there will support this syntax?
>
> Designated Initializers were a GNU C C89 extension.
> So I thought they were both elegant and not too new.
> I've not got access to older machines to test unfortunately.

Since we've been requiring declaration-after-statement support
for some time now, using a feature like the above should be safe.
I think it is worthwhile, too.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

[Ondřej Vašík]

Hello,
as reported in https://bugzilla.redhat.com/show_bug.cgi?id=502026, in dd
is an unnecessary memory allocation for input block even if input block
buffer is not needed (skip and count set to 0). Attached patch should
prevent memory exhaustion error in that very special case. I guess
mentioning in NEWS is not required in that case...

Greetings,
 Ondřej Vašík

From 5c9811896936341f462f67fd192748cac2f49dbd Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Ond=C5=99ej=20Va=C5=A1=C3=ADk?= 
Date: Fri, 22 May 2009 09:47:34 +0200
Subject: [PATCH] dd: do not unnecesarilly allocate memory for input block size, when not needed

* src/dd.c: do not allocate memory when count=0 and skip=0
  (and input block buffer is not needed)
* tests/dd/no-allocate: new test to check this change
* tests/Makefile.am: run that test
---
 src/dd.c |4 
 tests/Makefile.am|1 +
 tests/dd/no-allocate |   34 ++
 3 files changed, 39 insertions(+), 0 deletions(-)
 create mode 100755 tests/dd/no-allocate

diff --git a/src/dd.c b/src/dd.c
index 3ba616b..be6d544 100644
--- a/src/dd.c
+++ b/src/dd.c
@@ -1553,6 +1553,10 @@ dd_copy (void)
   int exit_status = EXIT_SUCCESS;
   size_t n_bytes_read;
 
+  /* Do not unnecessarily allocate memory */
+  if (max_records == 0 && skip_records == 0)
+return exit_status;
+
   /* Leave at least one extra byte at the beginning and end of `ibuf'
  for conv=swab, but keep the buffer address even.  But some peculiar
  device drivers work only with word-aligned buffers, so leave an
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 5591331..fd2fc90 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -291,6 +291,7 @@ TESTS =		\
   cp/symlink-slash\
   cp/thru-dangling\
   dd/misc	\
+  dd/no-allocate\
   dd/not-rewound\
   dd/reblock	\
   dd/skip-seek	\
diff --git a/tests/dd/no-allocate b/tests/dd/no-allocate
new file mode 100755
index 000..19629f2
--- /dev/null
+++ b/tests/dd/no-allocate
@@ -0,0 +1,34 @@
+#!/bin/sh
+# make sure that dd doesn't allocate memory unnecessarily
+
+# Copyright (C) 2009 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+if test "$VERBOSE" = yes; then
+  set -x
+  dd --version
+fi
+
+. $srcdir/test-lib.sh
+
+fail=0
+
+#count and skip is zero, we don't need to allocate memory for input block
+(ulimit -v 1;dd if=/dev/zero of=x bs=10M seek=1 count=0) || fail=1
+
+#skip is not zero, we need to allocate input block size (and we should fail)
+(ulimit -v 1;dd if=/dev/zero of=x bs=10M seek=1 skip=1 count=0) && fail=1
+
+Exit $fail
-- 
1.5.6.1.156.ge903b



signature.asc
Description: Toto je digitálně	 podepsaná část	 zprávy
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils