-
Notifications
You must be signed in to change notification settings - Fork 2.1k
tests/sys/libc_newlib: drop test #21669
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
Conversation
This tests makes little sense to have for a number of reasons:
1. One should not use `iprintf()` for a number of reasons:
1. It is non-standard and using it over `printf()` makes the code
less portable (e.g. it cannot be used on AVR)
2. The idea of adding a leaner variant of `printf()` in addition to
the larger one is bogus, as apps will end up using both resulting
in a *larger* firmware instead of a smaller
3. RIOT's build system already has the `printf_float` module to
control whether formatting of floating point numbers should be
suppered. This mechanism will actually result in smaller builds,
if floating point support is not needed, as it prevents two
variants of printf to be linked in.
2. The test checks some implementation details (e.g. whether the
address of two functions is identical), rather than correct behavior
of the implementation. This is completely bogus.
|
Was that test ever executed by our CI system? I don't think there is a test configuration which would set |
|
The boards that use newlib by default have a So this should indeed be executed. The fact that this fails in a PR that makes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I concur with your assessment. As this test is broken when replacing newlib's printf implementation by pkg/mpaland-printf, I think we can drop this test since it is a bit fragile anyway.
Contribution description
This tests makes little sense to have for a number of reasons:
iprintf()for a number of reasons:printf()makes the code less portable (e.g. it cannot be used on AVR)printf()in addition to the larger one is bogus, as apps will end up using both resulting in a larger firmware instead of a smallerprintf_floatmodule to control whether formatting of floating point numbers should be suppered. This mechanism will actually result in smaller builds, if floating point support is not needed, as it prevents two variants of printf to be linked in.Testing procedure
Happy CI
Issues/PRs references
#9599 introduced this test.
As can be seen in the PR, the point of the test is to check whether using
nano.specsfrom newlib via the modulenewlib_nanohas the intended effect. But since it is up to whoever is building / packaging newlib to decide whether to provide anano.specsat all and how thenano.specsvariant is configured, this way of testing does not appear to be super valid.