Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix warnings in static inline functions in installed headers #8870

Closed

Conversation

ggirol-rc
Copy link

= { 0 } has different meaning in C and C++: in C it initialises all members to 0, in C++ only the first one so the compiler warns that other members are not initialised. Use an empty initialiser list instead.

It's not very pretty; if you prefer a different style let me know :)

= { 0 } has different meaning in C and C++: in C it initialises all
members to 0, in C++ only the first one so the compiler warns that other
members are not initialised. Use an empty initialiser list instead.
@freerdp-bot
Copy link

Can one of the admins verify this patch?

Copy link
Contributor

@hardening hardening left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for that, I've been bothered by it too.

@hardening
Copy link
Contributor

@freerdp-bot can you test that my friend ?

@freerdp-bot
Copy link

Refer to this link for build results (access rights to CI server needed):
https://ci.freerdp.com//job/PullRequestTester/9297/

Copy link
Member

@akallabeth akallabeth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Already changed in #8866

*pcbe = empty;
pcbe->Version = 1;
}

static INLINE VOID DestroyThreadpoolEnvironment(PTP_CALLBACK_ENVIRON pcbe)
{
/* no actions, this may change in a future release. */
(void)pcbe;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better use WINPR_UNUSED

@akallabeth
Copy link
Member

Looking at these functions, it might be the better option to make them normal functions.
We´d run into trouble if we change something in that code as it will always be ABI breaking and these functions are exposed via API to potential 3rd party software.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants