• Netsurf build failure: 'PATH_MAX' undeclared

    From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to All on Mon Apr 26 13:10:01 2021
    Apologies for the consecutive emails.

    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?
    I would need some guidance on implementing something more sophisticated as I fear I would make a mess.

    Regards,
    João

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to Samuel Thibault on Mon Apr 26 13:00:01 2021
    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?

    Regards,
    João

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Apr 26 13:40:02 2021
    João Pedro Malhado, le lun. 26 avril 2021 12:51:34 +0200, a ecrit:
    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?

    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...

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to Samuel Thibault on Mon Apr 26 18:50:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Mark Dymek@21:1/5 to All on Mon Apr 26 19:40:02 2021
    --d507e938b689439087ad7e09aab0ecee
    Content-Type: text/plain;charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    Unsubscribe me from the list

    On Mon, Apr 26, 2021, at 12:31 PM, João Pedro Malhado wrote:
    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


    --d507e938b689439087ad7e09aab0ecee
    Content-Type: text/html;charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Unsubscribe me from the list&nbsp;</div><div><br></div><div>On Mon, Apr 26, 2021, at 12:31 PM, João Pedro Malhado wrote:<br></
    <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 loads
    pages 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>&nbsp;<br></div><div>another
    solution would be better, then we would be done with this package.<br></div><div><br></div><div>On Mon, Apr 26, 2021 at 01:36:54PM +0200, Samuel Thibault wrote:<br></div><div>&gt; João Pedro Malhado, le lun. 26 avril 2021 12:51:34 +0200, a ecrit:<br></
    <div>&gt; &gt; It does seem this is a documented issue:<br></div><div>&gt; &gt;&nbsp;<br></div><div>&gt; &gt;&nbsp;<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>&gt; &gt;&nbsp;<br></div><div>&gt; &gt; What would be a reasonable approach here, change to use _POSIX_PATH_MAX?<br></div><div>&gt;&nbsp;<br></div><div>&gt; See what the
    page says:<br></div><div>&gt;&nbsp;<br></div><div>&gt; Note: constants such as _POSIX_PATH_MAX are only the minimum required<br></div><div>&gt; value for a potential corresponding PATH_MAX macro. They are not a<br></div><div>&gt; replacement for PATH_MAX,
    just the minimum value that one can assume.<br></div><div>&gt;&nbsp;<br></div><div>&gt; What would be best suited completely depends on what the buf purpose is<br></div><div>&gt; at all, whether the size is actually known and just needs to be<br></div><
    &gt; computed, or else use dynamic allocation. I'm here basically just<br></div><div>&gt; 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 well
    defined 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:
    how<br></div><div>to declare the variable, how to allocate, what to allocated to, how to deallocate.<br></div><div><br></div><div>There are 5 relevant files where this PATH_MAX shows up. In all cases the string<br></div><div>corresponds to a file path
    and either the function filepath_sfind() or<br></div><div>filepath_defsfind() is being called (gtk_fetch_filetype_init() is also called<br></div><div>but does not seem to have PATH_MAX hard-coded).<br></div><div><br></div><div>The two filepath_*
    functions are defined in:<br></div><div><br></div><div>netsurf/utils/filepath.c<br></div><div><a href="https://sources.debian.org/src/netsurf/3.10-1/netsurf/utils/filepath.c">https://sources.debian.org/src/netsurf/3.10-1/netsurf/utils/filepath.c</a><br></
    <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/
    netsurf/frontends/gtk/gui.c</a><br></div><div><br></div><div>netsurf/frontends/framebuffer/fetch.c<br></div><div><a href="https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/framebuffer/fetch.c">https://sources.debian.org/src/netsurf/3.10-1/
    netsurf/frontends/framebuffer/fetch.c</a><br></div><div><br></div><div>netsurf/frontends/framebuffer/font_freetype.c<br></div><div><a href="https://sources.debian.org/src/netsurf/3.10-1/netsurf/frontends/framebuffer/font_freetype.c">https://sources.
    debian.org/src/netsurf/3.10-1/netsurf/frontends/framebuffer/font_freetype.c</a><br></div><div><br></div><div>What would be a good solution in this case?<br></div><div>How big/small is _POSIX_PATH_MAX, and what problems may that create (also for<br></div><
    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 is
    this 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.
    The atari code path seems to<br></div><div>have loads PATH_MAX<br></div><div><br></div><div>Regards,<br></div><div>João<br></div><div><br></div><div><br></div></blockquote></body></html>
    --d507e938b689439087ad7e09aab0ecee--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Povl Ole Haarlev Olsen@21:1/5 to Mark Dymek on Mon Apr 26 20:20:01 2021
    On Mon, 26 Apr 2021, Mark Dymek wrote:
    Unsubscribe me from the list

    You need to send an email to:

    mailto:debian-hurd-request@lists.debian.org?subject=unsubscribe

    --
    Povl Ole

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to phlogiston@sapo.pt on Mon Apr 26 20:50:01 2021
    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

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to sthibault@debian.org on Mon Apr 26 21:10:01 2021
    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. Instead of wasting
    hundreds of developers' time (say 1000 developers, 15 minutes each),
    Hurd can fix it in once (15 minutes). 15 minutes (Hurd) is much more
    cost effective than asking each developer to figure out what Hurd is
    doing special (15000 minutes, 250 man hours).

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Apr 26 21:00:01 2021
    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.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Apr 26 21:20:01 2021
    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.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to sthibault@debian.org on Mon Apr 26 21:30:01 2021
    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

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Mon Apr 26 22:20:01 2021
    Jeffrey Walton, le lun. 26 avril 2021 15:25:23 -0400, a ecrit:
    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.

    Yes, 'Nearly'. Also nearly all operating systems are monolithical. And
    nearly all operating systems are Windows.

    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

    Also, lack of being able to extrapolate what the other wants to say.

    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.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William ML Leslie@21:1/5 to sthibault@debian.org on Tue Apr 27 10:40:02 2021
    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.



    Samue


    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.



    <div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Apr 2021, 6:13 am Samuel Thibault, &lt;<a href="mailto:sthibault@debian.org">sthibault@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="
    margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It&#39;s not because something is economical that one should want to do it.<br>

    You don&#39;t even seem to realize that defining PATH_MAX *does* pose<br> problem, notably with the actual semantic of realpath(), due to the<br> semantic that posix attaches to it.<br>
    <br><br><br>
    Samue<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="
    auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey Walton@21:1/5 to william.leslie.ttg@gmail.com on Tue Apr 27 10:50:02 2021
    On Tue, Apr 27, 2021 at 4:35 AM William ML Leslie <william.leslie.ttg@gmail.com> wrote:

    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.

    It is what it is. Folks are going to use PATH_MAX.

    You can thank Drepper and the Glibc folks for many of the buffer
    overflow problems in GNU software.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Marcin Laszewski@21:1/5 to All on Wed Apr 28 10:40:02 2021
    https://eklitzke.org/path-max-is-tricky

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to All on Sat May 29 20:40:02 2021
    Hello everyone,

    "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().

    Note that if on the gtk version you try to open a local file via the widget, the
    directory contents are not listed. This is not a problem of this patch as a crude change of MAX_PATH to _POSIX_MAX_PATH in the original source shows the same
    problem.

    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.

    Regards,
    João

    --- 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>
    @@ -41,7 +41,7 @@ nsuerror nsu_getmonotonic_ms(uint64_t *c
    uint64_t current;
    static uint64_t prev = 0; /* previous time so we never go backwards */

    -#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__) || define
  • From Jeffrey Walton@21:1/5 to phlogiston@sapo.pt on Sat May 29 21:40:01 2021
    On Sat, May 29, 2021 at 2:33 PM João Pedro Malhado <phlogiston@sapo.pt> wrote:

    "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.

    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.

    Also see https://www.gnu.org/software/gnulib/manual/html_node/asprintf.html
    and https://www.gnu.org/software/gnulib/manual/html_node/realpath.html.

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to Jeffrey Walton on Fri Jun 4 23:30:02 2021
    Hello Jeff,

    (Writing this from the hurd-console. Does utf-8 work? ã õ á à ê)

    On Sat, May 29, 2021 at 03:31:52PM -0400, Jeffrey Walton wrote:
    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.

    Thank you for the suggestion, I did not know about Gnulib. I think it might be a good idea in this case. I'll suggest it to upstream and see if they want to go that way.

    Regards,
    João

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Samuel Thibault@21:1/5 to All on Sun Jun 6 23:40:01 2021
    Guillem Jover, le dim. 06 juin 2021 23:21:52 +0200, a ecrit:
    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?

    _POSIX_TIMERS, no, because we don't have everything that posix requires,
    and some package builds would then break.

    Samuel

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillem Jover@21:1/5 to All on Sun Jun 6 23:30:02 2021
    Hi!

    On Sat, 2021-05-29 at 19:16:57 +0100, João Pedro Malhado wrote:
    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.

    In general, I'd recommend switching all code bases to use dynamic
    allocation for pathname handling.

    --- 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?

    #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;

    Always try to mimic the existing coding style. In this case spaces
    around ‘=’.

    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);
    +
    ^
    Watch for those trailing spaces.

    + if (buf != NULL) {
    + free(buf);
    + }

    There's no need to check for NULL before calling free().


    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;

    Spaces around ‘=’.


    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);
    + }

    No NULL check.

    }

    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);
    + }

    No NULL check.

    }

    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);
    + }

    No NULL check.


    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;

    Spaces around ‘=’.

    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);
    + }

    No NULL check.


    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;

    Spaces around ‘=’.

    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);
    + }

    No NULL check.


    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);
    + }

    No NULL check.


    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);

    No NULL check.

    + 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);

    This can leak on failure. You need a temporary variable to hold the
    return value and check whether it's not NULL, and then either free the
    other or assign the new value on top, and perhaps abort as needed or
    rollback or something.

    Missing space after ‘,’.

    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*/

    Typo “asprintf”, I guess you also need a “. ” before the comment end.

    +#if defined(__GNU__)
    +#define _GNU_SOURCE 1
    +#endif
    +

    Hmm, given that you are using asprintf family functions
    unconditionally, something like this will be needed for all
    architectures not just GNU/Hurd. This also seems like it should be
    defined in the build-system instead.

    #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;
    + }

    The coding style, seems to prefer omitting the curly brackets for
    single statements.

    +
    + len = vasprintf(&pathname, format, ap);
    +
    + if (len < 0) {
    + return NULL; /* error in vasprintf */
    }

    Excess curly brackets.


    - realpathname = realpath(pathname, str);
    + *str = realpath(pathname, NULL);

    I'd probably only assign into *str the final pathname, after the function
    has made sure everything is fine. And probably would also assign NULL at
    the beginning, so that on any error condition *str has a consistent
    state. To make this all more future-proof.


    - free(pathname);
    + if (pathname != NULL) {
    + free(pathname);
    + }

    No NULL check.


    - 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;

    This would not be needed here, neither the missing ones on the other
    early returns.

    return NULL;
    }
    }


    Here we'd also assign into *str. And I'd probably leave the existing realpathname handling as is.

    Actually, seeing now that str was only ever used to be filled with the
    contents of the result, and now we always allocate it anyway, I'd
    probably just get rid of the function argument completely.

    - 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, ...)

    I'm assuming this str argument can also go.

    {
    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)

    The same as with filepath here?

    {
    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)
    {

    And filepath here too.

    - char t[PATH_MAX];
    + char *t = NULL;

    While the spaces vs tabs handling in the upstream code does not seem consistent, I'd preserve the style on changed lines.

    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));
    }

    The strlen() here seems bogus, as it should depend on t not ret, but
    in any case the whole premise in this block now seems fishy.

    ret here should ideally be just NULL, otherwise we do not know if
    realpath() will have enough space for its copy. And then on failure
    we'd instead simply assign t to ret, as that's already been assigned
    with the correct allocated spaces.


    }
    +
    + if (t != NULL) {
    + free(t);
    + }
    +

    No NULL check. Although if we are going to return t, we should only
    free() it when realpath() has succeeded.

    return ret;
    }


    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?B?Sm/Do28=?= Pedro Malhado@21:1/5 to All on Sat Jun 26 13:40:02 2021
    Hello Guillem,

    Apologies for the late reply.
    Many thanks for the thorough comments on the patch. I have tried to address the issues that you pointed out in the attached new version of the patch.

    For those interested in tracking this issue, I had file a bug report upstream with the original patch: https://bugs.netsurf-browser.org/mantis/view.php?if=2824
    If there are no further comments, I will upload the new version of the patch to that bug report.

    Best regards,
    João

    -- 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>
    @@ -41,7 +41,7 @@ nsuerror nsu_getmonotonic_ms(uint64_t *c
    uint64_t current;
    static uint64_t prev = 0; /* previous time so we never go backwards */

    -#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__)
    struct timespec tp;

    clock_gettime(CLOCK_MONOTONIC, &tp);
    @@ -51,7 +51,7 @@ nsuerror nsu_getmonotonic_ms(uint64_t *c

    time = os_read_monotonic_time();
    current = time * 10;
    -#elif defined(__MACH__)
    +#elif defined(__MACH__) && defined(__APPLE__)
    clock_serv_t cclock;
    mach_timespec_t mts;

    --- netsurf-3.10.orig/netsurf/frontends/framebuffer/fetch.c
    +++ netsurf-3.10/netsurf/frontends/framebuffer/fetch.c
    @@ -48,13 +48,16 @@
    */
    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);
    + buf = filepath_find(respaths, path);
    + netsurf_path_to_nsurl(buf, &url);
    +
    + 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,16 @@ 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,