Hello,
Em terça-feira, 27 de agosto de 2019, às 19:06:21 -03, Paul Eggert
escreveu:
> Santiago Vila wrote:
> > In tests/colors there was a race condition which I tried to fix
> > by adding a "sleep 1", like this:
> >
> > mkfifo fifo
> > printf '%100s-a' > a
> > printf '%100s-b' > b
> > h
Hello,
Em quarta-feira, 3 de julho de 2019, às 08:19:55 -03, Normand escreveu:
> diffutils 3.7 make check failure ppc64le opensuse on colors test as
> reported in OBS tool (1)
>
>
> The extracted failure is a "Broken pipe"
I believe this is the same problem reported in bug 34519.
The Debian bu
Hello Paul,
Em domingo, 29 de agosto de 2021, às 04:22:27 -03, Paul Eggert escreveu:
> On 8/28/21 8:40 AM, Thiago Jung Bauermann via bug-diffutils via All
>
> diffutils discussion. wrote:
> > I believe this is the same problem reported in bug 34519.
> > The Debian build
Hello Everyone,
If the end of an inserted block matches the end of the block preceding the
insert, then the output between "diff" and "diff3" is not the same.
It looks like "diff" takes LCS from the end up, while "diff3" goes top down
which is more natural to the eye (see attached VS Code
Jim Meyering writes:
> This is to announce diffutils-3.9, a stable release.
Thank you!
> To summarize the 931 gnulib-related changes, run these commands
> from a git-cloned diffutils directory:
> git checkout v3.9
> git submodule summary v3.8
This results in empty output if the gnulib subm
Jim Meyering writes:
> Hi Simon,
> Thanks for reporting that. Good point, indeed.
> I've made that change to the tiny script I use to generate that part
> of the announcement.
>
> In case anyone else wants to use it (to be run after you've run "make
> release"), here it is:
Thank you -- any part
Hello list.
Since some time ago, building diff.exe with ASAN (on Windows-10),
causes it to trigger on illegal use of memcpy().
For example:
==3752==ERROR: AddressSanitizer: heap-use-after-free on address 0x121647e20772
at
pc 0x7ffc6e93727e bp 0x00d589efdba0 sp 0x00d589efd330
WRITE of size 17 at
Thanks for reporting that bug, which I recently introduced. I installed the
attached to fix it.
Applied it, ran the new version. Works fine (I think)
when compiling using 'clang-cl.exe',
But with MSVC's 'cl.exe', I often get:
diff.exe: memory exhausted
(on directory branches with approx. > 7
Hello Paul,
since the commit "diff: use openat, fstatat when recursive":
https://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=6bf2c33ea45c20061c13eeefebf2951eab79b61c
any '--recursive' option has stopped working on
Windows. AFAICS, since the 'openat()' seems unsupported
on Windows (acce
Bruno Haible wrote:
Gisle Vanem wrote:
since the commit "diff: use openat, fstatat when recursive":
https://git.savannah.gnu.org/cgit/diffutils.git/commit/?id=6bf2c33ea45c20061c13eeefebf2951eab79b61c
any '--recursive' option has stopped working on
Windows. AFAICS, since the 'openat()' see
Paul Eggert wrote:
in my test:
diff --recursive
does not work.
What are the failure symptoms?
Is this something you can debug? I don't use MS-Windows and won't be of much help on that platform. My guess would be in
the fdopendir area; perhaps that guess will help you debug.
Correct.
Paul Eggert wrote:
On 2023-08-01 02:59, Gisle Vanem via bug-diffutils via All diffutils
discussion. wrote:
What does this tell you guys about the 'diff --recursive'
behaviour on Windows?
Not being a MS-Windows person, it doesn't tell me much. You may have to delve further i
Paul Eggert wrote:
That's not enough information for me to offer clues. You don't say what the
failure symptoms are.
Perhaps you can use a debugger to see what system calls fail; that would be even more useful than the failure symptoms.
(Even better would be a proposed patch.)
I assume you
Bruno Haible wrote (at 25.07.2023 15:45):
The fix is to not define _FORTIFY_SOURCE on this platform. Done in
configure.ac.
I found another issue with gnu-diff from master;
if I do a (recursive) comparison of e.g.
f:\Cygwin64 -- the backed-up physical tree
and:
h:\Cygwin64 -- a mounted VDMK
Hi,
The `diff` command in `diffutils` can compare the difference between two
directories.
However, for large directories (the size for each file is small), when
traversal through them, `diff` command will eat up all the system memory. My
computer is 16GB RAM. And I believe this issue still e
Paul Eggert writes:
> On 2/3/25 12:15, Santiago Vila wrote:
>> So: Will diffutils really do the same at some point?
>
> I don't see why not. We didn't get around to it for 3.11, though.
Something like this perhaps?
/Simon
From 280f6a66819e6e2738498a6f37e09a50058cd9f0 Mon Sep 17 00:00:00 2001
Fr
Howdy,
This system is a Fedora 42 x86_64 version.
I have run diffutils-3.10/src/sdiff with NO problems. With
diffutils-3.11/src/sdiff I get the following:
/tools/diffutils/diffutils-3.11/src# ./sdiff -w 111 mkc mkconfig
realloc(): invalid next size
Aborted (core dumped) ./sdi
Howdy,
Just a brief note of appreciation.
Best regards,
George...
The commit 33ee12e5878c950dfd5ee230039abc514d936d03
build: use system help2man
surely was intended to have an effect only on the users
who build from git or who have made modifications after
unpacking the diffutils tarball.
But it also has an effect on OpenBSD users who take the diffut
Hi Paul,
The CI reports a compilation error of GNU diffutils, caused by the
most recent commit 45a4762bf3241e7fb6a2e01d382791ae44236841 .
Error seen on CentOS 7 (with gcc):
../../src/sdiff.c: In function 'edit':
../../src/sdiff.c:884:8: error: a label can only be part of a statement and a
decla
In the weekly CI, I see a test failure:
FAIL: test-nstrftime-2.sh
on NetBSD 10, Solaris 11.4, and Solaris 11 OmniOS,
that was a PASS last week.
Since nothing in this area has changed in Gnulib since last week,
I suspect that the cause is the diffutils commit
25919920377f08d6f09df804c7f8af11f5a
“make check” failure:
Testsuite summary for GNU diffutils 3.11
# TOTAL: 339
# PASS: 286
# SKIP: 41
# XFAIL: 0
# FAIL: 12
# XPASS: 0
# ERROR: 0
> Am 24.06.2025 um 12:42 schrieb Peter Dyballa :
>
> So some time before build_script() is called the wrong value is written into
> the component changed of both files' filevec or curr structs. Let's find out!
It presumingly happens in shift_boundaries().
--
Greetings
Pete
> Am 20.Mai.2025 um 19:17 schrieb Paul Eggert :
>
> Sure, attached is a gzip-compressed output of './configure; make check' on
> macOS 12.6 ARM.
On my recent Mac with Sonoma 14.7 testing diffutils 3.12 shows same results as
in the supplied reference. On the old PowerBook G4 the log files from
I tried to build diffutils 3.11 and 3.12 with GCC 14.2, both fail here:
/opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I/opt/local/include
-Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef
-Wno-unused-function -Wno-unused-parameter -Wno-float-conversion
-Wimpli
> Am 21.05.2025 um 13:35 schrieb Peter Dyballa :
>
> On my recent Mac with Sonoma 14.7 testing diffutils 3.12 shows same results
> as in the supplied reference. On the old PowerBook G4 the log files from
> tests show that the just built binaries do not work in many cases because of
> "program
> Am 16.06.2025 um 22:07 schrieb Paul Eggert :
>
> "git bisect" can help here.
I never learned to use this, so I'm still on the old way underway – and think
that this might make the difference:
diffutils-3.10/src/context.c:#include "c-ctype.h"
vs.
diffutils-3.12/src/context.
This morning I tested diffutils 3.10 on PPC Mac OS X 10.4.11, Tiger – with
pretty good results:
Testsuite summary for GNU diffutils 3.10
=
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> On 2025-06-12 03:29, Peter Dyballa wrote:
>> (gdb) p base
>> $2 = 0x0
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
Hello Paul!
The case becomes mysterious.
Here is
> Am 20.06.2025 um 08:16 schrieb Paul Eggert :
>
> On 2025-06-19 11:27, Peter Dyballa wrote:
>> I never learned to use this, so I'm still on the old way underway – and
>> think that this might make the difference:
>> diffutils-3.10/src/context.c:#include "c-ctype.h"
>> vs.
>> diffutils-3.12/src
In diff.c:882 we have in main():
exit_status = compare_files (&noparent, de_unknowns, argv[optind],
argv[optind + 1]);.
This function is defined in diff.c, starting at lines #1376 (comments) or #1387
(code). It has close to its end on line #1633/1634:
if (status == EXIT_SUCCE
Hello Paul!
The differences start earlier:
Breakpoint 1 at 0xf1ac: file diff.c, line 1633.
Breakpoint 2 at 0x8e10: file context.c, line 349.
Breakpoint 3 at 0x69f4: file analyze.c, line 624.
Breakpoint 4 at 0x6a04: file analyze.c, line 628.
Breakpoint 5 at
> Am 21.06.2025 um 00:05 schrieb Paul Eggert :
>
> On 2025-06-20 03:01, Peter Dyballa wrote:
>> To me "char const *const *" is not the same as "char const *" – could be for
>> PPC Mac OS X 10.4.11 too? I do not understand these code differences anyway.
>
> Correct. Read the types right to left
I have one more clue: on old Tiger the changed component of curr (or filevec)
holds TRUE instead of FALSE. Here are excepts from the debug sessions, side by
side:
Session on PPC Mac OS X 10.4.11, Tiger, Darwin 8.11.0
| Session on x86_64 macOS High Sierra, Version 10.13
> Am 24.06.2025 um 13:09 schrieb Peter Dyballa :
>
> It presumingly happens in shift_boundaries().
No, it does not happen there, because filevec|cmp|curr is not changed. The
function reads the component changed but does not write back. It just wastes
time? I cannot see that the function's res
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> On 2025-06-12 03:29, Peter Dyballa wrote:
>> (gdb) p base
>> $2 = 0x0
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
I think I found the actual cause: char const *con
When built with GCC 10, diff shows the same behaviour as when compiled with GCC
4.2. Compilation with GCC 14 fails here:
/opt/local/bin/gcc-mp-14 -std=gnu23 -I. -I/opt/local/include
-Wno-cast-qual -Wno-conversion -Wno-float-equal -Wno-sign-compare -Wno-undef
-Wno-unused-function -W
> Am 13.06.2025 um 19:14 schrieb Paul Eggert :
>
> On 2025-06-13 01:03, Peter Dyballa wrote:
>> Another question seems to be, why is the null pointer used when calling
>> fwrite()? A check should avoid this, rather early, and report or set some
>> failure status…
>
> No, that would be a bad w
> Am 16.06.2025 um 22:07 schrieb Paul Eggert :
>
> How about diffutils 3.11 (the previous diffutils)?
I think it already had the same problem. That's why I deleted diffutils for
some time. Could be the problem started with 3.10…
Anyway, I can go backwards version by version until I'll find th
A small remark: 'diff A B' works OK, but 'diff -u A B' does not. Adding --color
does not change anything.
"diff -ud A B" brings only *one* 'program error' plus a "+Abort" message (Exit
134):
tiger pete 225 /\
/opt/local/var/macports/build/_Users_btest_ports_sysutils_diffutils/diffutil
Diffutils 3.11 fail exactly as 3.12 do.
Diffutils 3.10 did not compile here since May 2023, see for example:
https://trac.macports.org/ticket/67488, https://trac.macports.org/ticket/67248,
https://trac.macports.org/ticket/68964.
They were never installed here (from time to time I am recording wh
I mentioned earlier:
> Am 20.06.2025 um 12:01 schrieb Peter Dyballa :
>
> In diff.c:882 we have in main():
>
> exit_status = compare_files (&noparent, de_unknowns, argv[optind],
> argv[optind + 1]);.
>
> This function is defined in diff.c, starting at lines #1376 (comments) or
> #1387 (code).
> Am 20.06.2025 um 12:01 schrieb Peter Dyballa :
>
> Comparing the function definition in both versions 3.12 and 3.10 I see that
> time is handled differently – cause found? In the end both functions simply
> have:
>
> set_color_context (RESET_CONTEXT);
> putc ('\n', outfile);
>
> The ne
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> On 2025-06-12 03:29, Peter Dyballa wrote:
>> (gdb) p base
>> $2 = 0x0
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
I am seeing something strange on my old PPC Tiger Mac:
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> On 2025-06-12 03:29, Peter Dyballa wrote:
>> (gdb) p base
>> $2 = 0x0
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
I think I am close to the cause (two sessions):
Bre
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
First unsatisfactory first answer is: because of this call and the code used in
the functions called:
context.c 379
> Am 13.06.2025 um 22:04 schrieb Paul Eggert :
>
> You can lessen the jumping by building with 'gcc -O0' instead of the usual
> -O2.
I built with "-O0 -ggdb". Many functions are outside of diff.c, in context.c or
util.c, some are GNU lib functions…
--
Greetings
Pete
"Evolution"
> Am 19.Mai.2025 um 20:16 schrieb Paul Eggert :
>
> There are lots of failures there, but unfortunately I don't have access to
> that old platform so you'll need to do some more digging to isolate the cause.
>
> Let's look at the first failure.
>
> echo a > a
> echo b > b
> diff a b
>
> This
Without coreutils 9.5 installed I encounter this:
tiger pete 238 /\ find .../diffutils -type f -name init.sh -ls
120650338 48 -rw-r--r--1 macports admin 24574 4 Apr 23:21:
.../diffutils-3.12/gnulib-tests/init.sh
120651731 48 -rw-r--r--1 macports admin
> Am 20.Mai.2025 um 18:53 schrieb Paul Eggert :
>
> Feel free to look into it further, but from a diffutils point of view I'm not
> sure it's worth the trouble for such an old platform.
OK! Tomorrow I'll try to test without coreutils the diffutils variations built
with either GCC 4.2 (meaning
Performing a 'make check V=1' reveals that coreutils 9.5 are defective:
126 + mv k out
127 mv: cannot stat 'out/k': Not a directory
Excerpt from gigantic tests/basic.log. (cp in coreutils 9.5 is also not working
properly.)
--
Greetings
Pete
It isn't pollution that's harming the envi
> Am 20.Mai.2025 um 18:25 schrieb Paul Eggert :
>
> If I understand you correctly, you're saying that although the original bug
> report shows the above test failing when you run 'make check', you cannot
> reproduce the problem when you run the same test under GDB.
Correct. My assumption is t
> Am 13.06.2025 um 00:14 schrieb Paul Eggert :
>
> On 2025-06-12 03:29, Peter Dyballa wrote:
>> (gdb) p base
>> $2 = 0x0
>
> That's obviously wrong; 'base' should not be a null pointer. Can you track
> down why it is a null pointer?
Yes. I thought so already, therefore I let its value print a
> Am 19.05.2025 um 20:16 schrieb Paul Eggert :
>
> There are lots of failures there, but unfortunately I don't have access to
> that old platform so you'll need to do some more digging to isolate the cause.
I think I tracked down the cause for diff to fail on Tiger, with .gdbinit
containing
I seem that "diff --ignore-space-change file1 file2"
ignores space-changes *inside* a C-string.
Like with file-1.c:
char strFl[7] = " ";
char strTt[5] = " ";
char strGs[5] = " ";
and file-2.c:
char strFl[7] = " ";
char strTt[5] = " ";
char strGs[5] = " ";
"diff.exe -u3 -b file-1.
Hi,
There was a change today in gnulib, that requires a small change in
packages that use gnulib-tool --with-tests with --makefile-name.
GNU diffutils is one such package.
Currently, './bootstrap' fails like this:
...
autoreconf: running: automake --add-missing --copy --force-missing
gnulib-tests
Paul Eggert wrote on 2025-09-05:
> I also installed the attached patch, to work around more the places
> where Gnulib drags in some multithreading and/or locale code that GNU
> diff (which is single-threaded and not that picky about locales) doesn't
> need. Not sure if these suggest any Gnulib c
This was in April 2025:
> In the weekly CI, I see a test failure:
> FAIL: test-nstrftime-2.sh
> on NetBSD 10, Solaris 11.4, and Solaris 11 OmniOS,
> that was a PASS last week.
>
> Since nothing in this area has changed in Gnulib since last week,
> I suspect that the cause is the diffutils commit
Hi,
The CI reports build failures on macOS and Cygwin, regressions from
last week.
1) New build failure on macOS 13, 14:
gcc -g -O2 -L/Users/runner/lib -L/usr/local/opt/gettext/lib -o diff
analyze.o context.o diff.o dir.o ed.o ifdef.o io.o normal.o side.o system.o
util.o libver.a ../lib/lib
Paul Eggert wrote:
> > I'm not even sure what you
> > mean by "Do not worry about multibyte C locales."
>
> I meant to not worry about platforms where the "C" (not "C.utf8") locale
> is multibyte. I don't know of how diffutils would misbehave in such
> locales (other than not be strictly POSIX-c
60 matches
Mail list logo
