If an unterminated string is getting all the way to readdir() and ls, doesn't that mean that somewhere a NULL wasn't put on it when it was added to the directory entry?
A quick review makes me think imfs_creat.c and imfs_rename.c at least do not appear to be accounting for the NULL. On 3/16/2015 1:18 PM, Sebastian Huber wrote: > Module: rtems > Branch: master > Commit: 674f8b1b050c7f6544424ea5c882878699dbc248 > Changeset: > http://git.rtems.org/rtems/commit/?id=674f8b1b050c7f6544424ea5c882878699dbc248 > > Author: Jamie Iles <ja...@jamieiles.com> > Date: Mon Mar 16 17:23:36 2015 +0000 > > IMFS: don't strlen() an unterminated string in IMFS_dir_read(). > > a43a3466 (IMFS: Implement variable length node names) introduced a > changed to IMFS_jnode_t from being a null terminated string to a > separate unterminated string and length. IMFS_dir_read() was still > performing a strlen() on this unterminated string though and when doing > an 'ls' in the fileio example I saw that some filenames had garbage > suffixes. > > --- > > cpukit/libfs/src/imfs/imfs_dir_default.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/cpukit/libfs/src/imfs/imfs_dir_default.c > b/cpukit/libfs/src/imfs/imfs_dir_default.c > index 98f06df..2f12072 100644 > --- a/cpukit/libfs/src/imfs/imfs_dir_default.c > +++ b/cpukit/libfs/src/imfs/imfs_dir_default.c > @@ -73,7 +73,7 @@ static ssize_t IMFS_dir_read( > dir_ent->d_off = current_entry; > dir_ent->d_reclen = sizeof( *dir_ent ); > dir_ent->d_ino = IMFS_node_to_ino( imfs_node ); > - dir_ent->d_namlen = strlen( imfs_node->name ); > + dir_ent->d_namlen = imfs_node->namelen; > memcpy( dir_ent->d_name, imfs_node->name, dir_ent->d_namlen + 1 ); > > iop->offset += sizeof( *dir_ent ); > > _______________________________________________ > vc mailing list > v...@rtems.org > http://lists.rtems.org/mailman/listinfo/vc -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel