Skip to content

NVStore.cpp compiler warning removal (os_ret) #10485

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

Merged
merged 1 commit into from
May 3, 2019

Conversation

JanneKiiskila
Copy link
Contributor

@JanneKiiskila JanneKiiskila commented Apr 25, 2019

Description

One gets this compiler warning from nvstore.cpp:

Compile [ 48.6%]: nvstore.cpp
[Warning] nvstore.cpp@814,9: variable 'os_ret' set but not used [-Wunused-but-set-variable]

Turns out it's caused by the fact that the variable is only used
with MBED_ASSERTs, which get optimized out or not, depending on your
build profile. In reality we do not need a separate variable for that
in my opinion though, so we can just use the ret-variable instead
and drop the os_ret variable completely and thus avoid this
compiler warning.

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@davidsaada @bulislaw

One gets this compiler warning from nvstore.cpp:

```
Compile [ 48.6%]: nvstore.cpp
[Warning] nvstore.cpp@814,9: variable 'os_ret' set but not used [-Wunused-but-set-variable]
```

Turns out it's caused by the fact that the variable is only used
with MBED_ASSERTs, which get optimized out or not, depending on your
build profile. In reality we do not need a separate variable for that
in my opinion though, so we can just use the ret-variable instead
and drop the os_ret variable completely and thus avoid this
compiler warning.
@ciarmcom ciarmcom requested review from bulislaw, davidsaada and a team April 25, 2019 21:00
@ciarmcom
Copy link
Member

@JanneKiiskila, thank you for your changes.
@bulislaw @davidsaada @ARMmbed/mbed-os-storage @ARMmbed/mbed-os-maintainers please review.

os_ret = flash_erase_area(area);
MBED_ASSERT(!os_ret);
ret = flash_erase_area(area);
MBED_ASSERT(!ret);
Copy link
Contributor

Choose a reason for hiding this comment

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

It is slightly worrying that the errors due to HW problems are detected only on debug-builds. If the remaining code survives from storage error, what is the point of assert here?

Copy link
Contributor

@kjbracey kjbracey Apr 26, 2019

Choose a reason for hiding this comment

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

Do we expect hardware problems to be indicated by error returns from flash functions though?

It's quite possible that the only error returns would be for parameter errors like address being out of range, and we only find out flash failure by actually trying to use it and finding it doesn't hold data correctly.

But I would agree that if these functions can indicate hardware problems, there should be paths to deal with that. Asserts should be reserved for catching should-be-impossible design errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Tend to agree here. :-) But, well out of scope for this PR in a way.

Copy link
Contributor

Choose a reason for hiding this comment

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

Tend to agree here. :-) But, well out of scope for this PR in a way.

Please create a tracking issue for this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done, IOTSTOR-832

Copy link
Contributor

Choose a reason for hiding this comment

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

@kjbracey-arm at least some drivers seem to notify HW/driver problems, not just user errors:

ret = flash_erase_sector(&_flash, addr);

->
int32_t flash_erase_sector(flash_t *obj, uint32_t address)
{
(void)(obj);
int32_t status = 0;
if (Cy_Flash_EraseRow(address) != CY_FLASH_DRV_SUCCESS) {
status = -1;
}
return status;
}

@JanneKiiskila
Copy link
Contributor Author

@JanneKiiskila
Copy link
Contributor Author

@adbridge @0xc0170 - can we merge this one in, please? One warning less, future work saved to backlog.

@adbridge
Copy link
Contributor

adbridge commented May 2, 2019

@TeroJaasko @kjbracey-arm are you happy for this to go in as is ?

@adbridge
Copy link
Contributor

adbridge commented May 2, 2019

@JanneKiiskila has to be approved by the reviewers and go through CI successfully before it can be 'merged' in :)

@0xc0170
Copy link
Contributor

0xc0170 commented May 2, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented May 2, 2019

Test run: SUCCESS

Summary: 11 of 11 test jobs passed
Build number : 1
Build artifacts

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

Successfully merging this pull request may close these issues.

8 participants