bugAVR C Runtime Library - Bugs: bug #59884, _delay_ms() documentation wrongly...


You are not allowed to post comments on this tracker with your current authentication level.

bug #59884: _delay_ms() documentation wrongly states delay can end up as 0 ms in certain situation

Submitter:  None
Submitted:  Fri 15 Jan 2021 11:33:02 PM UTC
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Documentation
Status:  None Percent Complete:  0%
Assigned to:  None Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  2.0.0
Fixed Release:  None

Fri 15 Jan 2021 11:33:02 PM UTC, original submission:  

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:


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).



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by None (Submitted the item)



    No changes have been made to this item

    Back to the top

    Powered by Savane 3.12