[PATCH] wdog: don't add the value of delay when check range

50 views
Skip to first unread message

Yuan Zhang

unread,
Jul 2, 2019, 9:33:42 PM7/2/19
to NuttX
Hi Greg:

Please consider the attached patch.

Thanks
Yuan
0001-sched-wdog-don-t-add-delay-when-check-the-range.patch

Alan Carvalho de Assis

unread,
Jul 3, 2019, 6:12:58 AM7/3/19
to nu...@googlegroups.com
Hi Yuan,

Is the compiler generating different code for both cases?

I think (++delay) = (delay + 1)

Is it not?

BR,

Alan
--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/7b8f4646-8a65-4528-8b98-d23587957f16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

spudaneco

unread,
Jul 3, 2019, 8:14:06 AM7/3/19
to nu...@googlegroups.com
The difference is that (++delay) modifies the value of 'delay', (delay + 1) does not.



Sent from Samsung tablet.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/nuttx/CAG4Y6eRSerxBrG4Ebem2WDQMKsxdXbWGSwKuhVZn0zDAJteY-A%40mail.gmail.com.

Alan Carvalho de Assis

unread,
Jul 3, 2019, 9:21:39 AM7/3/19
to nu...@googlegroups.com
Hmm, true!

Thank you very much Greg!

Sorry to raise this question Yuan!

BR,

Alan

--
You received this message because you are subscribed to the Google Groups "NuttX" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuttx+unsubscribe@googlegroups.com.

patacongo

unread,
Jul 3, 2019, 9:26:49 AM7/3/19
to nu...@googlegroups.com

Please consider the attached patch.


It seems to me that the code is correct as it is.  But perhaps I am missing something.  The code is simply implementing '++delay' with extreme caution.  This is the code as it is:

  /* Calculate delay+1, forcing the delay into a range that we can handle */

  if (delay <= 0)
    {
      delay = 1;
    }
  else if (++delay <= 0)
    {
      delay--;
    }


That is a little awkward, but I think correct.  The first if part just tests if a bad delay was passed:  The minimum delay is 0.  The else condition is more interesting:  It increments delay (as we want to do) and checks for signed overflow.  delay is signed type int32_t.  This condition could happen only if delay == 0x7fffffff.  In that case ++delay is 0x80000000.  That is negative and is caught by the else if.  The delay-- correctly restores the delay to 0x7fffffff.  That is all correct.

The following would have been clearer but is really the same thing:

  else if (delay < INT32_MAX)
    {
      delay++;
    }

The suggested change is wrong, however, because it fails to increment delay in all cases where delay is in a valid range:

  else if ((delay + 1) <= 0)
    {
      delay++;
    }

Perhaps the issue is that you do not understand why the delay is incremented in the first place?  That is explained here: http://www.nuttx.org/doku.php?id=wiki:nxinternal:time-delays

Yuan Zhang

unread,
Jul 3, 2019, 11:27:56 PM7/3/19
to NuttX
Hi, Greg:

I found the explain of the "++delay",  thanks for your help ^^

"usleep() has no knowledge of the the phase of the system timer when it is started: The next timer interrupt may occur immediately or may be delayed for almost a full cycle. In order to meet the contract of the first requirement, the requested time is also always incremented by one."


在 2019年7月3日星期三 UTC+8下午9:26:49,patacongo写道:
Reply all
Reply to author
Forward
0 new messages