Paolo Bonzini writes:
> On 14/03/19 13:16, Peter Maydell wrote:
>> Mmm, that makes sense. So in this particular case, do we
>> want to try to avoid doing an unbounded allocation based
>> on whatever rubbish the user passed us in the environment,
>> or do we say "this particular case is OK" and ma
On Thu, Mar 14, 2019 at 12:16:06PM +, Peter Maydell wrote:
> On Thu, 14 Mar 2019 at 11:23, Paolo Bonzini wrote:
> >
> > On 14/03/19 11:51, Peter Maydell wrote:
> > > Our coverity model of g_strdup() includes:
> > > __coverity_string_size_sink__(s);
> > >
> > > This seems to be causing Coveri
On 14/03/19 13:16, Peter Maydell wrote:
> Mmm, that makes sense. So in this particular case, do we
> want to try to avoid doing an unbounded allocation based
> on whatever rubbish the user passed us in the environment,
> or do we say "this particular case is OK" and mark it
> as a false-positive ?
On Thu, 14 Mar 2019 at 11:23, Paolo Bonzini wrote:
>
> On 14/03/19 11:51, Peter Maydell wrote:
> > Our coverity model of g_strdup() includes:
> > __coverity_string_size_sink__(s);
> >
> > This seems to be causing Coverity to report false positives like
> > CID1399705 and 1399699 where we take a
On 14/03/19 11:51, Peter Maydell wrote:
> Our coverity model of g_strdup() includes:
> __coverity_string_size_sink__(s);
>
> This seems to be causing Coverity to report false positives like
> CID1399705 and 1399699 where we take a string from getenv() and
> pass it to g_strdup() The getenv() str
Our coverity model of g_strdup() includes:
__coverity_string_size_sink__(s);
This seems to be causing Coverity to report false positives like
CID1399705 and 1399699 where we take a string from getenv() and
pass it to g_strdup() The getenv() string is untrusted data of unknown
length, and g_strdu
