Subject: bug#75938: closed (Re: bug#75938: 31.0.50; Temporary file-names overflowing MAX_PATH characters)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 01 Feb 2025 12:22:01 +0000

Your bug report

#75938: 31.0.50; Temporary file-names overflowing MAX_PATH characters

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
75938: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75938
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#75938: 31.0.50; Temporary file-names overflowing MAX_PATH characters
From: Eli Zaretskii <[email-masked]>
To: arthur miller <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 01 Feb 2025 14:21:31 +0200
List-Id: <debbugs-submit.debbugs.gnu.org>

> From: arthur miller <[email-masked]>
> CC: "[email-masked]" <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Date: Sat, 1 Feb 2025 10:02:23 +0000
> 
> > > However, it eats up all the RAM, and stays busy for minutes without
> > > anything seemingly happen.
> >
> > GC, perhaps?  Or maybe the system working on the pagefile (e.g.,
> > extending it, because what was there was exhausted)?
> 
> It happends quite immidiately as Emacs starts to execute the make-string
> function.

What is "it" in this case?

> > As I said earlier, I'm not sure I understand why you think there's any
> > problem in this scenario.
> 
> I am not sure what you think that I think that is a problem :).

Then what are we still discussing here?

> I think the problem is that Emacs seems to ask for that much RAM/VM
> whatever.

Why?  As I explained, Emacs asks for more than is immediately needed,
to avoid the need to ask the OS for more if you then enlarge the
string by 1 byte.

> > OTOH, you seem to assume that creating a 1 GB string asks the system
> > for 1 GB of memory, but that is not so.  I think Emacs asks for more,
> > in particular because the string could grow, and because Emacs holds
> > strings in memory in a superset of UTF-8 representation, so each
> > character could use up to 5 bytes.
> 
> I am aware that it can be more than 1 gig. I said gigabyte of
> characters. In this case, utf8 internally, since I am askring for "a", I
> guess it is one gigabyte of RAM too, it should fit into one byte since
> according to utf8, but I don't know, perhaps Emacs does something
> different?

See above.

> There is probably more storage needed for bookkeeping of this
> data internally, and probably some intermediary buffers and so on when
> function is executing.

Yes.  And also for printing the result, since evaluating a function
shows the result in the echo-area or in *scratch*.

> Still even if it took 5 gigabyte for the string storage, does it not seem
> strange to eat up more than double, almost tripple that ram? Perhaps
> it's ok, I don't know; it is a question, just asking.

Feel free to step with a debugger through the code, but I personally
am not surprised at all.

> > AFAIU, that bug is now fixed on the master branch, right?
> 
> Yes, it seems so, so you can close the bug repport :). Thanks for fixing
> it so fast!

Closing.

Subject: 31.0.50; Temporary file-names overflowing MAX_PATH characters
From: arthur miller <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 30 Jan 2025 03:45:43 +0000
List-Id: <debbugs-submit.debbugs.gnu.org>

I am not sure if this is a bug or not; so do what you want with this.

It is fully possibly to create names that are not valid as file names,
via make-temp-name and make-temp-file, which are frontend for the
make-temp-file-internal function. For example:

(make-temp-name (make-string 1024 ?a))

will succeed without problems, but of course:

(make-temp-file (make-string 1024 ?a))

will fail, later on when it actually tries to create the file.

Attached is a suggested fix; the idea is to save the unnecessary trip to
the OS; it signals error if the total file name length is longer than
MAX_PATH.

I don't know if it is a feature to have temp-names longer than certain
length, if it is than OK; this is more of a question/suggestion than a
bug report.