Skip to content

Conversation

prbprbprb
Copy link
Contributor

This should be the correct fix for the build issues that came up on recent ECH changes.

Background: Unless you install Clang and take steps to make it the default compiler, then on many Linux distributions (esp Ubuntu) the JNI code will get built with gcc.

gcc does not consider casting to void is sufficient to avoid a warning about unused returns from a function which has the warn_unused_result attribute.

This change assigns the result to a variable with the CONSCRYPT_UNUSED attribute which works correctly on Clang, gcc and MSVC.

As for why it's OK in these cases:

The asprintf methods should probably not ignore the value but they're calling FatalError with the result so it's game over anyway. This method could use re-writing but not this PR.

The read and write on fdsEmergency in native_crypto is part of an "interesting" mechanism to prevent blocking forever when using the ConscryptFileDescriptorSocket implementation, which ought to go away but works as-is.

This should be the correct fix for the build issues that came up on
recent ECH changes.

Background: Unless you install Clang and take steps to make it the
default compiler, then  on many Linux distributions (esp Ubuntu) the
JNI code will get built with gcc.

gcc does not consider casting to void is sufficient to avoid a warning
about unused returns from a function which has the warn_unused_result
attribute.

This change assigns the result to a variable with the CONSCRYPT_UNUSED
attribute which works correctly on Clang, gcc and MSVC.

As for why it's OK in these cases:

The asprintf methods should probably *not* ignore the value but
they're calling FatalError with the result so it's game over anyway.
This method could use re-writing but not this PR.

The read and write on fdsEmergency in native_crypto is part of an
"interesting" mechanism to prevent blocking forever when using the
ConscryptFileDescriptorSocket implementation, which ought to go away
but works as-is.
@prbprbprb
Copy link
Contributor Author

Historic discussion about gcc's behaviour: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 😄

@tweksteen tweksteen merged commit 82eb558 into google:master Oct 8, 2025
39 checks passed
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.

2 participants