On Sun, Nov 28, 2021 at 3:20 PM Paul Smith <psm...@gnu.org> wrote: > > On Sun, 2021-11-28 at 14:57 +0100, Jouke Witteveen wrote: > > > Since the two arguments are equal, it doesn't matter which of LHS > > > or RHS we return. > > > > They could differ for instance when one of them contains a '+'-sign. > > My reason for using LHS is that we already have a string for it. > > I don't think that it's necessary return the exact string. If the user > wanted a string match they can do that other ways. Returning the > "absolute value" (stripping leading +/-, leading 0's, etc.) seems more > useful to me.
I fully agree, but was not aware of the robustness of INTSTR_LENGTH. It felt a bit fragile when I spotted its definition in makeint.h. > > > However, now that I think about it I need to change the code more: we > > > need to be using "long long" here not just "long". While on Linux etc. > > > a "long" is 8 bytes, on Windows "long" is only 4 bytes. > > > > I was hoping this would not be necessary, and I cannot think of a > > typical use case where make is a good fit for dealing with large > > integers. The benefit of "long" is that strtol is more widely > > available than strtoll. > > I see what you mean, but I _really_ don't like the idea of GNU make > working differently on different platforms, even if such use cases are > rare. I can imagine a situation where, for example, someone wants to > compare the sizes of files and if one of the files is >4G then it will > work on Linux and fail on Windows. File sizes are an interesting application indeed. If you want me to change the patches to use strtoll, I would need some help since I am not sure how to set things up so that we get a fallback implementation on platforms where it is missing.
