Boost C++ Libraries: Ticket #4533: timespec translation fails for times before 1970

Thu, 12 Aug 2010 13:36:21 GMT

by the way, the system time was 1919 and so timeout.tv_sec as well as timeout.tv_nsec became negative. tv_sec are accepted negative but not tv_nsec.

anonymous — Sun, 29 Aug 2010 00:34:43 GMT

1000000000L is a magic number. I suggest that it be replaced using a const long.

cc set

viboes — Wed, 17 Nov 2010 20:35:10 GMT

cc viboes added

I would say that in this case an exception must be thrown.

owner, status, milestone changed; cc deleted

viboes — Sun, 04 Dec 2011 00:14:49 GMT

cc viboes removed
owner changed from Anthony Williams to viboes
status new → assigned
milestone Boost 1.44.0 → To Be Determined

viboes — Wed, 07 Dec 2011 21:47:51 GMT

I would like to understand how the seconds are positive and the nanoseconds are negative. Could you post an example?

phu@… — Thu, 08 Dec 2011 07:28:16 GMT

Hi viboes

Well, 16 month is quite a while ago... We do use boost intensively but have fixed already 3 bugs in different parts of boost, all sent to this bug tracker tool but with little or no response. So we keep on fixing every new release...

We used boost for embedded linux on a hardware with broken realtime clock. So the system time was often randomly startet and in this case it was 1919.

The timeout resulted from a calculation of some time value minus another time value. let's say, we scheduled a timer to a specific absolute time. The scheduler thread inspects this time value, compares it with the current posix time and calculates how long it needs to sleep until the timer will be signaled. If the scheduler is busy, it can happen that the sleep timeout, which is basically the subtraction of two times, becomes negative. But it only happend with the low year numbers of 1919. At least, that is what I think caused the timeout to become negative. But I can't tell you for sure. After 16 Month.

I understand that you would like to fix the cause of the negative timeout but as long as the timeout type allows negative values, you can not avoid a call with negative values in general anyway.

What I can tell you for sure is, that the bugfix, which I suggested works well for us. Whether or not it is fixing the real cause of the bug.

cheers phu

viboes — Fri, 09 Dec 2011 11:13:26 GMT

Replying to phu@…:

Hi viboes

Well, 16 month is quite a while ago...

It is always better late than never ;-)

We do use boost intensively but have fixed already 3 bugs in different parts of boost, all sent to this bug tracker tool but with little or no response. So we keep on fixing every new release...

I'm trying to change this.

We used boost for embedded linux on a hardware with broken realtime clock. So the system time was often randomly startet and in this case it was 1919.

The timeout resulted from a calculation of some time value minus another time value. let's say, we scheduled a timer to a specific absolute time. The scheduler thread inspects this time value, compares it with the current posix time and calculates how long it needs to sleep until the timer will be signaled. If the scheduler is busy, it can happen that the sleep timeout, which is basically the subtraction of two times, becomes negative. But it only happend with the low year numbers of 1919. At least, that is what I think caused the timeout to become negative. But I can't tell you for sure. After 16 Month.

I understand that you would like to fix the cause of the negative timeout but as long as the timeout type allows negative values, you can not avoid a call with negative values in general anyway.

What I can tell you for sure is, that the bugfix, which I suggested works well for us. Whether or not it is fixing the real cause of the bug.

cheers phu

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Let me know what do you think of this resolution?

Best, Vicente

phu@… — Fri, 09 Dec 2011 13:03:44 GMT

Hi Vicente

Thanks for taking up the bug. Right you are, better late than never. I stripped the answer a bit to get to the point:

Replying to viboes:

Replying to phu@…:

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints ...

Well, we have a correct linux system time. Even if it shows the year 1919, I think it perfectly satisfy the interface constraints. Well, I might be a bit naive on that point.

... and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

We subtract two ptime values. I expect the value to be usable for further operations. I would not check every subtraction for its correct value (whether its components are positive or not), that is what I expect of the operation to do.

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Sorry, but I might be misunderstanding this point. If we end up with an assertion instead of a working program flow, I'm not exactly happy with the solution. Then I prefer you do nothing at all and we continue the way we did so far.

Let me know what do you think of this resolution?

Best, Vicente

Thanks for looking into it anyway :-) Cheers Philipp

viboes — Fri, 09 Dec 2011 17:44:45 GMT

Replying to phu@…:

Replying to viboes:

Replying to phu@…:

Thanks for the explanation. IIUC,and if you where using directly the underlying platform you will need to make sure that the time given satisfy the interface constraints ...

Well, we have a correct linux system time. Even if it shows the year 1919, I think it perfectly satisfy the interface constraints. Well, I might be a bit naive on that point.

... and when you did a difference you will ensure that the seconds and nanoseconds will be positive, isn't it?

We subtract two ptime values. I expect the value to be usable for further operations. I would not check every subtraction for its correct value (whether its components are positive or not), that is what I expect of the operation to do.

What do you use to make this difference? Boost.Date?

I think that you will do the same when using Boost.Chrono. The best I can do is to add an assertion so that the modification doesn't add code on release mode.

Sorry, but I might be misunderstanding this point. If we end up with an assertion instead of a working program flow, I'm not exactly happy with the solution. Then I prefer you do nothing at all and we continue the way we did so far.

The question is if the ptime given as parameter must be a valid one, that is, if it is a precondition. IMO, this is the spirit of a lot of standard functions, so that the implementation is not required to test the validity of the informations received in the parameters.

type changed; cc set

viboes — Sat, 10 Dec 2011 16:02:26 GMT

cc viboes added
type Bugs → Support Requests

Moved to support request until resolution clarified

status changed; resolution set

viboes — Sat, 31 Dec 2011 15:23:24 GMT

status assigned → closed
resolution → worksforme

Closed. Please answer the questions and reopen it if you consider necessary.