Richard Guenther wrote:
...
>>> The patch is ok with caching strlen and using memcpy.
>>
>> Like this, I presume:
>> [alternatively, declare and compute m_len on a separate line,
>> just before the comparison:
>> size_t m_len = strlen (m->name);
>> I'd actually prefer that, but don't know if de
On Thu, Apr 19, 2012 at 3:01 PM, Jim Meyering wrote:
> Richard Guenther wrote:
>> On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
>>> Richard Guenther wrote:
On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
> Found by inspection.
> Seeing this strncpy use without the usual
Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
>> Richard Guenther wrote:
>>> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
Found by inspection.
Seeing this strncpy use without the usual following NUL-termination,
my reflex was that it was a
On Thu, Apr 19, 2012 at 02:38:11PM +0200, Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 2:34 PM, Jakub Jelinek wrote:
> > On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
> >> That's better. Or even cache the strlen result and use memcpy here
> >> as Jakub suggested.
> >
> >
On Thu, Apr 19, 2012 at 2:34 PM, Jakub Jelinek wrote:
> On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
>> That's better. Or even cache the strlen result and use memcpy here
>> as Jakub suggested.
>
> tree-ssa-strlen.c will do that for you when optimizing in this case ;)
Does i
On Thu, Apr 19, 2012 at 02:31:37PM +0200, Richard Guenther wrote:
> That's better. Or even cache the strlen result and use memcpy here
> as Jakub suggested.
tree-ssa-strlen.c will do that for you when optimizing in this case ;)
Jakub
On Thu, Apr 19, 2012 at 2:13 PM, Jim Meyering wrote:
> Richard Guenther wrote:
>> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
>>> Found by inspection.
>>> Seeing this strncpy use without the usual following NUL-termination,
>>> my reflex was that it was a buffer overrun candidate, but t
Richard Guenther wrote:
> On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
>> Found by inspection.
>> Seeing this strncpy use without the usual following NUL-termination,
>> my reflex was that it was a buffer overrun candidate, but then I
>> realized this is gcc, so that's not very likely.
>>
On Thu, Apr 19, 2012 at 02:01:36PM +0200, Richard Guenther wrote:
> strncpy -> strcpy definitely looks like premature optimization to me.
I disagree. Almost all uses of strncpy are wrong. If the string length is
smaller, than it is unlikely useful that it clears all remaining bytes
(sometimes ma
On Thu, Apr 19, 2012 at 12:42 PM, Jim Meyering wrote:
> Found by inspection.
> Seeing this strncpy use without the usual following NUL-termination,
> my reflex was that it was a buffer overrun candidate, but then I
> realized this is gcc, so that's not very likely.
> Looking a little harder, I saw
Found by inspection.
Seeing this strncpy use without the usual following NUL-termination,
my reflex was that it was a buffer overrun candidate, but then I
realized this is gcc, so that's not very likely.
Looking a little harder, I saw the preceding strlen >= sizeof buf test,
which means there is no
11 matches
Mail list logo
