URL: <https://savannah.nongnu.org/bugs/?59884>
Summary: _delay_ms() documentation wrongly states delay can end up as 0 ms in certain situation Project: AVR C Runtime Library Submitted by: None Submitted on: Fri 15 Jan 2021 11:33:02 PM UTC Category: None Severity: 3 - Normal Priority: 5 - Normal Item Group: Documentation Status: None Assigned to: None Percent Complete: 0% Originator Email: britton.ke...@gmail.com Open/Closed: Open Discussion Lock: Any Release: 2.0.0 Fixed Release: None _______________________________________________________ Details: On a 16 MHz Arduino Mega 256, this code: __builtin_avr_delay_cycles (100.0); // Compiles, so we apparently have it debug_led_on (); _delay_ms (290000.0); debug_led_off (); assert (0); leaves the debug led on for about 269 s. Same for larger arguments to _delay_ms (e.g. 350000.0). This is different from what this documentation implies will happen: If the avr-gcc toolchain has __builtin_avr_delay_cycles() support, maximal possible delay is 4294967.295 ms/ F_CPU in MHz. For values greater than the maximal possible delay, overflows results in no delay i.e., 0ms. A discussion on the avr-libc mailing list made clear that the problem is that the documented behavior depends on undefined behavior as described here: https://lists.nongnu.org/archive/html/avr-libc-dev/2020-01/msg00009.html Rather than document the particular behavior I would change the documentation for _delay_ms() (at least, not sure if _delay_us() or others might also need attention) to state the behavior in that circumstance is undefined ("propagate" the undefined). _______________________________________________________ Reply to this item at: <https://savannah.nongnu.org/bugs/?59884> _______________________________________________ Message sent via Savannah https://savannah.nongnu.org/