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.

Sign up for GitHub

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

Jump to bottom

Adjust the use of CETL_NODISCARD #350

Closed
pavel-kirienko opened this issue Apr 24, 2024 · 1 comment
Closed

Adjust the use of CETL_NODISCARD #350

pavel-kirienko opened this issue Apr 24, 2024 · 1 comment
Assignees
@serges147
Labels
class-requirement Issue that can be traced back to a design requiement domain-production Pertains to the shippable code rather than any scaffolding priority-low A minor issue

Comments

@pavel-kirienko
Copy link
Member

  • All non-void internal functions can (should) continue using CETL_NODISCARD.

  • User-facing (API) functions can only use CETL_NODISCARD where unused return value may lead to a resource leak or some other disaster.
@pavel-kirienko pavel-kirienko added priority-low A minor issue domain-production Pertains to the shippable code rather than any scaffolding class-requirement Issue that can be traced back to a design requiement labels Apr 24, 2024
@pavel-kirienko pavel-kirienko mentioned this issue Apr 25, 2024
Merged
@serges147 serges147 mentioned this issue May 13, 2024
Merged
serges147 added a commit that referenced this issue May 14, 2024
@serges147 @sshirokov-mwb @pavel-kirienko
No CETL_NODISCARD for most of the public api (#359)
abcfc14 
No `CETL_NODISCARD` for the most of public api (issue #350), but private
(aka `detail`) stuff stays under strict `[[nodiscard]]` policy for all
non-`void` returning functions.

Also:
- Less `NOSONAR`-s by switching some internal `void*`-s →
`cetl::byte*`-s.
- Eliminated `IMultiplexer` at CAN - no use of it; but will be at UDP.
- More docs for public api.
- Fixed Build Status and Sonar Cloud badges at `README.md`.

---------

Co-authored-by: Sergei Shirokov <sshirokov@malwarebytes.com>
Co-authored-by: Pavel Kirienko <pavel.kirienko@gmail.com>
@serges147
Copy link
Collaborator

Closing as it was addressed by PR 359

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@serges147 serges147

Labels
class-requirement Issue that can be traced back to a design requiement domain-production Pertains to the shippable code rather than any scaffolding priority-low A minor issue
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@serges147 @pavel-kirienko