On 8/22/22 19:16, Bruno Haible wrote:
At this occasion: How about moving __path_search and direxists to a
different source file in glibc?
Thanks, good idea. I installed the attached into Gnulib and plan to
follow up on the glibc side.
From 044bf893acee0a55b22b4be0ede0e3ce010c480a Mon Sep 17
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 23 Aug 2022 16:49:36 +0200
>
> Eli Zaretskii asked:
> > > Yes. Running the "case 2" part 1000 times again, among the 2000 generated
> > > file names,
Eli Zaretskii asked:
> > Yes. Running the "case 2" part 1000 times again, among the 2000 generated
> > file names, there are no duplicates — neither on 32-bit mingw, nor on 64-bit
> > mingw.
>
> Was that with or without using clock_gettime? If it was with
> clock_gettime, what happens without it
> From: Bruno Haible
> Cc: Eli Zaretskii , bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 23 Aug 2022 02:13:02 +0200
>
> > If I understand things
> > correctly, these patches should fix the 0.1% failure rate you observed
> > on 64-bit mingw.
>
Paul Eggert wrote:
> These fixes should be merged into glibc upstream since they fix glibc
> bugs; I plan to follow up on that shortly.
At this occasion: How about moving __path_search and direxists to a
different source file in glibc? They are not called, nor do they call,
nor do they share
Paul Eggert wrote:
> Thanks for the detailed diagnosis, Bruno. To try to fix the problems I
> installed the attached patches into Gnulib.
These look all good. Here's again my evaluation of the three scenarios:
(Q1) What is the expected quality inside a single gen_tempname call?
It depends on
Thanks for the detailed diagnosis, Bruno. To try to fix the problems I
installed the attached patches into Gnulib. If I understand things
correctly, these patches should fix the 0.1% failure rate you observed
on 64-bit mingw. They also fix a minor security leak I discovered: in
rare cases,
Paul Eggert asked:
> > Could you investigate further why mingw 64-bit fails?
Some words on the "why". You seem to have expectations regarding the
distribution quality of the resulting file names, but these expectations
are not warranted.
Donald E. Knuth wrote in TAOCP vol 2 "Seminumerical
> From: Bruno Haible
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com
> Date: Sun, 21 Aug 2022 18:20:52 +0200
>
> I changed test-tempname.c to skip the case 1 and execute only case 2, and
> added printf statements per the attached tempname.c.diff. Then
Paul Eggert wrote:
> > Since this contradicts what you debugged on mingw, I ran the test 1
> > times on native Windows. Result:
> >- on 32-bit mingw, no failure.
> >- on 64-bit mingw, around 30 failures (or around 10 failures with Paul's
> > newest patch). That is, a probability
> Date: Wed, 17 Aug 2022 23:05:33 -0700
> Cc: br...@clisp.org, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> From: Paul Eggert
>
> On 8/17/22 04:08, Eli Zaretskii wrote:
> > Would it be possible to cherry-pick this to the emacs-28 branch, so
> > that Emacs
On 8/17/22 04:08, Eli Zaretskii wrote:
Would it be possible to cherry-pick this to the emacs-28 branch, so
that Emacs 28.2 would have this fixed?
I installed that.
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 22:06:13 +0200
>
> Eli Zaretskii wrote:
> > Emacs has a with-temp-file macro, which generates a temporary file
> > name, executes the body
> Date: Tue, 16 Aug 2022 12:11:24 -0700
> Cc: br...@clisp.org, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> From: Paul Eggert
>
> > Thanks, but why not use 'random' instead? Emacs does have it on all
> > platforms, including MS-Windows. AFAIU, it's
On 8/16/22 12:59, Bruno Haible wrote:
Since this contradicts what you debugged on mingw, I ran the test 1
times on native Windows. Result:
- on 32-bit mingw, no failure.
- on 64-bit mingw, around 30 failures (or around 10 failures with Paul's
newest patch). That is, a probability
Paul Eggert wrote:
> Emacs 'configure' deliberately suppresses MinGW's clock_gettime.
Ah, this explains why Eli saw the problem in Emacs in a deterministic
manner, whereas I see it only with 0.3% probability in my tests on 64-bit
mingw.
> I installed
> into Gnulib the attached patch, which I
Eli Zaretskii wrote:
> Emacs has a with-temp-file macro, which generates a temporary file
> name, executes the body of the macro with a variable bound to the file
> name, then deletes the file. Very handy for writing test suites.
Since, even with Paul's newest patch, gen_tempname on 64-bit mingw
Eli Zaretskii wrote:
> Looking at your test program, I see that you generate the seconds file
> name without deleting the first one. When a file by the first
> generated name already exists, gen_tempname will indeed generate a
> different name. But in the scenario I described, Emacs creates one
On 8/16/22 10:47, Eli Zaretskii wrote:
(Why are you talking about MS-DOS?)
I mistakenly thought it was an MS-DOS problem because tempname.c
ordinarily would use clock_gettime on MinGW. I didn't know Emacs
'configure' deliberately suppresses MinGW's clock_gettime.
Thanks, but why not use
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 19:29:33 +0200
>
> > The buffer which visited that file still exists, and still records the
> > name of the file, yes. And then, when the
> Date: Tue, 16 Aug 2022 10:30:54 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com, br...@clisp.org
> From: Paul Eggert
>
> On 8/16/22 10:04, Eli Zaretskii wrote:
> > That "finite number" of 62^6 sounds pretty close to infinity to me!
>
> It's only
> Date: Tue, 16 Aug 2022 10:25:57 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com
> From: Paul Eggert
>
> On 8/16/22 09:25, Eli Zaretskii wrote:
> > why does this work differently on
> > different platforms?
>
> Platforms that lack clock_gettime
> Cc: jporterb...@gmail.com, la...@gnus.org, bug-gnulib@gnu.org,
> 57...@debbugs.gnu.org, br...@clisp.org
> Date: Tue, 16 Aug 2022 20:04:49 +0300
> From: Eli Zaretskii
>
> Therefore, if there's no intention to fix this in Gnulib, I'm going to
> update the documentation of make-temp-file so that
On 8/16/22 10:04, Eli Zaretskii wrote:
That "finite number" of 62^6 sounds pretty close to infinity to me!
It's only 57 billion or so. That's not infinity, considering all the
Emacs sessions out there. If Emacs's success grows, almost surely
someone will run into this unlikely bug. Since we
Thanks for the explanations, Eli.
Eli Zaretskii wrote:
> > Maybe the problem is that the file gets deleted too early, when some parts
> > of Emacs still reference it?
>
> The buffer which visited that file still exists, and still records the
> name of the file, yes. And then, when the program
On 8/16/22 09:25, Eli Zaretskii wrote:
why does this work differently on
different platforms?
Platforms that lack clock_gettime and CLOCK_MONOTONIC fall back on a
deterministic algorithm. Presumably MS-DOS one of the few such
platforms, which is why the problem is observed only on MS-DOS.
> Date: Tue, 16 Aug 2022 09:54:25 -0700
> Cc: bug-gnulib@gnu.org, la...@gnus.org, 57...@debbugs.gnu.org,
> jporterb...@gmail.com, Bruno Haible
> From: Paul Eggert
>
> On 8/16/22 09:25, Eli Zaretskii wrote:
> > The programmer didn't
> > expect that because it is natural to expect each call to a
On 8/16/22 09:25, Eli Zaretskii wrote:
The programmer didn't
expect that because it is natural to expect each call to a function
that creates a temporary file to create a file under a new name, not
reuse the same name.
Regardless of whether the programmer expects a random name or a
> From: Bruno Haible
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org, la...@gnus.org,
> 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 16:40:16 +0200
>
> Eli Zaretskii wrote:
> > Looking at your test program, I see that you generate the seconds file
> > name without deleting
Eli Zaretskii wrote:
> Looking at your test program, I see that you generate the seconds file
> name without deleting the first one. When a file by the first
> generated name already exists, gen_tempname will indeed generate a
> different name. But in the scenario I described, Emacs creates one
> From: Bruno Haible
> Cc: la...@gnus.org, 57...@debbugs.gnu.org, jporterb...@gmail.com
> Date: Tue, 16 Aug 2022 15:35:17 +0200
>
> Eli Zaretskii wrote:
> > The problem is that callers of
> > make-temp-file reasonably expect it to return a new name every call.
> > And evidently, it does that on
Eli Zaretskii wrote:
> The problem is that callers of
> make-temp-file reasonably expect it to return a new name every call.
> And evidently, it does that on GNU/Linux (not sure how, given that the
> tempname.c code is supposed to be in glibc?). So if there's no
> intention to change gen_tempname
> Date: Mon, 15 Aug 2022 13:55:35 -0700
> Cc: la...@gnus.org, 57...@debbugs.gnu.org, Jim Porter
> , Gnulib bugs
> From: Paul Eggert
>
> On 8/15/22 11:58, Eli Zaretskii wrote:
>
> > Ah, okay. It's a (mis)feature of Gnulib's gen_tempname function
> > (which is the guts of make-temp-file) in
Paul Eggert wrote:
> I do see a comment saying that gen_tempname generates "hard-to-predict"
> names, which as you note is not correct on MS-DOS, nor even strictly
> speaking on all POSIX platforms. I installed the first attached patch
> into Gnulib to fix that comment.
Another comment fix is
On 8/15/22 11:58, Eli Zaretskii wrote:
Ah, okay. It's a (mis)feature of Gnulib's gen_tempname function
(which is the guts of make-temp-file) in its implementation for
MS-Windows (and maybe other platforms?): it always begins from the
same "random" characters in the file name, and only
35 matches
Mail list logo
