I made some simple changes to the time.c file and the build went on, only to fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the build does not seem to have any problems on other platforms, so I don't know. Anyone has an idea on how to best approach this?
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same problem?
Various packages wrongly think that mach == apple. The fix is usually
very simple.
On Mon, Apr 26, 2021 at 12:40:25PM +0200, João Pedro Malhado wrote:
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
It does seem this is a documented issue:
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#Bad_File_Descriptor
What would be a reasonable approach here, change to use _POSIX_PATH_MAX?
João Pedro Malhado, le lun. 26 avril 2021 12:51:34 +0200, a ecrit:
It does seem this is a documented issue:
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
What would be a reasonable approach here, change to use _POSIX_PATH_MAX?
See what the page says:
Note: constants such as _POSIX_PATH_MAX are only the minimum required
value for a potential corresponding PATH_MAX macro. They are not a replacement for PATH_MAX, just the minimum value that one can assume.
What would be best suited completely depends on what the buf purpose is
at all, whether the size is actually known and just needs to be
computed, or else use dynamic allocation. I'm here basically just
rephrasing the page...
Hello everyone,
Replacing all PATH_MAX by _POSIX_PATH_MAX on all files concerned in the build rules does result in a successful build and a browser that loads pages from the
web.
If we can decide on what is a reasonable technical solution in this case, we would then have another ported package users can use ;)
another solution would be better, then we would be done with this package.
On Mon, Apr 26, 2021 at 01:36:54PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le lun. 26 avril 2021 12:51:34 +0200, a ecrit:
It does seem this is a documented issue:
https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
What would be a reasonable approach here, change to use _POSIX_PATH_MAX?
See what the page says:
Note: constants such as _POSIX_PATH_MAX are only the minimum required
value for a potential corresponding PATH_MAX macro. They are not a replacement for PATH_MAX, just the minimum value that one can assume.
What would be best suited completely depends on what the buf purpose is
at all, whether the size is actually known and just needs to be
computed, or else use dynamic allocation. I'm here basically just rephrasing the page...
Yes, I did notice that. And I understand that the way I posed the question did
not have a well defined answer without knowledge of the specific context.
My knowledge of C goes as far as trying to change the size of the string. If dynamic allocation would be a better solution, I would need help doing that: how
to declare the variable, how to allocate, what to allocated to, how to deallocate.
There are 5 relevant files where this PATH_MAX shows up. In all cases the string
corresponds to a file path and either the function filepath_sfind() or filepath_defsfind() is being called (gtk_fetch_filetype_init() is also called but does not seem to have PATH_MAX hard-coded).
The two filepath_* functions are defined in:
netsurf/utils/filepath.c https://sources.debian.org/src/netsurf/3.10-1/netsurf/utils/filepath.c
These functions are being called from:
netsurf/frontends/gtk/fetch.c https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/gtk/fetch.c
netsurf/frontends/gtk/gui.c https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/gtk/gui.c
netsurf/frontends/framebuffer/fetch.c https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/framebuffer/fetch.c
netsurf/frontends/framebuffer/font_freetype.c https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/framebuffer/font_freetype.c
What would be a good solution in this case?
How big/small is _POSIX_PATH_MAX, and what problems may that create (also for the linux build)?
Perhaps interestingly ATARI also seems to have problems with PATH_MAX, as per line 36 in netsurf/utils/filepath.c:
#include "utils/dirent.h" /** \todo why is this necessary for atari to get PATH_MAX and is there a better way */
Some sort of hack seems to have been found there. I don't know if it would apply
to the hurd, but it does not seem very elegant. The atari code path seems to have loads PATH_MAX
Regards,
João
<blockquote type="cite" id="qt" style=""><div>Hello everyone,<br></div><div><br></div><div>Replacing all PATH_MAX by _POSIX_PATH_MAX on all files concerned in the build<br></div><div>rules does result in a successful build and a browser that loadspages from the<br></div><div>web.<br></div><div><br></div><div>If we can decide on what is a reasonable technical solution in this case, we<br></div><div>would then have another ported package users can use ;)<br></div><div> <br></div><div>another
<div>> > It does seem this is a documented issue:<br></div><div>> > <br></div><div>> > <a href="https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL">https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL</a><br></div><div>> > <br></div><div>> > What would be a reasonable approach here, change to use _POSIX_PATH_MAX?<br></div><div>> <br></div><div>> See what the
> computed, or else use dynamic allocation. I'm here basically just<br></div><div>> rephrasing the page...<br></div><div><br></div><div>Yes, I did notice that. And I understand that the way I posed the question did<br></div><div>not have a welldefined answer without knowledge of the specific context.<br></div><div><br></div><div>My knowledge of C goes as far as trying to change the size of the string. If<br></div><div>dynamic allocation would be a better solution, I would need help doing that:
<div><br></div><div>These functions are being called from:<br></div><div><br></div><div>netsurf/frontends/gtk/fetch.c<br></div><div><a href="https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/gtk/fetch.c">https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/gtk/fetch.c</a><br></div><div><br></div><div>netsurf/frontends/gtk/gui.c<br></div><div><a href="https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/gtk/gui.c">https://sources.debian.org/src/netsurf/3.10-1/
the linux build)?<br></div><div><br></div><div>Perhaps interestingly ATARI also seems to have problems with PATH_MAX, as per<br></div><div>line 36 in netsurf/utils/filepath.c:<br></div><div><br></div><div>#include "utils/dirent.h" /** \todo why isthis necessary for atari to get<br></div><div>PATH_MAX and is there a better way */<br></div><div><br></div><div>Some sort of hack seems to have been found there. I don't know if it would apply<br></div><div>to the hurd, but it does not seem very elegant.
Unsubscribe me from the list
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same problem?
Various packages wrongly think that mach == apple. The fix is usually
very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the build does not seem to have any problems on other platforms, so I don't know. Anyone has an idea on how to best approach this?
Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same problem?
Various packages wrongly think that mach == apple. The fix is usually very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
Ensure you are including <limits.h> in the source file. That's usually
the place PATH_MAX is defined.
Please always read the porting guideline page, it discusses such things.
You can search for symbols on the Posix website at https://pubs.opengroup.org:
https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
GNU/Hurd. Please read the mentioned page.
On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same problem?
Various packages wrongly think that mach == apple. The fix is usually very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
Ensure you are including <limits.h> in the source file. That's usually
the place PATH_MAX is defined.
You can search for symbols on the Posix website at https://pubs.opengroup.org:
https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault <sthibault@debian.org> wrote:
Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same
problem?
Various packages wrongly think that mach == apple. The fix is usually very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
Ensure you are including <limits.h> in the source file. That's usually the place PATH_MAX is defined.
Please always read the porting guideline page, it discusses such things.
You can search for symbols on the Posix website at https://pubs.opengroup.org:
https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
GNU/Hurd. Please read the mentioned page.
Instead of asking the world to do something special, perhaps Hurd
should do what people expect?
Doing what the world expects is economical.
Jeffrey Walton, le lun. 26 avril 2021 15:08:28 -0400, a ecrit:
On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault <sthibault@debian.org> wrote:
Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same
problem?
Various packages wrongly think that mach == apple. The fix is usually
very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
Ensure you are including <limits.h> in the source file. That's usually the place PATH_MAX is defined.
Please always read the porting guideline page, it discusses such things.
You can search for symbols on the Posix website at https://pubs.opengroup.org:
https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
GNU/Hurd. Please read the mentioned page.
Instead of asking the world to do something special, perhaps Hurd
should do what people expect?
People should *not* expect PATH_MAX to be defined.
Using PATH_MAX is most often a sign of laziness, that possibly entails
bugs or even security holes.
Doing what the world expects is economical.
Yes. And we should also burn all the petrol we have on earth since it's economical.
On Mon, Apr 26, 2021 at 3:12 PM Samuel Thibault <sthibault@debian.org> wrote:
Jeffrey Walton, le lun. 26 avril 2021 15:08:28 -0400, a ecrit:
On Mon, Apr 26, 2021 at 2:58 PM Samuel Thibault <sthibault@debian.org> wrote:
Jeffrey Walton, le lun. 26 avril 2021 14:48:32 -0400, a ecrit:
On Mon, Apr 26, 2021 at 6:57 AM João Pedro Malhado <phlogiston@sapo.pt> wrote:
On Thu, Apr 22, 2021 at 01:39:58PM +0200, Samuel Thibault wrote:
João Pedro Malhado, le jeu. 22 avril 2021 13:10:04 +0200, a ecrit:
src/time.c:25:10: fatal error: mach/clock.h: No such file or directory
https://buildd.debian.org/status/package.php?p=netsurf
Is this something easy to fix and patch?
Yes, see https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#mach_clock
would there be other packages in the repository affected by the same
problem?
Various packages wrongly think that mach == apple. The fix is usually
very simple.
Thank you Samuel for the useful pointers.
I made some simple changes to the time.c file and the build went on, only to
fail at some later stage. The error that I'm getting is:
frontends/gtk/fetch.c: In function 'nsgtk_get_resource_url': frontends/gtk/fetch.c:252:11: error: 'PATH_MAX' undeclared (first use in this
function)
252 | char buf[PATH_MAX];
Now, the only C I know is what I can guess from other programming languages I'm
familiar with, but this seems simple and not very hurd specific. However the
build does not seem to have any problems on other platforms, so I don't know.
Anyone has an idea on how to best approach this?
Ensure you are including <limits.h> in the source file. That's usually
the place PATH_MAX is defined.
Please always read the porting guideline page, it discusses such things.
You can search for symbols on the Posix website at https://pubs.opengroup.org:
https://www.google.com/search?q=PATH_MAX+site:pubs.opengroup.org
Yes, but PATH_MAX is not mandatory, and it is indeed not defined on
GNU/Hurd. Please read the mentioned page.
Instead of asking the world to do something special, perhaps Hurd
should do what people expect?
People should *not* expect PATH_MAX to be defined.
Using PATH_MAX is most often a sign of laziness, that possibly entails
bugs or even security holes.
Or expediency. Nearly all operating systems provide PATH_MAX.
Doing what the world expects is economical.
Yes. And we should also burn all the petrol we have on earth since it's economical.
https://www.google.com/search?q=logical+fallacy+faulty+analogy
It's not because something is economical that one should want to do it.
You don't even seem to realize that defining PATH_MAX *does* pose
problem, notably with the actual semantic of realpath(), due to the
semantic that posix attaches to it.
Samue
On Tue, 27 Apr 2021, 6:13 am Samuel Thibault, <sthibault@debian.org> wrote:
It's not because something is economical that one should want to do it.
You don't even seem to realize that defining PATH_MAX *does* pose
problem, notably with the actual semantic of realpath(), due to the
semantic that posix attaches to it.
Economical would be to avoid the rich bug farm that is arbitrary but unenforced limits. PATH_MAX is an open invitation for buffer overflows on any modern system.
"With a little help from my friends", I came up with a patch for the Netsurf build. The size of the filepaths are now allocated dynamically using asprintf()
type of functions and realpath().
...
I don't know if upstream would accept such a patch as they need to worry about
platforms like RISC OS and AmigaOS, and I don't know if this would work there.
It might be ok for Debian though. If there are no objections/corrections I could
try upstream first.
On Sat, May 29, 2021 at 2:33 PM João Pedro Malhado <phlogiston@sapo.pt> wrote:
The size of the filepaths are now allocated dynamically using asprintf() type of functions and realpath().
...
I don't know if upstream would accept such a patch as they need to worry about
platforms like RISC OS and AmigaOS, and I don't know if this would work there.
It might be ok for Debian though. If there are no objections/corrections I could
try upstream first.
You may be able to use Gnulib for the cross-platform support of
asprintf and realpath. Gnulib will handle the implementation details
for you. Gnulib also does a good job of listing problem platforms.
On Sat, 2021-05-29 at 19:16:57 +0100, João Pedro Malhado wrote:
--- netsurf-3.10.orig/libnsutils/src/time.c
+++ netsurf-3.10/libnsutils/src/time.c
@@ -16,11 +16,11 @@
#include <stdlib.h>
#include <unistd.h>
-#if (defined(_POSIX_TIMERS) && (_POSIX_TIMERS > 0) && (defined _POSIX_MONOTONIC_CLOCK)) || defined(__OpenBSD__)
+#if (defined(_POSIX_TIMERS) && (_POSIX_TIMERS > 0) && (defined _POSIX_MONOTONIC_CLOCK)) || defined(__OpenBSD__) || defined(__GNU__)
Does the Hurd not define _POSIX_TIMERS > 0 and _POSIX_MONOTONIC_CLOCK?
I don't know if upstream would accept such a patch as they need to worry about
platforms like RISC OS and AmigaOS, and I don't know if this would work there.
It might be ok for Debian though. If there are no objections/corrections I could
try upstream first.
--- netsurf-3.10.orig/libnsutils/src/time.c
+++ netsurf-3.10/libnsutils/src/time.c
@@ -16,11 +16,11 @@
#include <stdlib.h>
#include <unistd.h>
-#if (defined(_POSIX_TIMERS) && (_POSIX_TIMERS > 0) && (defined _POSIX_MONOTONIC_CLOCK)) || defined(__OpenBSD__)
+#if (defined(_POSIX_TIMERS) && (_POSIX_TIMERS > 0) && (defined _POSIX_MONOTONIC_CLOCK)) || defined(__OpenBSD__) || defined(__GNU__)
#include <time.h>
#elif defined(__riscos)
#include <oslib/os.h>
-#elif defined(__MACH__)
+#elif defined(__MACH__) && defined(__APPLE__)
#include <mach/mach.h>
#include <mach/clock.h>
#include <mach/mach_time.h>
--- netsurf-3.10.orig/netsurf/frontends/framebuffer/fetch.c
+++ netsurf-3.10/netsurf/frontends/framebuffer/fetch.c
@@ -48,13 +48,17 @@
*/
static nsurl *get_resource_url(const char *path)
{
- char buf[PATH_MAX];
+ char *buf=NULL;
nsurl *url = NULL;
if (strcmp(path, "favicon.ico") == 0)^
path = "favicon.png";
- netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), &url);
+ netsurf_path_to_nsurl(filepath_sfind(respaths, &buf, path), &url);
+
+ if (buf != NULL) {
+ free(buf);
+ }
return url;
}
--- netsurf-3.10.orig/netsurf/frontends/framebuffer/font_freetype.c
+++ netsurf-3.10/netsurf/frontends/framebuffer/font_freetype.c
@@ -120,15 +120,18 @@ fb_new_face(const char *option, const ch
fb_faceid_t *newf;
FT_Error error;
FT_Face aface;
- char buf[PATH_MAX];
+ char *buf=NULL;
newf = calloc(1, sizeof(fb_faceid_t));
if (option != NULL) {
newf->fontfile = strdup(option);
} else {
- filepath_sfind(respaths, buf, fontname);
+ filepath_sfind(respaths, &buf, fontname);
newf->fontfile = strdup(buf);
+ if (buf != NULL) {
+ free(buf);
+ }
}
error = FTC_Manager_LookupFace(ft_cmanager, (FTC_FaceID)newf, &aface);
--- netsurf-3.10.orig/netsurf/frontends/gtk/fetch.c
+++ netsurf-3.10/netsurf/frontends/gtk/fetch.c
@@ -249,14 +249,17 @@ const char *fetch_filetype(const char *u
static nsurl *nsgtk_get_resource_url(const char *path)
{
- char buf[PATH_MAX];
+ char *buf = NULL;
nsurl *url = NULL;
/* favicon.ico -> favicon.png */
if (strcmp(path, "favicon.ico") == 0) {
nsurl_create("resource:favicon.png", &url);
} else {
- netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), &url);
+ netsurf_path_to_nsurl(filepath_sfind(respaths, &buf, path), &url);
+ if (buf != NULL) {
+ free(buf);
+ }
}
return url;
--- netsurf-3.10.orig/netsurf/frontends/gtk/gui.c
+++ netsurf-3.10/netsurf/frontends/gtk/gui.c
@@ -335,8 +335,8 @@ static nserror nsgtk_add_named_icons_to_
*/
static nserror nsgtk_init(int argc, char** argv, char **respath)
{
- char buf[PATH_MAX];
- char *resource_filename;
+ char *buf = NULL;
+ char *resource_filename = NULL;
char *addr = NULL;
nsurl *url;
nserror res;
@@ -407,8 +407,12 @@ static nserror nsgtk_init(int argc, char
browser_set_dpi(gdk_screen_get_resolution(gdk_screen_get_default()));
NSLOG(netsurf, INFO, "Set CSS DPI to %d", browser_get_dpi());
- filepath_sfinddef(respath, buf, "mime.types", "/etc/");
+ filepath_sfinddef(respath, &buf, "mime.types", "/etc/");
gtk_fetch_filetype_init(buf);
+
+ if (buf != NULL) {
+ free(buf);
+ }
save_complete_init();
--- netsurf-3.10.orig/netsurf/frontends/monkey/fetch.c
+++ netsurf-3.10/netsurf/frontends/monkey/fetch.c
@@ -36,10 +36,13 @@ extern char **respaths;
static nsurl *gui_get_resource_url(const char *path)
{
- char buf[PATH_MAX];
+ char *buf=NULL;
nsurl *url = NULL;
- netsurf_path_to_nsurl(filepath_sfind(respaths, buf, path), &url);
+ netsurf_path_to_nsurl(filepath_sfind(respaths, &buf, path), &url);
+ if (buf != NULL) {
+ free(buf);
+ }
return url;
}
--- netsurf-3.10.orig/netsurf/frontends/monkey/main.c
+++ netsurf-3.10/netsurf/frontends/monkey/main.c
@@ -379,7 +379,7 @@ main(int argc, char **argv)
{
char *messages;
char *options;
- char buf[PATH_MAX];
+ char *buf=NULL;
nserror ret;
struct netsurf_table monkey_table = {
.misc = &monkey_misc_table,
@@ -441,8 +441,11 @@ main(int argc, char **argv)
die("NetSurf failed to initialise");
}
- filepath_sfinddef(respaths, buf, "mime.types", "/etc/");
+ filepath_sfinddef(respaths, &buf, "mime.types", "/etc/");
monkey_fetch_filetype_init(buf);
+ if (buf != NULL) {
+ free(buf);
+ }
urldb_load(nsoption_charp(url_file));
urldb_load_cookies(nsoption_charp(cookie_file));
--- netsurf-3.10.orig/netsurf/frontends/windows/fetch.c
+++ netsurf-3.10/netsurf/frontends/windows/fetch.c
@@ -76,10 +76,13 @@ static const char *fetch_filetype(const
*/
static nsurl *nsw32_get_resource_url(const char *path)
{
- char buf[PATH_MAX];
+ char *buf = NULL;
nsurl *url = NULL;
- netsurf_path_to_nsurl(filepath_sfind(G_resource_pathv, buf, path), &url);
+ netsurf_path_to_nsurl(filepath_sfind(G_resource_pathv, &buf, path), &url);
+ if (buf != NULL) {
+ free(buf);
+ }
return url;
}
--- netsurf-3.10.orig/netsurf/frontends/windows/main.c
+++ netsurf-3.10/netsurf/frontends/windows/main.c
@@ -191,7 +191,11 @@ static nserror set_defaults(struct nsopt
if (res_len > 0) {
nsoption_setnull_charp(ca_bundle, strdup(buf));
} else {
- ptr = filepath_sfind(G_resource_pathv, buf, "ca-bundle.crt");
+ if (buf != NULL) {
+ free(buf);
+ buf = NULL;
+ }
+ ptr = filepath_sfind(G_resource_pathv, &buf, "ca-bundle.crt");
if (ptr != NULL) {
nsoption_setnull_charp(ca_bundle, strdup(buf));
}
@@ -204,6 +208,7 @@ static nserror set_defaults(struct nsopt
* not available so use the obsolete method of user prodile
* with downloads suffixed
*/
+ buf = realloc(buf,buf_bytes_size);
buf[0] = '\0';
hres = SHGetFolderPath(NULL,
--- netsurf-3.10.orig/netsurf/utils/filepath.c
+++ netsurf-3.10/netsurf/utils/filepath.c
@@ -24,6 +24,11 @@
* straightforward.
*/
+/* This is needed by asprinf type of functions on GNU/Hurd*/
+#if defined(__GNU__)
+#define _GNU_SOURCE 1
+#endif
+
#include <sys/types.h>
#include <sys/stat.h>
#include <stdarg.h>
@@ -42,44 +47,43 @@
#define MAX_RESPATH 128
/* exported interface documented in filepath.h */
-char *filepath_vsfindfile(char *str, const char *format, va_list ap)
+char *filepath_vsfindfile(char **str, const char *format, va_list ap)
{
- char *realpathname;
char *pathname;
int len;
- pathname = malloc(PATH_MAX);
- if (pathname == NULL)
- return NULL; /* unable to allocate memory */
-
- len = vsnprintf(pathname, PATH_MAX, format, ap);
-
- if ((len < 0) || (len >= PATH_MAX)) {
- /* error or output exceeded PATH_MAX length so
- * operation is doomed to fail.
- */
- free(pathname);
+ if (str == NULL) {
return NULL;
+ }
+
+ len = vasprintf(&pathname, format, ap);
+
+ if (len < 0) {
+ return NULL; /* error in vasprintf */
}
- realpathname = realpath(pathname, str);
+ *str = realpath(pathname, NULL);
- free(pathname);
+ if (pathname != NULL) {
+ free(pathname);
+ }
- if (realpathname != NULL) {
+ if (*str != NULL) {
/* sucessfully expanded pathname */
- if (access(realpathname, R_OK) != 0) {
+ if (access(*str, R_OK) != 0) {
/* unable to read the file */
+ free(*str);
+ *str=NULL;
return NULL;
}
}
- return realpathname;
+ return *str;
}
/* exported interface documented in filepath.h */
-char *filepath_sfindfile(char *str, const char *format, ...)
+char *filepath_sfindfile(char **str, const char *format, ...)
{
va_list ap;
char *ret;
@@ -105,8 +109,9 @@ char *filepath_findfile(const char *form
return ret;
}
+
/* exported interface documented in filepath.h */
-char *filepath_sfind(char **respathv, char *filepath, const char *filename) +char *filepath_sfind(char **respathv, char **filepath, const char *filename)
{
int respathc = 0;
@@ -115,7 +120,7 @@ char *filepath_sfind(char **respathv, ch
while (respathv[respathc] != NULL) {
if (filepath_sfindfile(filepath, "%s/%s", respathv[respathc], filename) != NULL) {
- return filepath;
+ return *filepath;
}
respathc++;
@@ -128,33 +133,23 @@ char *filepath_sfind(char **respathv, ch
/* exported interface documented in filepath.h */
char *filepath_find(char **respathv, const char *filename)
{
- char *ret;
- char *filepath;
+ char *filepath = NULL;
if ((respathv == NULL) || (respathv[0] == NULL))
return NULL;
- filepath = malloc(PATH_MAX);
- if (filepath == NULL)
- return NULL;
-
- ret = filepath_sfind(respathv, filepath, filename);
-
- if (ret == NULL)
- free(filepath);
-
- return ret;
+ return filepath_sfind(respathv, &filepath, filename);
}
/* exported interface documented in filepath.h */
char *
filepath_sfinddef(char **respathv,
- char *filepath,
+ char **filepath,
const char *filename,
const char *def)
{
- char t[PATH_MAX];
+ char *t = NULL;
char *ret;
if ((respathv == NULL) || (respathv[0] == NULL) || (filepath == NULL)) @@ -164,17 +159,22 @@ filepath_sfinddef(char **respathv,
if ((ret == NULL) && (def != NULL)) {
/* search failed, return the path specified */
- ret = filepath;
+ ret = *filepath;
if (def[0] == '~') {
- snprintf(t, PATH_MAX, "%s/%s/%s", getenv("HOME"), def + 1, filename);
+ asprintf(&t, "%s/%s/%s", getenv("HOME"), def + 1, filename);
} else {
- snprintf(t, PATH_MAX, "%s/%s", def, filename);
+ asprintf(&t, "%s/%s", def, filename);
}
if (realpath(t, ret) == NULL) {
- strncpy(ret, t, PATH_MAX);
+ strncpy(ret, t, strlen(ret));
}
}
+
+ if (t != NULL) {
+ free(t);
+ }
+
return ret;
}
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 62:42:34 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,568 |