GNU bug report logs - #75938
31.0.50; Temporary file-names overflowing MAX_PATH characters

Previous Next

Full log

Message #23 received at 75938 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: arthur.miller <at> live.com, 75938 <at> debbugs.gnu.org
Subject: Re: bug#75938: 31.0.50; Temporary file-names overflowing MAX_PATH
 characters
Date: Fri, 31 Jan 2025 09:35:22 +0200

> Date: Thu, 30 Jan 2025 20:14:56 -0800
> Cc: "75938 <at> debbugs.gnu.org" <75938 <at> debbugs.gnu.org>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> On 1/30/25 18:01, arthur miller wrote:
> > (make-temp-name (* 1024 1024 1024) ?a) <- asks for 1 gig of chars
> > 
> > After trying to execute that, I get message that Emacs has recovered
> > from the C stack overflow.
> 
> I assume you mean:
> 
>    (make-temp-name (make-string (* 1024 1024 1024) ?a))
> 
> and I don't observe the problem on bleeding-edge Emacs (commit 
> a5965217fc1d7b56df60f8e798edd48ae52c8624) when built on Fedora 41 
> x86-64. There is no C stack overflow, and make-temp-name signals 
> (file-error "Creating file name with prefix" "File name too long" 
> "aaa...") as expected.
> 
> If you're getting a C stack overflow on bleeding-edge Emacs, it might be 
> helpful to see exactly why. This would likely require running Emacs 
> under a debugger.

There are a few calls to literally 'alloca' in expand-file-name, at
least one of them specific to WINDOWSNT.  make-temp-name call
expand-file name inside make-temp-file-internal, so maybe this is the
reason?

Why don't all calls to 'alloca' in expand-file-name call SAFE_ALLOCA
instead?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.