But what about systems that don't have uint64_t? I think bash uses unsigned long for nanoseconds. Maybe we should adopt that behavior?

given that rcl_wait uses an int64_t for it's timeout (negative values meaning wait forever) and that the docblocks examples use these macros to specify the timeout, it looks risky to me to cast this as a uint64_t. see ros2/rcl#86 (comment) for an analog discussion

But what about systems that don't have uint64_t?

I don't know of any systems which cannot represent uint64_t (either natively on the CPU or through emulation). I think it's an unreasonable constraint on the use of the 64-bit type. We've discussed this in the past internally as well as externally:

https://discourse.ros.org/t/of-clocks-and-simulation-betimes-and-otherwise/1587/7

I think bash uses unsigned long for nanoseconds. Maybe we should adopt that behavior?

Bash probably uses it in combination with a 32-bit seconds field too, but I don't know since you didn't link to what you're referring. I don't think it makes sense to use unsigned long for the nanoseconds representation of a time point (note only nanoseconds, not a nanoseconds + seconds style structure), but maybe you meant something else.

given that rcl_wait uses an int64_t for it's timeout (negative values meaning wait forever)

That's because it is a duration. In rcl we represent durations as signed 64-bit integers so you can safely do arithmetic on them. Time points, however, use unsigned integers because they are not often the result of arithmetic but rather a component of it, and because using an unsigned values give a much longer scope for the time point since the unix epoch. Basically it is a trade-off between representing more time points in the future versus representing time points before 1970. I made the decision for the former in rcl.

and that the docblocks examples use these macros to specify the timeout, it looks risky to me to cast this as a uint64_t

Indeed, not all representations of time that could be used with these macros must be unsigned or even integers. You could perfectly well do this:

double nanoseconds = RCUTILS_S_TO_NS(1.3);

You might need to consider the consequences of doing that (loss of floating point precision, etc) but it's totally valid.

closing in favor of commit: ros2/rclcpp@89b6b6f