On 16/02/2020 20.55, Paul Eggert wrote:
> I installed the attached, which is a bit more conservative than your
> suggestion, as it doesn't assume that 'pause' exists or that it indeed
> sleeps forever (though I know of no counterexamples, there's little
> difficulty in relaxing those assumptions).
Paul Eggert wrote:
> if GCC generated warnings for that sort of thing, the warnings would be false
> alarms.
Yes, and this in turn means that the ability to produce useful warnings via
'restrict' is limited. In this example:
===
#incl
On 2/16/20 4:14 PM, Bruno Haible wrote:
I thought that passing pointers to different elements of the same array
would produce warnings. But I was mistaken: This code does NOT produce warnings.
Yes, and I don't see why such code has undefined behavior, as long as the
function doesn't actually a
Hi Clement,
> Currently, --disable-rpath will add directly $found_so to the compilation
> line. However, on AIX, this will result on the path being hardcoded in
> the built binaries.
> The only way to avoid hardcoded paths without using linker flags (like
> -Wl,-bnoipath) is to add -l$name.
Can y
Addendum:
> > >- 'restrict' should NOT be used for multiple output parameters of the
> > > same type, when only a single word is written through each parameter.
> > > Example: ssize_t copy_file_range (int ifd, off_t *ipos, int ofd,
> > > off_t *opos,
> > >
Hi Paul,
Thanks a lot for your comments.
> >- If all pointer parameters point to different types, excluding 'void *',
> > ISO C forbids aliasing anyway, therefore 'restrict' is redundant.
>
> The actual ISO C rule is a bit different, since it allows aliasing between
> 'char
> *', 'uns
> Ideally, valgrind would have a way to distinguish static memory allocations
> from leaks (where by "leak" I mean an allocation that would accumulate when
> the code is run repeatedly). How could such a distinction be implemented,
> without multiplying the time needed to run the test by a factor o
> > Perhaps lchmod.m4 and fchmodat.m4 should define a symbol
> > HAVE_LCHMOD_BUG_WITH_NON_SYMLINKS and the C code could refer to that.
> 2020-02-16 Bruno Haible
>
> lchmod: Make more future-proof.
> * m4/lchmod.m4 (gl_FUNC_LCHMOD): Define NEED_LCHMOD_NONSYMLINK_FIX.
> (gl_P
Paul Eggert wrote:
> it's merely choosing a point in a design space that involves simplicity,
> efficiency, correctness, testability, etc. and where there are several
> reasonable choices.
Right. In the case of fstrcmp, the bison tests use 'valgrind -q'. Akim could
use 'valgrind -q --leak-check=
On 2/16/20 12:44 PM, Jeffrey Walton wrote:
The coding standard is wrong in this area. The practice breaks testing.
Not really. It breaks some tests, which are arguably testing the wrong thing.
Any tests that check for whether all memory is freed just before exit, are
testing for a property th
On 2/9/20 7:02 PM, Bruno Haible wrote:
- If all pointer parameters point to different types, excluding 'void *',
ISO C forbids aliasing anyway, therefore 'restrict' is redundant.
The actual ISO C rule is a bit different, since it allows aliasing between 'char
*', 'unsigned char *', 's
Paul Eggert wrote:
> > 2) Also the discussion what is the "right" behaviour is specific to Linux.
> > The code in the '#else' case
> >
> >if (S_ISLNK (st.st_mode))
> > {
> >close (fd);
> >errno = EOPNOTSUPP;
> >return -1;
> > }
> >
> > will surely upset users
On 2/10/20 4:26 AM, Vladimir Panteleev wrote:
I'm not sure if isfinite is the best way to check for infinity, as far
as the tradeoff between portability and dependencies goes.
We can use the same test that dtotimespec uses, since we want to sleep forever
not only if the argument is infinity,
On Sun, Feb 16, 2020 at 7:53 AM Bruno Haible wrote:
>
> ...
> > I agree, I would like to be able to explicitly release the memory. But
> > I can't see any API to do that in fstrcmp.c. Is this one ok?
>
> The GNU Coding Standards [1] tell us to not worry about this situation.
> However,
> the al
Hi Paul,
> One other possible bug is that the mode could change temporarily and then
> spontaneously revert later, because the updated mode was cached but not
> committed to stable storage. Filesystem bugs can be nasty.
The S_ISLNK check that you put in bypasses this dark/fuzzy area in the kern
On 2020-02-08 I wrote:
> 1) Improve the cross-compilation guesses. The result of the
> "fchmodat+AT_SYMLINK_NOFOLLOW works on non-symlinks" test is:
> - yes on kFreeBSD/glibc, Hurd/glibc, FreeBSD 12, AIX 7.2, Solaris 11, Haiku,
> - no on Linux/glibc, Cygwin 2.9.
A similar improvement can be do
On 2/16/20 9:24 AM, Bruno Haible wrote:
In this case:
- On ext4, btrfs, jfs, xfs:
mode changed, but error "Operation not supported".
- On reiserfs:
mode changed, success.
Thanks for checking. I hope all this stuff is worked around by the latest patch.
One other possible bug is that t
I wrote:
> But what I observe is that the behaviour is the same on all major file
> systems on Linux.
>
> Tested on Linux 5.3.7 (fc31), with the trivial program below, on
> - ext4
> - btrfs
> - jfs
> - reiserfs
> - xfs
This are different when using the code which goes through the /proc
Hi Akim,
Sorry for the delay.
> > Do the threads still exist at the moment valgrind does its inventory of
> > left-
> > over memory?
>
> I don't know when it runs its stuff, but I expect, given where it stands,
> that it does it as the latest possible instant.
>
> > In particular:
> > - Did y
19 matches
Mail list logo
