Re: devel/ddd after libXt update

2020-01-17 Thread Marc Espie 
On Fri, Jan 17, 2020 at 09:50:26AM +0100, Matthieu Herrb wrote:
> This looks like the correct fix to me.
> I think only C++ cares about this kind of function signature changes.

Well, that's one instance where C++ is right to care !
Functions that don't return are pretty special.

(it's not even a gcc extension in modern C++, btw. In C++11 and upwards, it's
[[noreturn]])

or you would prefer to go back to pre-ANSI C ?...

Re: devel/ddd after libXt update

2020-01-17 Thread Matthieu Herrb 
On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote:
> (ddd is cruft, the latest release dates from 2009, so this isn't
> really important.)
> 
> After the libXt 1.2.0 update in xenocara, devel/ddd fails to build:
> 
> --->
> /usr/obj/ddd-3.3.12/ddd-3.3.12/ddd/exit.C:815:12: error: no matching function 
> for call to 'XtAppSetErrorHandler'
> (void) XtAppSetErrorHandler(app_context, ddd_xt_error);
>^~~~
> /usr/X11R6/include/X11/Intrinsic.h:1769:23: note: candidate function not 
> viable: no known conversion from 'void (String)' (aka 'void (char *)') to 
> 'void (*)(String) __attribute__((noreturn))' (aka 'void (*)(char *) 
> __attribute__((noreturn))') for 2nd argument
> extern XtErrorHandler XtAppSetErrorHandler(
>   ^
> <---
> 
> The respective code is this:
> 
> --->
> static void ddd_xt_error(String message = 0)
> {
> ...
> }
> 
> void ddd_install_xt_error(XtAppContext app_context)
> {
> (void) XtAppSetErrorHandler(app_context, ddd_xt_error);
> xt_error_app_context = app_context;
> }
> <---
> 
> And the corresponding change in libXt's  is this:
> 
> --->
>  extern XtErrorHandler XtAppSetErrorHandler(
>  XtAppContext  /* app_context */,
> -XtErrorHandler  /* handler */
> +XtErrorHandler  /* handler */ _X_NORETURN
>  );
> <---
> 
> So what's the proper way to fix this?  All I have been able to think
> of so far is adding _X_NORETURN to the definition of ddd_xt_error().
> 
> Index: patches/patch-ddd_exit_C
> ===
> RCS file: patches/patch-ddd_exit_C
> diff -N patches/patch-ddd_exit_C
> --- /dev/null 1 Jan 1970 00:00:00 -
> +++ patches/patch-ddd_exit_C  16 Jan 2020 20:30:07 -
> @@ -0,0 +1,14 @@
> +$OpenBSD$
> +
> +Index: ddd/exit.C
> +--- ddd/exit.C.orig
>  ddd/exit.C
> +@@ -769,7 +769,7 @@ static void PostXtErrorCB(XtPointer client_data, XtInt
> + 
> + static XtAppContext xt_error_app_context = 0;
> + 
> +-static void ddd_xt_error(String message = 0)
> ++static void ddd_xt_error(String message = 0) _X_NORETURN
> + {
> + ddd_has_crashed = true;
> + 
> -- 
> Christian "naddy" Weisgerber  na...@mips.inka.de

This looks like the correct fix to me.
I think only C++ cares about this kind of function signature changes.

-- 
Matthieu Herrb

Re: devel/ddd after libXt update

2020-01-16 Thread Stuart Henderson 
On 2020/01/16 21:57, Marc Espie wrote:
> On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote:
> > (ddd is cruft, the latest release dates from 2009, so this isn't
> > really important.)
> 
> What would you recommend as a "simple" gui frontend to (e)gdb then ?...
> 

https://www.gdbgui.com/ is probably about the nicest (it's browser-based),
but needs an annoying number of new/updated py-* ports.

If a curses UI will do there's always cgdb..

Re: devel/ddd after libXt update

2020-01-16 Thread Marc Espie 
On Thu, Jan 16, 2020 at 09:35:04PM +0100, Christian Weisgerber wrote:
> (ddd is cruft, the latest release dates from 2009, so this isn't
> really important.)

What would you recommend as a "simple" gui frontend to (e)gdb then ?...

devel/ddd after libXt update

2020-01-16 Thread Christian Weisgerber 
(ddd is cruft, the latest release dates from 2009, so this isn't
really important.)

After the libXt 1.2.0 update in xenocara, devel/ddd fails to build:

--->
/usr/obj/ddd-3.3.12/ddd-3.3.12/ddd/exit.C:815:12: error: no matching function 
for call to 'XtAppSetErrorHandler'
(void) XtAppSetErrorHandler(app_context, ddd_xt_error);
   ^~~~
/usr/X11R6/include/X11/Intrinsic.h:1769:23: note: candidate function not 
viable: no known conversion from 'void (String)' (aka 'void (char *)') to 'void 
(*)(String) __attribute__((noreturn))' (aka 'void (*)(char *) 
__attribute__((noreturn))') for 2nd argument
extern XtErrorHandler XtAppSetErrorHandler(
  ^
<---

The respective code is this:

--->
static void ddd_xt_error(String message = 0)
{
...
}

void ddd_install_xt_error(XtAppContext app_context)
{
(void) XtAppSetErrorHandler(app_context, ddd_xt_error);
xt_error_app_context = app_context;
}
<---

And the corresponding change in libXt's  is this:

--->
 extern XtErrorHandler XtAppSetErrorHandler(
 XtAppContext  /* app_context */,
-XtErrorHandler  /* handler */
+XtErrorHandler  /* handler */ _X_NORETURN
 );
<---

So what's the proper way to fix this?  All I have been able to think
of so far is adding _X_NORETURN to the definition of ddd_xt_error().

Index: patches/patch-ddd_exit_C
===
RCS file: patches/patch-ddd_exit_C
diff -N patches/patch-ddd_exit_C
--- /dev/null   1 Jan 1970 00:00:00 -
+++ patches/patch-ddd_exit_C16 Jan 2020 20:30:07 -
@@ -0,0 +1,14 @@
+$OpenBSD$
+
+Index: ddd/exit.C
+--- ddd/exit.C.orig
 ddd/exit.C
+@@ -769,7 +769,7 @@ static void PostXtErrorCB(XtPointer client_data, XtInt
+ 
+ static XtAppContext xt_error_app_context = 0;
+ 
+-static void ddd_xt_error(String message = 0)
++static void ddd_xt_error(String message = 0) _X_NORETURN
+ {
+ ddd_has_crashed = true;
+ 
-- 
Christian "naddy" Weisgerber  na...@mips.inka.de