Pádraig Brady wrote:
On 28/05/11 22:47, Jim Meyering wrote:
Jim Meyering wrote:
These (off_t) casts are anachronistic.
They were useful in pre-ANSI-C days, i.e., before prototypes.
There are two remaining off_t casts, and neither appears useful:
(one is even inconsistently formatted, with
Pádraig Brady wrote:
On 28/05/11 22:34, Jim Meyering wrote:
I built the latest gcc from git/svn (4.7.0 20110528)
and got a new -Wstrict-overflow warning:
ls.c: In function 'main':
ls.c:2291:9: error: assuming signed overflow does not occur when\
simplifying conditional to
FYI,
From 5c557690d8f10d1adc6d64478ab1ac0667282460 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 29 May 2011 14:29:13 +0200
Subject: [PATCH] maint: remove unnecessary gnulib .diff file
* gl/modules/getloadavg.diff: Remove file. It stopped being
useful back in
Hello,
I believe that cp uses wrong order of syscalls when applying target file
attributes; fchown(2) is called before fchmod(2).
As a result it looses access to target file and is unable to apply file mode
correctly; error message is as follows
cp: preserving permissions for `target': Not owner
bug-coreutils@gnu.orgAccording to valgrind, ls -l leaks memory. I have
included the coreutils version, uname -a information, Expected output
from valgrind (ls) and non-expected output (ls -l).
My first bug report ever, please tell me if something is wrong. I am using a
dell e4300 laptop,
On 05/28/11 06:10, Milan Novak wrote:
I believe that cp uses wrong order of syscalls when applying target file
attributes; fchown(2) is called before fchmod(2).
As a result it looses access to target file and is unable to apply file mode
correctly; error message is as follows
cp: preserving
On 05/29/11 12:27, Paul Eggert wrote:
# echo -n CHOWN /etc/privgrp
# setprivgrp -f /etc/privgroup
Whoops, obviously I misspelled one of those two file names.
I think the second one is right. But you should read the
manuals and check before trying it (I haven't used HP-UX
in years).
On 29/05/11 01:28, Ola Olsson wrote:
bug-coreutils@gnu.orgAccording to valgrind, ls -l leaks memory. I have
included the coreutils version, uname -a information, Expected output
from valgrind (ls) and non-expected output (ls -l).
ls does leak but inconsequentially.
Explicitly freeing the
