The value is stored in unsigned long long, so ULLONG_MAX is the proper
upper limit to use.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
Even though this is a build-breaker (for 32bit systems
memtune-unlimited fails to parse), I'm not pushing it as one because
it feels odd that such
On 10/30/2014 09:49 AM, Martin Kletzander wrote:
The value is stored in unsigned long long, so ULLONG_MAX is the proper
upper limit to use.
No, it's not.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
Even though this is a build-breaker (for 32bit systems
memtune-unlimited
On 10/30/2014 09:55 AM, Eric Blake wrote:
On 10/30/2014 09:49 AM, Martin Kletzander wrote:
The value is stored in unsigned long long, so ULLONG_MAX is the proper
upper limit to use.
No, it's not.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
Even though this is a
On 10/30/2014 10:09 AM, Eric Blake wrote:
On 10/30/2014 09:55 AM, Eric Blake wrote:
On 10/30/2014 09:49 AM, Martin Kletzander wrote:
The value is stored in unsigned long long, so ULLONG_MAX is the proper
upper limit to use.
No, it's not.
Signed-off-by: Martin Kletzander
On 10/30/2014 10:23 AM, Eric Blake wrote:
Or maybe the problem is that at some point we used unsigned long, and
later moved to unsigned long long, but never updated the comment? I'm
trying to investigate the history of this code...
Looking a bit deeper, commit 4888f0fb5 was where we changed
On 10/30/2014 10:51 AM, Eric Blake wrote:
On 10/30/2014 10:23 AM, Eric Blake wrote:
Or maybe the problem is that at some point we used unsigned long, and
later moved to unsigned long long, but never updated the comment? I'm
trying to investigate the history of this code...
Or maybe the
