On Mon, Apr 24, 2017 at 12:01:10AM +0200, Marc Espie wrote:
> On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote:
> > > The main difference between you and Theo is that Theo knows what he's
> > > talking about.
>
> > If you want to contribute anything, point out how casting a
On Sun, Apr 23, 2017 at 10:16:38PM +0200, Timo Buhrmester wrote:
> > The main difference between you and Theo is that Theo knows what he's
> > talking about.
> If you want to contribute anything, point out how casting a non-negative
> into to size_t for comparison against another size_t could
> The main difference between you and Theo is that Theo knows what he's
> talking about.
If you want to contribute anything, point out how casting a non-negative
into to size_t for comparison against another size_t could lead to
"real errors later whenever the code evolves in any way". Nice
On Sun, Apr 23, 2017 at 05:12:16PM +0200, Timo Buhrmester wrote:
> Except if the world changes... In a way that's still POSIX-compliant.
> But why would anyone want to protect themselves from that, right?
You're full of it.
You're advocating for an unnecessary cast that can actually hide real
> Timo if you feel the need to be an asshole, please be that asshole
> elsewhere.
Pot, meet Kettle.
> > Otherwise, you can start enabling that option and sending a diff which
> > fixes ALL THE WARNINGS IT GIVES IN THE ENTIRE TREE.
> I think I'll pass on that. I wasn't aware of how many warnings
> a build seems to cause. This must be why NetBSD has -Werror in their
> CFLAGS.
Timo if you feel
> > Otherwise people might fall into a habit
> > of ignoring warnings [that may point to actual problems].
>
> People might fall into the habit of ignoring a warning from an
> extension to C provided by a single compiler?
>
> I doubt it.
Doubt away. I find it more than obvious that telling
> > The code is already safe.
> It is reasonably safe(*) and triggers a warning. That's a good reason
> to silence the warning.
No.
The warning is a false extension to C.
In C, int and sizeof can be compared safely in this circumstance.
> Otherwise people might fall into a habit
> of ignoring
> The code is already safe.
It is reasonably safe(*) and triggers a warning. That's a good reason
to silence the warning. Otherwise people might fall into a habit
of ignoring warnings [that may point to actual problems]. I just
pointed out a safe way to silence the warning, without it
> > Well, when the world changes, that cast is suddenly wrong.
>
> I.e. instead of
> > if (ret == -1 || ret >= sizeof(buffer))
> one could use
> > if (ret < 0 || (size_t)ret >= sizeof(buffer))
>
> And be safe from a changing world.
The code is already safe.
> Well, when the world changes, that cast is suddenly wrong.
I.e. instead of
> if (ret == -1 || ret >= sizeof(buffer))
one could use
> if (ret < 0 || (size_t)ret >= sizeof(buffer))
And be safe from a changing world.
-Wextra is stupid.
It is trying to persuade patterns that ignore the rules of standard C.
In particular for this situation:
Never add extra costs. Adding casts everywhere is HIGHLY ERROR PRONE.
Unneccesary casts were among the hardest parts of the jump from 32-bit
to 64-bit, since a cast means
The example proper usage of snprintf(3) (under Caveats) evokes a warning
when compiled with -Wextra. I presume casting ret to unsigned int would
be safe, but I'll defer to those who know the nuances.
#include
int
foo(char* string) {
char buffer[128];
int ret = snprintf(buffer,
13 matches
Mail list logo
