Hi,
the problem you demonstrate exists in the code below, but it's a coding
bug. it's missing the signed cast to compare wrapping variables.
It is well known that to compare counters that can rollover/wrap, the
subtraction to check if the timer has elapsed *must* be using signed
arithmetic.
The usual case is hardware timers, which are most always considered
unsigned. This is not just a Nuttx problem.
https://stackoverflow.com/questions/3095623/how-to-deal-with-a-wrapping-counter-in-embedded-c
This cast is required, at least as an explicit acknowledge that the
wrapping behaviour has been taken into consideration. I add comments
every time I have to do this now. Of course I have been bitten by this
bug too, in a bare metal PIC18 project IIRC.
So, forcing counters to be signed just to avoid a well known embedded
development pitfall makes little sense to me.
The ability to use negative timestamps (even if probably not really
useful but you never know) is a much more valid reason.
I still do not advise changing the signedness of time_t, the reason is
to prevent unpredictability in projects *we are not even aware of*
But doing so on the 64-bit version of time_t is less critical because it
avoids the y2038 problem.
Anyway, changing the signedness of such an important variable should
have to be explicitly acknowledged by developers.
Maybe with a mechanism similar to debian updates that displays a text
with important warnings from updated packages. That could be triggered
by make.
Or maybe a kconfig option, something like that now must be checked
before code compiles again:
#ifndef CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE
#error "Signedness of 64-bit time_t has changed, you may need to fix
your code to take this change into account. Please do so, then select
option CONFIG_DEVELOPER_ACKNOWLEDGED_TIME_SIGNEDNESS_CHANGE in kconfig
(indicate where to find it) to acknowledge this fact."
#endif
We should make sure that every developer will be aware of it. Releases
notes are not enough.
Thank you everyone for discussing these issues.
Sebastien
On 11/5/24 19:50, Xiang Xiao wrote:
Here is a simple example demonstrate that why the signed/unsigned is very
important for time_t:
one function records a timestamp:
time_t t1 = time(NULL);
another function records a second timestamp:
time_t t2 = time(NULL);
and check which one is early by:
if (t2 - t1 < 0)
{
printf("t2 is early than t1\n");
}
But If time_t is an unsigned integer, the comparison can never become true:
https://devblogs.microsoft.com/oldnewthing/20140122-00/?p=2013
Since most POSIX OS map time_t to a signed type, the above code(appears in
many code bases) works very well until they meet NuttX.
Actually, we hit the problem before which takes our engineer to debug this
problem and find the root cause by several days.
That's why I prefer to follow other OS practice if the spec is ambiguous
like time_t.
If 32bit signed time_t is unacceptable due to the 2038 problem, at least
64bit time_t should change to the signed integer.
Otherwise, you will take time to debug the above problem soon or later.
On Tue, Nov 5, 2024 at 6:05 PM Simon Filgis <si...@ingenieurbuero-filgis.de>
wrote:
Thanks. So there are use cases for negative numbers of time. Interesting.
--
Hard- and Softwaredevelopment Consultant
Geschäftsführung: Simon Filgis
USt-IdNr.: DE305343278
ISO9001:2015 <https://activities.ingenieurbuero-filgis.de/certifications>
On Tue, Nov 5, 2024 at 11:03 AM <michal.lyszc...@bofc.pl> wrote:
On 2024-11-05 08:13:19, Simon Filgis wrote:
Seems like a dump question, but why time needs to be signed?
It doesn't. But you may want to go backwards to show date before 1970.
This is
usually implemented by using negative time.
--
.-----------------.-------------------.----------------------.-----------------.
| Michal Lyszczek | Embedded C, Linux | Company Address | .-.
opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 | oo|
supporter |
| https://bofc.pl `----.--------------: Brzezinka Sredzka PL | /`'\
& |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP: 813 349 58 78 |(\_;/)
programer |
`----------------------^--------------^----------------------^-----------------'
