This is indeed a problem. Although there is no essential difference between useing `-0x1` or `0xffffffffffffffff`, but `-1` is usually used to represent infinity for developers.
Now there are two different types on the linux platform, this seems unnecessary. 在2023年4月4日星期二 UTC+8 03:40:33<Bryan C. Mills> 写道： > POSIX specifies that RLIM_INFINITY in C has type rlim_t and that type > rlim_t is an “unsigned integral type”, so the `uint64` value seems > appropriate. > ( > https://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html > ) > > And it appears that syscall.RLIM_INFINITY has the correct (unsigned) value > on most non-Linux platforms already. I wonder why the other Linux > architectures use a signed value for an unsigned type? 🤔 > > On Friday, March 24, 2023 at 1:14:45 PM UTC-4 莫胜文 wrote: > >> RLIM_INFINITY is a constant generated by mkerrors.sh. Its value is >> 0xffffffffffffffff (uint64) in loong64 but -0x1(int64) in other >> architectures. >> >> I'm not sure if it is necessary but it will cause some troubles for >> applications such as prometheus >> <https://github.com/prometheus/prometheus/blob/main/util/runtime/limits_default.go#L27> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0b204e8c-1d04-46b4-b3c8-e19d106c3438n%40googlegroups.com.
