-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Various warning fixes #3101
Conversation
@@ -55,7 +55,7 @@ int random_read(char *buf, unsigned int num) | |||
} | |||
} | |||
|
|||
return count; | |||
return (int)count; |
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.
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)?
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 think the intention is to be able to return error codes as negative values.
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.
Yes, I assumed that. But at least theoretical this could lead to a problem, if you specify a crazy big value.
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.
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 validReturns
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.
@OlegHahm I usually assign you whenever I don't know who to assign a PR, is that OK? |
I noticed that. ;)
Yes, it's completely okay. I will re-assign whenever I don't have time or knowledge for the PR to review. |
what does this Travis error even mean? (
|
I think it's a Travis problem. |
@PeterKietzmann, can you look at the periph stuff? |
Travis is green after I restarted the build. |
Will look at it tomorrow. |
7f0919a
to
101e022
Compare
rebased |
#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 |
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 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
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.
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
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.
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++) { |
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.
Maybe less changes if you initialize i
as unsigned int? Anyway...
@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. |
101e022
to
2ae8055
Compare
Rebased, split the buffer overflow fix into a separate PR #3110 |
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.
2ae8055
to
00367ab
Compare
- 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
00367ab
to
ea597a3
Compare
squashed |
ping @PeterKietzmann |
Sorry for the delay. I'm fine with the list of commits. ACK and go |
This PR fixes all warnings that I encountered when adding with
-Wall -Wextra
toMakefile.include
and buildingexamples/rpl_udp
for mulle andexamples/default
for stm32f4discoveryMost warnings were harmless but there were a few mistakes that were corrected as well:
Potential buffer overflow insplit to sys/newlib/syscalls: _read_r fix potential buffer overflow #3110sys/newlib/syscalls.c
(_read_r()
)__set_FPSCR
when building for Cortex-M4 without FPU - duplicated in Cortex-M CMSIS: Update CMSIS to version 4.3 #3128