Re: No need for AV tools on Linux, eh?



On 18 February 2011 19:13, Joe Zeff <joe@xxxxxxx> wrote:
On 02/18/2011 09:55 AM, Ian Malone wrote:
To derail discussion slightly, this doesn't really fix the problem,
just shifts it to a different place (keeping track of lengths and
dynamically handling data)

In a word, "NO."  You know how big your buffer is so you only allow
strncpy() to copy that many bytes, throwing away any excess.

Used properly, yes you've avoided buffer overruns, used badly no.
strncpy(dest,src,strlen(src)+1)
Ridiculous? Yes. Never used in practice? I'd like to believe it.
strncpy has been in C since it was first standardised, but people
still write code that overflows.

--
imalone
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines


Relevant Pages

  • Re: No need for AV tools on Linux, eh?
    ... just shifts it to a different place (keeping track of lengths and ... "NO." You know how big your buffer is so you only allow ...
    (Fedora)
  • Re: Function Points
    ... I should've compared with strncpy() instead of strcpy. ... strncpyalso copies into a buffer of unknown size, ... of that string actually is, so strncat is not that helpful. ... I'm not sure if these are the type of hash functions they need, ...
    (comp.lang.forth)
  • Re: strcpy() - dangerous? [Was Re: gets() - dangerous?]
    ... >> buffer and act accordingly if it does. ... > The two strings must not overlap too with strncpy(). ... outside of src or dst gets overwritten. ... and strcpy speaks of the size of dst ...
    (comp.lang.c)
  • Re: strcpy() - dangerous? [Was Re: gets() - dangerous?]
    ... > The more dangerous problem with strncpy is: If the destination buffer is ... If you use strncpy to copy into a 10 byte ... > copying 9 bytes and a trailing zero, which at least would have given you ... > a valid C string. ...
    (comp.lang.c)
  • Re: [C] simple string question
    ... > That's one of the problems with strncpy. ... We might have been clever enough to make the target buffer ... If I know that most of the time my input is between 18-20 characters, ... creating a buffer overrun with strncpy is less likely than with strcpy. ...
    (alt.comp.lang.learn.c-cpp)