Avoidable warning in getdtable.c?

[Reuben Thomas]

I get this warning:

getdtablesize.c:115:12: warning: comparison of 0 <= unsigned
expression is always true [-Wtautological-compare]
&& 0 <= lim.rlim_cur && lim.rlim_cur <= INT_MAX
~ ^ ~~~~~~~~~~~~

According to this Open Group reference page
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html
:

rlim_t: Unsigned integer type used for limit values.

So could the test 0 <= lim.rlim_cur be removed? I looked at the
communications around the introduction of that line, and I can't see
any suggestion that rlim_t is signed in any case.

[Paul Eggert]

Post by Reuben Thomas
According to this Open Group reference page
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/resource.h.html
rlim_t: Unsigned integer type used for limit values.

rlim_t is signed on some non-POSIX platforms so the comparison is needed
there. Sorry, don't recall which platforms offhand, but a quick Google
search suggests that older  HP-UX is one such (this version was before
the requirement in question was added to POSIX). See page 18 of:

https://community.hpe.com/hpeb/attachments/hpeb/itrc-151/23778/1/241970.pdf

How about compiling with -Wno-tautological-compare instead, at least for
code derived from Gnulib? In my experience, -Wtautological-compare is
more trouble than it's worth, for Gnulib code.

[Reuben Thomas]

Post by Paul Eggert

Post by Reuben Thomas
According to this Open Group reference page
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/
resource.h.html
rlim_t: Unsigned integer type used for limit values.

rlim_t is signed on some non-POSIX platforms so the comparison is needed
there. Sorry, don't recall which platforms offhand, but a quick Google
search suggests that older HP-UX is one such (this version was before the
https://community.hpe.com/hpeb/attachments/hpeb/itrc-151/
23778/1/241970.pdf
How about compiling with -Wno-tautological-compare instead, at least for
code derived from Gnulib? In my experience, -Wtautological-compare is more
trouble than it's worth, for Gnulib code.

Would it be acceptable to add a pragma to turn this warning off at that
point? (And explain why, against immediate appearances, it's needed?)

[Paul Eggert]

Post by Reuben Thomas
Would it be acceptable to add a pragma

I'm not a fan of cluttering the code just to pacify a false alarm. In my
experience, for Gnulib -Wtautological-compare is more trouble than it's
worth.

See coreutils for an example of using different -W options for Gnulib
code than for the app itself; that should address the issue without
Gnulib clutter.

[Reuben Thomas]

Post by Paul Eggert

Post by Reuben Thomas
Would it be acceptable to add a pragma

I'm not a fan of cluttering the code just to pacify a false alarm. In my
experience, for Gnulib -Wtautological-compare is more trouble than it's
worth.
See coreutils for an example of using different -W options for Gnulib code
than for the app itself; that should address the issue without Gnulib
clutter.

​I agree as a general principle. However, this case seems to me one where
we should not put that burden on the gnulib user, since it's only on old
systems (presumably a tiny number as a proportion of all those in use) that
rlim_t can even be signed.

I see you seem to have put a similar pragma for the same warning in
anytostr.c.

Thanks for the pointer to how to compile gnulib with different flags. If
you're really against adding a pragma in this case, then how about changing
manywarnings to use suitable flags for gnulib code? (Though I can see
potential problems with that too
)

[Paul Eggert]

Post by Reuben Thomas
I see you seem to have put a similar pragma for the same warning in
anytostr.c.

Yes, and that's the sort of thing I'd rather not do elsewhere. That mess
started with the thread here:

https://lists.gnu.org/r/bug-gnulib/2010-10/msg00428.html

Post by Reuben Thomas
how about changing manywarnings to use suitable flags for gnulib code?
(Though I can see potential problems with that too…

Something that coreutils etc. could use, instead of the by-hand stuff
they do nowadays? That would be nice, I think. Not quite sure how to do
it, though.

[Reuben Thomas]

Post by Paul Eggert

Post by Reuben Thomas
I see you seem to have put a similar pragma for the same warning in
anytostr.c.

Yes, and that's the sort of thing I'd rather not do elsewhere. That mess
https://lists.gnu.org/r/bug-gnulib/2010-10/msg00428.html
how about changing manywarnings to use suitable flags for gnulib code?

Post by Reuben Thomas
(Though I can see potential problems with that too


Something that coreutils etc. could use, instead of the by-hand stuff they
do nowadays?

​Exactly.​