Okay, I guess we 'll just disable the __wur's by default then -- as introducing
an unnecessary hard-to-avoid noise. I recon many other people do the same.
Thanks nevertheless. It's still a useful feature, just not flexible enough to
use it for *everyday* compilation.
Denis
On Fri, May 28, 2010 at 11:32:46AM -0700, Ian Lance Taylor wrote:
> Please read http://gcc.gnu.org/PR25509 .
>
> As the compiler documentation states, warn_unused_result was intended
> for cases where failing to check the return value is always a security
> risk or a bug. The documentation cites
On 29/05/2010 11:55, Richard Guenther wrote:
> On Sat, May 29, 2010 at 3:16 AM, Dave Korn wrote:
>> What it really is is, I don't see the consistency in disregarding an
>> explicit cast to void, yet permitting a workaround such as an inlined no-op
>> function that casts the parameter to void. I
On Sat, May 29, 2010 at 3:16 AM, Dave Korn wrote:
> On 29/05/2010 01:14, Ian Lance Taylor wrote:
>> Dave Korn
>>> there is *no* circumstances
>>> under which ignoring the return from *any* function is *always* a bug.
>
>> For practical purposes, it is always a bug to ignore the return value
>>
On Sat, May 29, 2010 at 3:13 AM, Dave Korn wrote:
> On 29/05/2010 01:17, Ian Lance Taylor wrote:
>> Dave Korn writes:
>>
>>> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>>>
The warn_unused_result extension was implemented specifically to catch
security problems. Permitting developers
Dave Korn writes:
> On 29/05/2010 01:14, Ian Lance Taylor wrote:
>> Dave Korn
>>> there is *no* circumstances
>>> under which ignoring the return from *any* function is *always* a bug.
>
>> For practical purposes, it is always a bug to ignore the return value
>> of realloc (I disregard the unu
On 29/05/2010 01:14, Ian Lance Taylor wrote:
> Dave Korn > there is *no* circumstances
>> under which ignoring the return from *any* function is *always* a bug.
> For practical purposes, it is always a bug to ignore the return value
> of realloc (I disregard the unusual case of passing 0 as the
On 29/05/2010 01:17, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>>
>>> The warn_unused_result extension was implemented specifically to catch
>>> security problems. Permitting developers to just add a cast to void
>>> would make it a very weak f
Dave Korn writes:
> On 28/05/2010 22:25, Ian Lance Taylor wrote:
>
>> The warn_unused_result extension was implemented specifically to catch
>> security problems. Permitting developers to just add a cast to void
>> would make it a very weak facility.
>
> But it's a weak and fundamentally flawe
Dave Korn writes:
> On 28/05/2010 19:32, Ian Lance Taylor wrote:
>
>> As the compiler documentation states, warn_unused_result was intended
>> for cases where failing to check the return value is always a security
>^^
> Note: "always
On 28/05/2010 22:25, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" > The reasonable (or, "great enough") solution would be to just trust
>> explicit developer's void-casting.
>>
>> Also, 'warn_unused_result' should be enough; there is no need to add
>> more levels to this simple par
On 28/05/2010 19:32, Ian Lance Taylor wrote:
> As the compiler documentation states, warn_unused_result was intended
> for cases where failing to check the return value is always a security
^^
Note: "always".
> risk or a bug.
OK,
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> The problem with the suggested scenario with one trusted developer
> that uses this option is that other developers won't see these
> warnings at all. However, IMO we can have our cake and eat it too --
> and, leave most of the involved parties genera
Ian Lance Taylor wrote:
> [...] developers can not always be trusted. Instead, we assume that there at
> least one trusted developer who can add warn_unused_result when
> appropriate. Then the compiler arranges matters such that other developers
> can not easily avoid the warning. Thus securi
On Fri, May 28, 2010 at 11:25 PM, Ian Lance Taylor wrote:
> "Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
>
>> Ian Lance Taylor wrote:
>>
>>> We should handle must_use_result and warn_unused_result similarly, except
>>> that adding a cast to (void) disables the warn_unused_result warning.
>>> Pe
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> Ian Lance Taylor wrote:
>
>> We should handle must_use_result and warn_unused_result similarly, except
>> that adding a cast to (void) disables the warn_unused_result warning.
>> Perhaps there should also be other simple ways to disable the
>> war
Ian Lance Taylor wrote:
> We should handle must_use_result and warn_unused_result similarly, except
> that adding a cast to (void) disables the warn_unused_result warning.
> Perhaps there should also be other simple ways to disable the
> warn_unused_result warning.
>
> This is not a great solu
"Vakatov, Denis (NIH/NLM/NCBI) [E]" writes:
> Can this design please be changed (or, dare I say without being
> considered impolite, improved) to better accommodate for the cases
> where there is indeed no reason for checking the return value?
>
> Making the developers jump through more complicat
Behalf Of
Paolo Bonzini
Sent: Friday, May 28, 2010 1:10 PM
To: Vakatov, Denis (NIH/NLM/NCBI) [E]
Cc: Lavrentiev, Anton (NIH/NLM/NCBI) [C]; gcc@gcc.gnu.org
Subject: Re: Request for suppressing "warn_unused_result" warnings
On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]
wr
On Fri, May 28, 2010 at 18:12, Vakatov, Denis (NIH/NLM/NCBI) [E]
wrote:
> Hi Paolo,
>
> Can this design please be changed
By saying "by design" I was implying that it won't.
FWIW I agree with you, but I'm also very undecided whether it is not
glibc that was too greedy in applying __wur (which al
olo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Friday, May 28, 2010 9:12 AM
To: Lavrentiev, Anton (NIH/NLM/NCBI) [C]
Cc: gcc@gcc.gnu.org; Vakatov, Denis (NIH/NLM/NCBI) [E]
Subject: Re: Request for suppressing "warn_unused_result" warnings
On 05/28/2010 06:36 AM, Lavrentiev, Ant
On 05/28/2010 06:36 AM, Lavrentiev, Anton (NIH/NLM/NCBI) [C] wrote:
Dear GCC developers,
Would you please consider suppressing (relatively new) warnings like
this one:
ignoring return value of 'int chdir(const char*)', declared with
attribute warn_unused_result
in cases when the source code ex
22 matches
Mail list logo
