avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #59884] _delay_ms() documentation wrongly states delay can end up a


From: anonymous
Subject: [bug #59884] _delay_ms() documentation wrongly states delay can end up as 0 ms in certain situation
Date: Fri, 15 Jan 2021 18:33:04 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

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.kerin@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/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]