Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 894684 - dev-libs/cyrus-sasl: minor compilation issue of srp plugin (plugins/srp_init.c:41:1: warning: type of 'srp_client_plug_init' does not match original declaration [-Wlto-type-mismatch])
Summary: dev-libs/cyrus-sasl: minor compilation issue of srp plugin (plugins/srp_init....
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks: lto
  Show dependency tree
 
Reported: 2023-02-16 06:49 UTC by Jocelyn Mayer
Modified: 2023-02-16 19:22 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
cyrus-sasl srp plugin patch to avoid the described warnings (cyrus-sasl-2.1.28-srp_plug_init.patch,712 bytes, patch)
2023-02-16 06:49 UTC, Jocelyn Mayer
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jocelyn Mayer 2023-02-16 06:49:19 UTC
Created attachment 851510 [details, diff]
cyrus-sasl srp plugin patch to avoid the described warnings

The src_client_plug_init / src_server_plug_init functions implementations in plugins/srp.c have a last "plugname" unused argument which is not in the prototype generated by the SASL_CLIENT_PLUG_INIT / SASL_SERVER_PLUG_INIT macros from common/plugin_common.h
This leads to 2 compilations warnings:
cyrus-sasl-2.1.28/plugins/srp_init.c:41:1:
warning: type of 'srp_client_plug_init' does not match original declaration [-Wlto-type-mismatch]
cyrus-sasl-2.1.28/plugins/srp_init.c:42:1:
warning: type of 'srp_server_plug_init' does not match original declaration [-Wlto-type-mismatch]

This can easily be avoided by removing the plugname argument (patch following).
As this minor issue seems to still be present in trunk code, a ticket has been opened at cyrus-sasl repository:
https://github.com/cyrusimap/cyrus-sasl/issues/757
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-16 07:05:53 UTC
Good spot. Thanks for filing these, code quality is important.

FWIW: for the upstream reports, most projects will prefer a PR rather than an inline patch in a bug, but if you're giving a patch in a bug upstream (no need if attaching), make sure to use Markdown so it renders ok, like this:
```
--- a/foo.c
+++ b/foo.c
...
```

(it's just 3 backticks above/below the 'code' bit)
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-02-16 07:07:34 UTC
It's possible that the unused int is there for ABI reasons (so they can add something later without breaking ABI), but it's a bit weird. So they might prefer to do something else to fix the warning.
Comment 3 Jocelyn Mayer 2023-02-16 19:18:21 UTC
(In reply to Sam James from comment #1)
> Good spot. Thanks for filing these, code quality is important.
> 
> FWIW: for the upstream reports, most projects will prefer a PR rather than
> an inline patch in a bug, but if you're giving a patch in a bug upstream (no
> need if attaching), make sure to use Markdown so it renders ok, like this:
> ```
> --- a/foo.c
> +++ b/foo.c
> ...
> ```
> 
> (it's just 3 backticks above/below the 'code' bit)

oh, OK, I did not check the view in the upstream ticket...
Just updated the inline patch upstream...
Comment 4 Jocelyn Mayer 2023-02-16 19:22:46 UTC
(In reply to Sam James from comment #2)
> It's possible that the unused int is there for ABI reasons (so they can add
> something later without breaking ABI), but it's a bit weird. So they might
> prefer to do something else to fix the warning.

it does not seem to me that this is the case as the macro used to define the headers declaration for plugins init routine does not declare this argument.
Then, using it from a caller would lead to some kind of issues, I guess.
And, as it seems, other plugins using this macro do not implement this extra argument...
Upstream will decide the best way to fix it...