Add inet_pton and inet_ntop (POSIX.1-2001) #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
OlegHahm
added a commit
that referenced
this pull request
Feb 8, 2013
…c9bfca8 Add inet_pton and inet_ntop (POSIX.1-2001)
rousselk
added a commit
that referenced
this pull request
Feb 17, 2014
implement rudimentary native reboot
jnohlgard
referenced
this pull request
in jnohlgard/RIOT
Jan 11, 2015
kinetis: Add RTC Load Capacitance configuration.
murdock-ci
pushed a commit
to murdock-ci/RIOT
that referenced
this pull request
Mar 31, 2017
roberthartung
added a commit
to roberthartung/RIOT
that referenced
this pull request
Jun 28, 2017
roberthartung
added a commit
to roberthartung/RIOT
that referenced
this pull request
Jul 24, 2017
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Feb 2, 2018
boards/jiminy: clean up initial PR
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Mar 3, 2018
memarray: Added testing application
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Apr 23, 2018
pkg/openthread: fix uart
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jun 12, 2018
drivers/mhz19: Integrated PWM with UART driver
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jun 20, 2018
ZetaR60
pushed a commit
to ZetaR60/RIOT
that referenced
this pull request
Jun 30, 2018
latest: Add cppcheck and doxygen for static tests
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jul 7, 2019
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "RIOT-OS#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "RIOT-OS#1 supposed to be 1581" At 4035 ms received msg 3: "RIOT-OS#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jul 9, 2019
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "RIOT-OS#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "RIOT-OS#1 supposed to be 1581" At 4035 ms received msg 3: "RIOT-OS#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jul 15, 2019
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "RIOT-OS#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "RIOT-OS#1 supposed to be 1581" At 4035 ms received msg 3: "RIOT-OS#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
This was referenced Jul 16, 2019
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jul 16, 2019
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "RIOT-OS#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "RIOT-OS#1 supposed to be 1581" At 4035 ms received msg 3: "RIOT-OS#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jul 17, 2019
The evtimer_msg test is expanded to also delete entries. Furthermore the messages that are printed should now show numbers that are very close (if not equal). Something like this: At 740 ms received msg 0: "RIOT-OS#2 supposed to be 740" At 1081 ms received msg 1: "#0 supposed to be 1081" At 1581 ms received msg 2: "RIOT-OS#1 supposed to be 1581" At 4035 ms received msg 3: "RIOT-OS#3 supposed to be 4035" The function evtimer_print is also called to show the intermediate status of evtimer entries.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Sep 2, 2019
The test randomly fails on `native` due to timers being not accurate but
it cannot be otherwise. So better disable it than raising fake errors.
main(): This is RIOT! (Version: buildtest)
Testing generic evtimer
This should list 2 items
ev RIOT-OS#1 offset=1000
ev RIOT-OS#2 offset=500
This should list 4 items
ev RIOT-OS#1 offset=659
ev RIOT-OS#2 offset=341
ev RIOT-OS#3 offset=500
ev RIOT-OS#4 offset=2454
Are the reception times of all 4 msgs close to the supposed values?
At 662 ms received msg 0: "RIOT-OS#2 supposed to be 659"
At 1009 ms received msg 1: "#0 supposed to be 1000"
At 1511 ms received msg 2: "RIOT-OS#1 supposed to be 1500"
Traceback (most recent call last):
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 33, in <module>
sys.exit(run(testfunc))
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/dist/pythonlibs/testrunner/__init__.py", line 29, in run
testfunc(child)
File "/tmp/dwq.0.3125418833043728/ef3af88c4b3615788b164464a437df5c/tests/evtimer_msg/tests/01-run.py", line 26, in testfunc
assert(actual in range(expected - ACCEPTED_ERROR, expected + ACCEPTED_ERROR))
AssertionError
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Nov 7, 2019
drivers/dcf77: add dcf77_set_tick_cb()
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Dec 13, 2019
stm32l010xx: add remaining vendor files
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Mar 25, 2020
The ROM size is encoded in the part number of the Atmel SAM chips. RAM size is not encoded directly, so get it by parsing the chip's vendor file. The file remains in the page cache for the compiler to use, so the overhead should be minimal: on master: Benchmark RIOT-OS#1: make BOARD=samr21-xpro -j Time (mean ± σ): 527.9 ms ± 4.9 ms [User: 503.1 ms, System: 69.6 ms] Range (min … max): 519.7 ms … 537.2 ms 10 runs with this patch: Benchmark RIOT-OS#1: make BOARD=samr21-xpro -j Time (mean ± σ): 535.6 ms ± 4.0 ms [User: 507.6 ms, System: 75.1 ms] Range (min … max): 530.6 ms … 542.0 ms 10 runs
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Aug 11, 2020
Coverty scan found this: > CID 298279 (RIOT-OS#1 of 1): Out-of-bounds read (OVERRUN) > 21. overrun-local: Overrunning array of 16 bytes at byte offset 64 by dereferencing pointer The original intention was probably to advance the destination pointer by 4 bytes, not 4 * the destination type size.
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Aug 11, 2020
Coverty scan found this: > CID 298295 (RIOT-OS#1 of 1): Operands don't affect result (CONSTANT_EXPRESSION_RESULT) result_independent_of_operands: > (ipv6_hdr_get_fl(ipv6_hdr) & 255) >> 8 is 0 regardless of the values of its operands. Looking at the code, this appears to be a copy & paste error from the previous line.
schulztr
pushed a commit
to schulztr/RIOT
that referenced
this pull request
Jul 7, 2021
Add endpoint type to wot thing description resource
riot-ci
pushed a commit
to riot-ci/RIOT
that referenced
this pull request
Jan 28, 2022
The ENTROPY test always fails on this board main(): This is RIOT! (Version: buildtest) mbedtls test SHA-224 test RIOT-OS#1: passed SHA-224 test RIOT-OS#2: passed SHA-224 test RIOT-OS#3: passed SHA-256 test RIOT-OS#1: passed SHA-256 test RIOT-OS#2: passed SHA-256 test RIOT-OS#3: passed ENTROPY test: failed
CW-75
pushed a commit
to CW-75/RIOT
that referenced
this pull request
Jul 1, 2022
initial structure of the repository
chrysn
referenced
this pull request
in chrysn-pull-requests/RIOT
Sep 16, 2022
Provide an application for openwsn
chrysn
referenced
this pull request
in chrysn-pull-requests/RIOT
Sep 23, 2022
The test is adjusted slightly: It is assumed that the RD is reachable on the all-nodes address (which by default the aiocoap-rd is); this removes the need for any address configuration.
bors bot
added a commit
that referenced
this pull request
Feb 15, 2023
19270: drivers/at24cxxx: implement _mtd_at24cxxx_read_page r=benpicco a=HendrikVE
### Contribution description
The function `read_page` was missing which lead to (from a user perspective) undefined behavior on the MTD layer.
### Testing procedure
Any application using MTD in conjunction with a board with an at24cxxx.
19271: core/xfa: disable asan on llvm r=benpicco a=Teufelchen1
### Contribution description
Hi! 🦎
When using llvm and address sanitation, the XFA trip the sanitizer.
This PR attempts to fix this by adding the `no_sanitize` attribute to the XFA macros. Sadly, this attribute is not known by gnu, a guard is hence needed. I'm open for alternatives as I dislike this solution but it is the best I could come up with.
### Testing procedure
Before this patch:
Go to `examples/gnrc_minimal` and run `TOOLCHAIN=llvm make all-asan` and then `make term`.
You should see an error similar to this:
```
==3374719==ERROR: AddressSanitizer: global-buffer-overflow on address 0x080774e0 at pc 0x0804af5e bp 0x0808eb88 sp 0x0808eb78
READ of size 4 at 0x080774e0 thread T0
#0 0x804af5d in _auto_init_module /RIOT/sys/auto_init/auto_init.c:40
#1 0x804af5d in auto_init /RIOT/sys/auto_init/auto_init.c:339
#2 0x804b375 in main_trampoline /RIOT/core/lib/init.c:56
#3 0xf76bc7b8 in makecontext (/lib32/libc.so.6+0x4a7b8)
...
```
After applying this PR, the example can be build and run with llvm or gcc, with or without asan.
Co-authored-by: Hendrik van Essen <hendrik.vanessen@ml-pa.com>
Co-authored-by: Teufelchen1 <bennet.blischke@haw-hamburg.de>
bors bot
added a commit
that referenced
this pull request
Feb 21, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references 19292: sys/phydat: Fix unit confusion r=benpicco a=maribu ### Contribution description Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol). To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart. ### Testing procedure Green CI ### Issues/PRs references None 19294: sys/shell: don't include suit command by default r=benpicco a=benpicco 19295: gcoap: Finish the gcoap_get_resource_list_tl -> gcoap_get_resource_list renaming r=benpicco a=chrysn ### Contribution description In #16688, an argument was added to the `gcoap_get_resource_list` function by creating a new function `gcoap_get_resource_list_tl` with a deprecation and roll-over plan. This plan has not been acted on so far. This PR shortens the original plan by just adding the argument to `gcoap_get_resource_list` and removing `gcoap_get_resource_list_tl` in a single go. The rationale for this deviation is that while it's a public API, its only two practical consumers are the (built-in) well-known/core implementation, and the (built-in) CoRE Resource Directory (cord) endpoint. Moreover, a further change to this API (switching over to `coap_block_slicer_t`) is expected to happen within this release cycle, which would take something like 4 total releases to get through otherwise, which is unrealistic for an API that there are no known external users of. A second commit clean up ToDo items (in the changed function's documentation) that referred to a IETF draft that has long been abandoned by the CoRE WG. ### Testing procedure Plain inspection and CI passing should suffice. ### AOB There is a second analogous pair left over from #16688, `gcoap_req_send` / `gcoap_req_send_tl`. As that *is* expected to be used widely, I prefer not to mix these two concerns, and get the present one through without unnecessary hold-up. Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de> Co-authored-by: Benjamin Valentin <benjamin.valentin@bht-berlin.de> Co-authored-by: chrysn <chrysn@fsfe.org>
bors bot
added a commit
that referenced
this pull request
Feb 21, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references 19292: sys/phydat: Fix unit confusion r=benpicco a=maribu ### Contribution description Previously, `UNIT_G` was used for g-force with the correct symbol `g`, `UNIT_GR` for gram (as in kilogram) with the incorrect symbol `G` (which would be correct for Gauss), and `UNIT_GS` for Gauss with symbol `Gs` (which is an alternative correct symbol). To avoid confusion between G-Force, Gauss, and Gram the units have been renamed to `UNIT_G_FORCE`, `UNIT_GRAM`, and `UNIT_GAUSS`. In addition, gram now uses the correct symbol `g`; which sadly is the same as for g-force. But usually there is enough context to tell them apart. ### Testing procedure Green CI ### Issues/PRs references None Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
bors bot
added a commit
that referenced
this pull request
Feb 22, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
bors bot
added a commit
that referenced
this pull request
Feb 22, 2023
18392: drivers/servo: reimplement with high level interface r=benpicco a=maribu ### Contribution description The previous servo driver didn't provide any benefit over using PWM directly, as users controlled the servo in terms of PWM duty cycles. This changes the interface to provide a high level interface that abstracts the gory PWM details. In addition, a SAUL layer and auto-initialization is provided. ### Testing procedure The test application provides access to the servo driver via the `saul` shell command. ``` > saul 2022-08-02 22:12:31,826 # saul 2022-08-02 22:12:31,827 # ID Class Name 2022-08-02 22:12:31,830 # #0 ACT_SWITCH LD1(green) 2022-08-02 22:12:31,832 # #1 ACT_SWITCH LD2(blue) 2022-08-02 22:12:31,834 # #2 ACT_SWITCH LD3(red) 2022-08-02 22:12:31,837 # #3 SENSE_BTN B1(User button) 2022-08-02 22:12:31,838 # #4 ACT_SERVO servo > saul write 4 0 2022-08-02 22:12:41,443 # saul write 4 0 2022-08-02 22:12:41,445 # Writing to device #4 - servo 2022-08-02 22:12:41,447 # Data: 0 2022-08-02 22:12:41,450 # [servo] setting 0 to 2949 (0 / 255) 2022-08-02 22:12:41,453 # data successfully written to device #4 > saul write 4 256 2022-08-02 22:12:45,343 # saul write 4 256 2022-08-02 22:12:45,346 # Writing to device #4 - servo 2022-08-02 22:12:45,347 # Data: 256 2022-08-02 22:12:45,351 # [servo] setting 0 to 6865 (255 / 255) 2022-08-02 22:12:45,354 # data successfully written to device #4 ``` Each write resulted in the MG90S servo that I connected to move to the corresponding position. ### Issues/PRs references Co-authored-by: Marian Buschsieweke <marian.buschsieweke@ovgu.de>
hugueslarrive
added a commit
to hugueslarrive/RIOT
that referenced
this pull request
Jun 17, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add functions to convert IP addresses to text and text to binary IP addresses.
(From Apache Portable Runtime)
also include stdint.h in net_help.h for uint16_t, etc.