[Linuxptp-devel] [PATCH] phc2sys: Fix lower bound value of update_rate

[Ken ICHIKAWA]

Following command produces unexpected update rate.
# phc2sys -s eth0 -q -m -O0 -R1.0842021724855044e-19
This is caused by wrong validation of phc_interval related to
significant digits of double precision and phc_interval_tp.tv_sec
overflow.

To avoid these unwanted trouble, this patch limits lower bound of
phc_rate to 1e-9.
There is no profound meaning in the lower bound value. I just think
it's enough to actual use and it doesn't cause phc_interval_tp.tv_sec
overflow in not only 64bit environment but also 32bit environment.
Thereby, messy validation of phc_interval is no longer needed.

Signed-off-by: Ken ICHIKAWA <***@jp.fujitsu.com>
---
phc2sys.c | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)

diff --git a/phc2sys.c b/phc2sys.c
index 157d0e8..2012fbd 100644
--- a/phc2sys.c
+++ b/phc2sys.c
@@ -634,17 +634,9 @@ int main(int argc, char *argv[])
return -1;
break;
case 'R':
- if (get_arg_val_d(c, optarg, &phc_rate, 0.0, DBL_MAX))
+ if (get_arg_val_d(c, optarg, &phc_rate, 1e-9, DBL_MAX))
return -1;
phc_interval = 1.0 / phc_rate;
- /* phc_interval will be assigned to a time_t variable. */
- /* check if that occurs overflow. */
- if ((sizeof(time_t) == 8 && phc_interval > INT64_MAX) ||
- (sizeof(time_t) == 4 && phc_interval > INT32_MAX)) {
- fprintf(stderr,
- "-R: %s is too small\n", optarg);
- return -1;
- }
break;
case 'N':
if (get_arg_val_i(c, optarg, &phc_readings, 1, INT_MAX))

[Miroslav Lichvar]

Post by Ken ICHIKAWA
To avoid these unwanted trouble, this patch limits lower bound of
phc_rate to 1e-9.
There is no profound meaning in the lower bound value. I just think
it's enough to actual use and it doesn't cause phc_interval_tp.tv_sec
overflow in not only 64bit environment but also 32bit environment.
Thereby, messy validation of phc_interval is no longer needed.

Looks good to me. Thanks.

[Richard Cochran]

Post by Ken ICHIKAWA
Following command produces unexpected update rate.
# phc2sys -s eth0 -q -m -O0 -R1.0842021724855044e-19
This is caused by wrong validation of phc_interval related to
significant digits of double precision and phc_interval_tp.tv_sec
overflow.
To avoid these unwanted trouble, this patch limits lower bound of
phc_rate to 1e-9.
There is no profound meaning in the lower bound value. I just think
it's enough to actual use and it doesn't cause phc_interval_tp.tv_sec
overflow in not only 64bit environment but also 32bit environment.
Thereby, messy validation of phc_interval is no longer needed.

Applied.

Thanks,
Richard