XPost: linux.debian.ports.hurd

X-Debbugs-Cc: debian-hurd@lists.debian.org

Dear Maintainer,

Would you consider the attached patch aiming to address the long standing FTBS on the Hurd, and allow Hurd users to explore gopher space?

Best regards,
João

diff -ruNd gopher-3.0.17.4.orig/gopher/download.c gopher-3.0.17.4/gopher/download.c
--- gopher-3.0.17.4.orig/gopher/download.c 2025-04-10 19:08:57.757636876 +0200
+++ gopher-3.0.17.4/gopher/download.c 2025-04-10 19:08:21.505457111 +0200
@@ -256,10 +256,10 @@
}

#ifdef HAVE_GETCWD
- getcwd(curcwd, MAXPATHLEN);
+ curcwd = getcwd(NULL, 0);
#else
#ifdef HAVE_GET_CURRENT_DIR_NAME
- curcwd = get_current_dir_name();
+ curcwd = get_current_dir_name();
#else
getwd(curcwd);
#endif
@@ -402,7 +402,7 @@
GSsetPath(gs, names[choice]);

#ifdef HAVE_GETCWD
- getcwd(tmppath,MAXPATHLEN);
+ tmppath = getcwd(NULL, 0);
#else
#ifdef HAVE_GET_CURRENT_DIR_NAME
tmppath = get_current_dir_name();

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi João,

Thank you for sending this patch! I don't believe it's correct,
however.

On line 202, curcwd is malloced. Overwriting it prevents freeing it
later, so this creates a memory leak.

I suspect the later instance also has that issue.

How exactly is getcwd() defined and used on Hurd?

Thanks,

John

On Thu, Apr 10 2025, João Pedro Malhado wrote:

X-Debbugs-Cc: debian-hurd@lists.debian.org

Dear Maintainer,

Would you consider the attached patch aiming to address the long standing FTBS
on the Hurd, and allow Hurd users to explore gopher space?

Best regards,
João

[2. text/x-diff; gopher-3.0.17.4-hurd.patch]...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello John,

Thank you for having a look at the patch.
I apologise as the patch is indeed a bit rushed.

On Thu, Apr 10, 2025 at 10:15:02PM -0500, John Goerzen wrote:

Thank you for sending this patch! I don't believe it's correct,
however.

On line 202, curcwd is malloced. Overwriting it prevents freeing it
later, so this creates a memory leak.

I suspect the later instance also has that issue.

I see what you mean. Instead of allocating the memory on line 202, would it not be possible to dynamically allocate with getcwd(NULL, 0) when that function is available?
Is there any case that would not be covered by this?

How exactly is getcwd() defined and used on Hurd?

My understanding is that on Hurd getcwd() is just defined in glibc. Looking at the comment in https://sources.debian.org/src/glibc/2.41-7/io/getcwd.c/?hl=39#L25

Many thanks,
João

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 16 2025, João Pedro Malhado wrote:

Hello John,

Thank you for having a look at the patch.
I apologise as the patch is indeed a bit rushed.

On Thu, Apr 10, 2025 at 10:15:02PM -0500, John Goerzen wrote:

Thank you for sending this patch! I don't believe it's correct,
however.

On line 202, curcwd is malloced. Overwriting it prevents freeing it
later, so this creates a memory leak.

I suspect the later instance also has that issue.

I see what you mean. Instead of allocating the memory on line 202, would it not
be possible to dynamically allocate with getcwd(NULL, 0) when that function is
available?
Is there any case that would not be covered by this?

I think that would work fine on Linux and Hurd. That behavior, however,
isn't POSIX so wouldn't be portable. Can you clarify what the problem
with getcwd() as written is on Hurd? From the description in glibc, it
sounds like the behavior is the same as on Linux.

- John

How exactly is getcwd() defined and used on Hurd?

My understanding is that on Hurd getcwd() is just defined in glibc. Looking at
the comment in https://sources.debian.org/src/glibc/2.41-7/io/getcwd.c/?hl=39#L25

Many thanks,
João

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello John,

On Wed, Apr 16, 2025 at 07:32:22AM -0500, John Goerzen wrote:

I think that would work fine on Linux and Hurd. That behavior, however, isn't POSIX so wouldn't be portable. Can you clarify what the problem
with getcwd() as written is on Hurd? From the description in glibc, it sounds like the behavior is the same as on Linux.

The issue is that MAXPATHLEN is not defined on Hurd. For reference: https://darnassus.sceen.net/~hurd-web/faq/foo_max/

It is interesting that you mention POSIX compliance, as I have seen contradictory information about this. The above linked page states that getcwd(NULL, 0) is part of POSIX 2008.

Best regards,
João

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Apr 16 2025, João Pedro Malhado wrote:

Hello John,

On Wed, Apr 16, 2025 at 07:32:22AM -0500, John Goerzen wrote:

I think that would work fine on Linux and Hurd. That behavior, however,
isn't POSIX so wouldn't be portable. Can you clarify what the problem
with getcwd() as written is on Hurd? From the description in glibc, it
sounds like the behavior is the same as on Linux.

The issue is that MAXPATHLEN is not defined on Hurd. For reference: https://darnassus.sceen.net/~hurd-web/faq/foo_max/

It is interesting that you mention POSIX compliance, as I have seen contradictory information about this. The above linked page states that getcwd(NULL, 0) is part of POSIX 2008.

Hi,

Every reference I have seen says it's not part of POSIX. However, Linux
and the BSDs seem to support it, so might as well just assume it will
work. If you have a patch to just go that direction, I'll take it.

- John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello John,

On Sat, Apr 19, 2025 at 11:20:11PM -0500, John Goerzen wrote:

Every reference I have seen says it's not part of POSIX. However, Linux
and the BSDs seem to support it, so might as well just assume it will
work. If you have a patch to just go that direction, I'll take it.

Ok, I can send a patch. However I am puzzled by the current code and wanted to ask you.

Is there not a problem in the case
#if !defined(HAVE_GETCWD) && !defined(HAVE_GET_CURRENT_DIR_NAME)
where getwd(curcwd) would be used but curcwd has not been allocated?

And in the case
#if !defined(HAVE_GETCWD) && defined(HAVE_GET_CURRENT_DIR_NAME)
and get_current_dir_name() is used, but the free(curcwd) is not called
in line 347.
Is this not a memory leak?

Best regards,
João

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: linux.debian.ports.hurd

X-Debbugs-Cc: debian-hurd@lists.debian.org

Hello John,

On Sat, Apr 19, 2025 at 11:20:11PM -0500, John Goerzen wrote:

Every reference I have seen says it's not part of POSIX. However, Linux
and the BSDs seem to support it, so might as well just assume it will
work. If you have a patch to just go that direction, I'll take it.

Please see attached my second attempt at patching gopher.

Best regards,
João

diff -ruNd gopher-3.0.17.4/gopher/download.c gopher-3.0.17.4_mod/gopher/download.c
--- gopher-3.0.17.4/gopher/download.c 2025-04-24 16:28:29.100204200 +0200
+++ gopher-3.0.17.4_mod/gopher/download.c 2025-04-24 16:13:30.507748321 +0200
@@ -198,14 +198,6 @@
int start, end;
struct stat buf;

-#if defined(HAVE_GETCWD) && !defined(HAVE_GET_CURRENT_DIR_NAME)
- curcwd = (char *) malloc(MAXPATHLEN + 2);
- if (!curcwd) {
- CursesErrorMsg("Out of memory.");
- return;
- }
-#endif
-
switch (GSgetType(gs)) {
case A_DIRECTORY:
case A_CSO:
@@ -256,14 +248,20 @@
}

#ifdef HAVE_GETCWD
- getcwd(curcwd, MAXPATHLEN);
+ curcwd = getcwd(NULL, 0);
#else
#ifdef HAVE_GET_CURRENT_DIR_NAME
- curcwd = get_current_dir_name();
+ curcwd = get_current_dir_name();
#else
+ curcwd = (char *) malloc(MAXPATHLEN + 2);
+ if (!curcwd) {
+ CursesErrorMsg("Out of memory.");
+ return;
+ }
+
getwd(curcwd);
-#endif
-#endif /* HAVE_GET_CURRENT_DIR_NAME */
+#endif /* HAVE_GET_CUR