Skip to content
New issue

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

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

Already on GitHub? # to your account

Various warning fixes #3101

Merged
merged 10 commits into from
May 31, 2015
Merged

Conversation

jnohlgard
Copy link
Member

This PR fixes all warnings that I encountered when adding with -Wall -Wextra to Makefile.include and building examples/rpl_udp for mulle and examples/default for stm32f4discovery

Most warnings were harmless but there were a few mistakes that were corrected as well:

@jnohlgard jnohlgard added Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation labels May 28, 2015
@jnohlgard jnohlgard added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label May 28, 2015
@@ -55,7 +55,7 @@ int random_read(char *buf, unsigned int num)
}
}

return count;
return (int)count;
Copy link
Member

Choose a reason for hiding this comment

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

Without looking further into this: Isn't the logic of this prototype here somehow broken: parameter for the count is unsigned, but the returning count value is signed (and therefore only half the size for possible values)?

Copy link
Member Author

Choose a reason for hiding this comment

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

I think the intention is to be able to return error codes as negative values.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, I assumed that. But at least theoretical this could lead to a problem, if you specify a crazy big value.

Copy link
Member Author

Choose a reason for hiding this comment

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

yes, and it will take a crazy long time to generate that entropy. But I think this is an actual API bug. The documentation for periph/random.h says:

Reads num or less bytes of randomness from the source, will block until random data is available.

Parameters
[in] buf destination buffer to write the bytes to
[in] num number of bytes to get from device, only values >0 are valid

Returns
the number of bytes written to buf
0 on error

so I guess we should update either the return type or the docs. My vote is for the return type.

@jnohlgard
Copy link
Member Author

@OlegHahm I usually assign you whenever I don't know who to assign a PR, is that OK?
(you may of course reassign, I believe you have a better overview of the project resources than I do)

@OlegHahm
Copy link
Member

I usually assign you whenever I don't know who to assign a PR

I noticed that. ;)

is that OK?
(you may of course reassign, I believe you have a better overview of the project resources than I do)

Yes, it's completely okay. I will re-assign whenever I don't have time or knowledge for the PR to review.

@jnohlgard
Copy link
Member Author

what does this Travis error even mean? (BUILDTEST_MCU_GROUP=arm7)

$ ./dist/tools/travis-scripts/build_and_test.sh
The command "./dist/tools/travis-scripts/build_and_test.sh" exited with 8.

@OlegHahm
Copy link
Member

I think it's a Travis problem.

@OlegHahm OlegHahm assigned PeterKietzmann and unassigned OlegHahm May 28, 2015
@OlegHahm
Copy link
Member

@PeterKietzmann, can you look at the periph stuff?

@jnohlgard
Copy link
Member Author

Travis is green after I restarted the build.

@PeterKietzmann
Copy link
Member

Will look at it tomorrow.

@jnohlgard
Copy link
Member Author

rebased

@OlegHahm OlegHahm modified the milestone: Release 2015.06 May 28, 2015
#if SPI_7_EN && (SPI_7_INDEX != SPI_0_INDEX) && (SPI_7_INDEX != SPI_1_INDEX) \
&& (SPI_7_INDEX != SPI_2_INDEX) && (SPI_7_INDEX != SPI_3_INDEX) \
&& (SPI_7_INDEX != SPI_4_INDEX) && (SPI_7_INDEX != SPI_5_INDEX) \
&& (SPI_7_INDEX != SPI_6_INDEX)
[SPI_7_INDEX] = MUTEX_INIT,
#endif
Copy link
Member

Choose a reason for hiding this comment

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

I agree, this looks strange somehow :/ . Isn't there a nicer way to check all combinations? Like an extra macro? Anyway, as it fixes warnings I won't NACK this

Copy link
Member Author

Choose a reason for hiding this comment

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

This was the most direct way I could imagine. The main problem is that the preprocessor can not perform loops or anything other than simple evaluations of the value of macro expressions. I believe we can refactor this if we rework the periph API as is being discussed in #3095

Copy link
Member

Choose a reason for hiding this comment

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

Yes ok, I'm fine for the moment

@@ -1041,13 +1056,13 @@ int spi_transfer_bytes(spi_t dev, char *out, char *in, unsigned int length)
/* Default: send idle data */
byte_out = (uint8_t)SPI_IDLE_DATA;

for (i = 0; i < length; i++) {
for (i = 0; i < (int)length; i++) {
Copy link
Member

Choose a reason for hiding this comment

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

Maybe less changes if you initialize i as unsigned int? Anyway...

@PeterKietzmann
Copy link
Member

@gebart thanks for this work. There is the question about the return values and the buffer overflow thing that you wanted to put in a separate PR.

@jnohlgard jnohlgard added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label May 29, 2015
@jnohlgard
Copy link
Member Author

Rebased, split the buffer overflow fix into a separate PR #3110
changed return type on the find scaler functions to long

@PeterKietzmann
Copy link
Member

@OlegHahm are you also fine with merging this and further discuss the open points in #3109 and #3111? I tend to give my ACK. Just one thing: isn't the first commit message a bit too long?

@PeterKietzmann
Copy link
Member

BTW: I think it's reasonable to squash into 4-5 commits. Non?

It is an error to call __set_FPSCR if no FPU is present in the CPU.
Joakim Gebart added 9 commits May 29, 2015 14:21
 - find_closest_x: sign-compare
 - hwtimer_arch: unused-parameter
 - i2c_init_slave: unused-parameter
 - rnga: sign-compare
 - rngb: sign-compare
 - spi_transfer_bytes: sign-compare
 - spi_transfer_regs: sign-compare
 - timer: unused-parameter
 - rx_cb: unused-parameter
 - _write_r: sign-compare
 - all stubbed syscalls: unused-parameter
@jnohlgard
Copy link
Member Author

squashed

@jnohlgard jnohlgard removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label May 30, 2015
@jnohlgard
Copy link
Member Author

ping @PeterKietzmann
Travis is green, is the current list of commits OK?

@PeterKietzmann
Copy link
Member

Sorry for the delay. I'm fine with the list of commits. ACK and go

PeterKietzmann added a commit that referenced this pull request May 31, 2015
@PeterKietzmann PeterKietzmann merged commit 6dc0e78 into RIOT-OS:master May 31, 2015
@jnohlgard jnohlgard deleted the pr/warning-fixes branch June 25, 2015 08:01
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Type: cleanup The issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants