Thanks for the report...

(In reply to Michal Jireš from comment #0)
> Building autofs with GCC 14 fails here:
> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:
> Gcc7/autofs/standard/x86_64
> 
> Due to (exhaustive list of errors):
> 
> cyrus-sasl.c:112:25: error: initialization of ‘int (*)(void)’ from
> incompatible pointer type ‘int (*)(void *, int,  const char **, unsigned int
> *)’ [-Wincompatible-pointer-types]
>   112 |         { SASL_CB_USER, &getuser_func, NULL },
...

This appears to be due to the somewhat confusing sasl_callback_t interface provided via cyrus-sasl's sasl.h:

 350 /*
 351  * Extensible type for a client/server callbacks
 352  *  id      -- identifies callback type
 353  *  proc    -- procedure call arguments vary based on id
 354  *  context -- context passed to procedure
 355  */
 356 /* Note that any memory that is allocated by the callback needs to be
 357  * freed by the application, be it via function call or interaction.
 358  *
 359  * It may be freed after sasl_*_step returns SASL_OK.  if the mechanism
 360  * requires this information to persist (for a security layer, for example)
 361  * it must maintain a private copy.
 362  */
 363 typedef struct sasl_callback {
 364     /* Identifies the type of the callback function.
 365      * Mechanisms must ignore callbacks with id's they don't recognize.
 366      */
 367     unsigned long id;
 368     int (*proc)(void);   /* Callback function.  Types of arguments vary by 'id' */
 369     void *context;
 370 } sasl_callback_t;

So the @proc function pointer's arguments are *supposed* to vary based on id, but it's declared parameter list is (void).
I wonder whether the sasl_callback_t.proc entry could get away with an unnamed union covering all argument cases for a valid @id?

(In reply to Michal Jireš from comment #0)
...
> ./autofs-5.1.9/config.log: conftest.c: In function 'main':
> ./autofs-5.1.9/config.log: conftest.c:58:47: error: passing argument 4 of
> 'ldap_parse_page_control' from incompatible pointer type
> [-Wincompatible-pointer-types]
> ./autofs-5.1.9/config.log:    58 |       ret =
> ldap_parse_page_control(ld,clp,ct,c);
> ./autofs-5.1.9/config.log:       |                                          
> ^
> ./autofs-5.1.9/config.log:       |                                          
> |
> ./autofs-5.1.9/config.log:       |                                          
> struct berval *
> ./autofs-5.1.9/config.log: In file included from
> /usr/include/lber_types.h:24,
> ./autofs-5.1.9/config.log:                  from /usr/include/lber.h:29,
> ./autofs-5.1.9/config.log:                  from /usr/include/ldap.h:30,
> ./autofs-5.1.9/config.log:                  from conftest.c:49:
> ./autofs-5.1.9/config.log: /usr/include/ldap.h:2155:25: note: expected
> 'struct berval **' but argument is of type 'struct berval *'
> ./autofs-5.1.9/config.log:  2155 | ldap_parse_page_control LDAP_P((
> ./autofs-5.1.9/config.log:       |                         ^~~~~~
> 
> 
> 
> Fixing configure may not be necessary to build the package, but it might be
> an indication that the package will be misconfigured.

Yeah, this looks like a bug in autofs. I'll propose the following fix upstream:
--- a/aclocal.m4
+++ b/aclocal.m4
@@ -424,7 +424,7 @@ AC_LINK_IFELSE(
       #include <ldap.h> ]],
    [[ LDAP *ld;
       ber_int_t *ct;
-      struct berval *c;
+      struct berval **c;
       int ret;
       LDAPControl **clp;
       ret = ldap_parse_page_control(ld,clp,ct,c); ]])],

(In reply to David Disseldorp from comment #2)
> (In reply to Michal Jireš from comment #0)
...
> > Fixing configure may not be necessary to build the package, but it might be
> > an indication that the package will be misconfigured.
> 
> Yeah, this looks like a bug in autofs. I'll propose the following fix
> upstream:
> --- a/aclocal.m4
> +++ b/aclocal.m4
> @@ -424,7 +424,7 @@ AC_LINK_IFELSE(
>        #include <ldap.h> ]],
>     [[ LDAP *ld;
>        ber_int_t *ct;
> -      struct berval *c;
> +      struct berval **c;
>        int ret;
>        LDAPControl **clp;
>        ret = ldap_parse_page_control(ld,clp,ct,c); ]])],

I've posted this upstream and submitted:
https://build.opensuse.org/request/show/1159674

As mentioned in comment#1 , I think the cyrus-sasl callback interface deserves to be tracked as a separate bug. @Michal: if you agree, could you raise a ticket?
I think this can be closed once cyrus-sasl is tracked elsewhere.

(In reply to David Disseldorp from comment #3)
...
> As mentioned in comment#1 , I think the cyrus-sasl callback interface
> deserves to be tracked as a separate bug. @Michal: if you agree, could you
> raise a ticket?
> I think this can be closed once cyrus-sasl is tracked elsewhere.

I've added an autofs cast workaround for the type-unsafe cyrus-sasl sasl_callback_t interface. I still think it warrants a separate cyrus-sasl ticket, but it'll do for now.

> I wonder whether the sasl_callback_t.proc entry could get away with an unnamed 
> union covering all argument cases for a valid @id?

Quickly looking at cyrus-sasl's saslplug.h, *unnamed* union would not be enough:
 36 typedef int (*sasl_callback_ft)(void);
 37 typedef int sasl_getcallback_t(sasl_conn_t *conn,
 38              unsigned long callbackid,
 39              sasl_callback_ft * pproc,
 40              void **pcontext);


> As mentioned in comment#1 , I think the cyrus-sasl callback interface
> deserves to be tracked as a separate bug. @Michal: if you agree, could you
> raise a ticket?
> I think this can be closed once cyrus-sasl is tracked elsewhere.

I don't see a problem with the sasl_callback_t interface (at least not more than with void* ).
Maybe using:
void (*proc)(void);
could be slightly preferable. At least it suppresses warnings and makes it a bit clearer that it is a generic function pointer.

I am not convinced that using union would improve type-safety by much.
So I would leave it as it is.



Sorry for the delay.

(In reply to Michal Jireš from comment #5)
> > I wonder whether the sasl_callback_t.proc entry could get away with an unnamed 
> > union covering all argument cases for a valid @id?
> 
> Quickly looking at cyrus-sasl's saslplug.h, *unnamed* union would not be
> enough:
>  36 typedef int (*sasl_callback_ft)(void);
>  37 typedef int sasl_getcallback_t(sasl_conn_t *conn,
>  38              unsigned long callbackid,
>  39              sasl_callback_ft * pproc,
>  40              void **pcontext);
> 
> 
> > As mentioned in comment#1 , I think the cyrus-sasl callback interface
> > deserves to be tracked as a separate bug. @Michal: if you agree, could you
> > raise a ticket?
> > I think this can be closed once cyrus-sasl is tracked elsewhere.
> 
> I don't see a problem with the sasl_callback_t interface (at least not more
> than with void* ).
> Maybe using:
> void (*proc)(void);
> could be slightly preferable. At least it suppresses warnings and makes it a
> bit clearer that it is a generic function pointer.

The callback API types have a different number of arguments passed. As-is it would appear that it's easy to have a mismatch between caller and callee function parameters... Couldn't that lead callback functions to access caller-uninitialized registers, if the caller passed fewer parameters than expected?

Anyhow, I'm also okay with leaving it as is if that's your preference. This can be closed once https://build.opensuse.org/request/show/1160083 is merged.

*** Bug 1225755 has been marked as a duplicate of this bug. ***

(In reply to David Disseldorp from comment #6)
> 
> Anyhow, I'm also okay with leaving it as is if that's your preference. This
> can be closed once https://build.opensuse.org/request/show/1160083 is merged.

Even with this merge request accepted, build of the package is still failing because of an from incompatible pointer type argument, see:

https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:Gcc7/autofs/standard/x86_64

You can test your build locally with osc build --clean --alternative-project home:rguenther:nextgcc

The failure (that halts the build) is:


[   15s] lookup_udisks.c: In function ‘parse_config’:
[   15s] lookup_udisks.c:1527:41: error: passing argument 2 of ‘xmlSetStructuredErrorFunc’ from incompatible pointer type [-Wincompatible-pointer-types]
[   15s]  1527 |         xmlSetStructuredErrorFunc(ctxt, &xmlerror);
[   15s]       |                                         ^~~~~~~~~
[   15s]       |                                         |
[   15s]       |                                         void (*)(void *, xmlError *) {aka void (*)(void *, struct _xmlError *)}
[   15s] In file included from /usr/include/libxml/valid.h:15,
[   15s]                  from /usr/include/libxml/parser.h:19,
[   15s]                  from lookup_udisks.c:29:
[   15s] /usr/include/libxml/xmlerror.h:898:57: note: expected ‘xmlStructuredErrorFunc’ {aka ‘void (*)(void *, const struct _xmlError *)’} but argument is of type ‘void (*)(void *, xmlError *)’ {aka ‘void (*)(void *, struct _xmlError *)’}
[   15s]   898 |                                  xmlStructuredErrorFunc handler);
[   15s]       |                                  ~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~

(In reply to Martin Jambor from comment #8)
> (In reply to David Disseldorp from comment #6)
> > 
> > Anyhow, I'm also okay with leaving it as is if that's your preference. This
> > can be closed once https://build.opensuse.org/request/show/1160083 is merged.
> 
> Even with this merge request accepted, build of the package is still failing
> because of an from incompatible pointer type argument, see:
> 
> https://build.opensuse.org/package/live_build_log/openSUSE:Factory:Staging:
> Gcc7/autofs/standard/x86_64
> 
> You can test your build locally with osc build --clean --alternative-project
> home:rguenther:nextgcc

Thanks for providing the local test instructions.
I've submitted a fix for this via https://build.opensuse.org/request/show/1178204 .