split.c - size_t overflow
Line 153 - 157 ... 153:size_t outbase_length = strlen (outbase); 154:size_t outfile_length = outbase_length + suffix_length; 155:if (outfile_length + 1 outbase_length) 156:xalloc_die (); 157:outfile = xmalloc (outfile_length + 1); ... If suffix_length SIZE_MAX the check on line 155 is bypassed. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: split.c - size_t overflow
Chris Penev wrote: Line 153 - 157 ... 153:size_t outbase_length = strlen (outbase); 154:size_t outfile_length = outbase_length + suffix_length; 155:if (outfile_length + 1 outbase_length) 156:xalloc_die (); 157:outfile = xmalloc (outfile_length + 1); ... If suffix_length SIZE_MAX the check on line 155 is bypassed. Thanks for the analysis and the report. That is true. However, the code that sets suffix_length ensures that it is no larger than SIZE_MAX / sizeof (size_t), so there's no problem. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in ls?
On Sun, 8 Mar 2009, Major Péter wrote: I would like to list some folders with they block-sizes, but only specific folders am I interested. So I would like to use find to list the correct folders for me: ls `find . -type d -user foo -name *` this is not working because ls can't find folders with spaces in there name, find uses an implicit -print argument, but in this case please look at find's -print0 option. This version of the above command should work: $ find . -type d -user foo -print0 | xargs -0 ls (-name * is redundant, as everything matches) I'm still not sure what you're referring to by folders with block-sizes? Would the du command be helpful here? Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Did I found a bug in ls?
On Sun, Mar 8, 2009 at 3:15 PM, Major Péter majorpe...@sch.bme.hu wrote: Hi! I would like to list some folders with they block-sizes, but only specific folders am I interested. So I would like to use find to list the correct folders for me: ls `find . -type d -user foo -name *` -name * is redundant I think. this is not working because ls can't find folders with spaces in there name, so I am using a pipe and sed, to make it comfortable: This is a very dangerous way to try to solve this problem. See the findutils Texinfo manual, in particular the section Safe File Name Handling. ls `find . -user major -type d -name * | sed 's,\ ,\\\ ,g'` If I'm using echo instead ls, the output is: ./foo\ bar So I tried to use: ls ./foo\ bar And it worked! The easiest way to check this is using this command in a folder where are folders with spaces in they names: ls `ls -a | sed 's,\ ,\\\ ,g'` Is there may an other way to find out the folders block-size belonging to a specific user? Do you mean the total size in blocks of the contents of each directory owned by a user?Or the size in blocks occupied by each directory (i.e. list of files) itself?I'm not sure I clearly understand what you wanted to do, so it is hard for me to be sure this is the correct answer, but this is a reasonable guess I think: $ find glpk -depth -type d -user youngman -print0 | du -s --files0-from=- 1936glpk/glpk-4.8/doc 12 glpk/glpk-4.8/examples/.deps 1756glpk/glpk-4.8/examples 356 glpk/glpk-4.8/include 176 glpk/glpk-4.8/src/.deps 3528glpk/glpk-4.8/src 8 glpk/glpk-4.8/sysdep/gnu 12 glpk/glpk-4.8/sysdep/w32 24 glpk/glpk-4.8/sysdep 7880glpk/glpk-4.8 960 glpk/tarfile 8844glpk Thanks for your help. Regards, Peter Major ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] build: allow ./bootstrap --srcdir=... to work with a git submodule
Jim Meyering wrote: When using git-bisect to see exactly when pr -oN broke, I was dismayed to see that I couldn't easily build some older versions from git due to their dependency on older versions of gnulib. Of course, this isn't at all surprising, once you think about it, and I've been remiss for not doing this sooner... So I'm about to make gnulib a git submodule of coreutils. However, first, there's a small portability problem in the bootstrap script that makes --scrdir=... fail to run module init with versions of git newer than the one mentioned in the log below. I confess I haven't tried this with an older version of git (I don't even have an old enough version installed), so if someone can confirm bootstrap --srcdir=... succeeds and a subsequent git submodule status prints something, I'd appreciate it. Works fine here... $ git --version git version 1.5.3.6 $ ./bootstrap --gnulib-srcdir=/home/padraig/git/gnulib $ git submodule status 8a4dc70a0d4efd5f53abb1f7a1c24fe67915f96b gnulib (v0.0-1958-g8a4dc70) cheers, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
