On Wed, 21 Sep 2016 16:52:31 -0700 Cedric BAIL <[email protected]> said:
> On Wed, Sep 21, 2016 at 4:32 PM, Carsten Haitzler <[email protected]> > wrote: > > On Wed, 21 Sep 2016 08:33:11 -0700 Cedric BAIL <[email protected]> said: > >> On Sep 21, 2016 4:18 AM, "Carsten Haitzler" <[email protected]> wrote: > >> > raster pushed a commit to branch master. > >> > > >> > > >> http://git.enlightenment.org/core/enlightenment.git/commit/?id=5861d9bef949c64cbc7ddad31b4ac2cc70bb6440 > >> > > >> > commit 5861d9bef949c64cbc7ddad31b4ac2cc70bb6440 > >> > Author: Carsten Haitzler (Rasterman) <[email protected]> > >> > Date: Wed Sep 21 20:18:01 2016 +0900 > >> > > >> > protect against non-nul terminated string from mmap in filepreview > >> > > >> > this should address 2nd gdb bt and fix T4543 > >> > >> No ! This patch is unnecessary or more exactly too late. Previous code was > >> using the _n variant of append which call strlen. The current code only > >> rely on the given length. Will revert. > > > > why on earth is it doing strlen when obviously n bytes are to go in (or > > until the nul byte)? > > It is the same difference as memcpy and strncpy. One take the original > pointer as just data, the other as a string. So the _n variant is the > one that does call strlen to get the max number of character to copy. shouldnt it walk UP to n and if it sees a 0 byte before that... take that as len otherwise take given length n as len? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
