On Sat, Oct 30, 2010 at 7:35 AM, Carsten Haitzler <ras...@rasterman.com> wrote: > On Sat, 30 Oct 2010 11:25:05 +0200 (CEST) Vincent Torri <vto...@univ-evry.fr> > said: > >> >> >> On Sat, 30 Oct 2010, Carsten Haitzler (The Rasterman) wrote: >> >> > On Sat, 30 Oct 2010 09:14:39 +0200 (CEST) Vincent Torri >> > <vto...@univ-evry.fr> said: >> > >> >> On Fri, 29 Oct 2010, Enlightenment SVN wrote: >> >> >> >>> Log: >> >>> aaagh. dirent... bad! too many things in dirent that are not portable >> >>> - d_type for example... so put that into the direct_info struct and >> >>> handle the compat in eina. >> >> >> >>> +#ifdef _DIRENT_HAVE_D_NAMLEN >> >> >> >> wouldn't is be better to test if d_namlen or d_type are available in >> >> configure.ac ? >> > >> > that's what that #ifdef does... the system defines those if it has the >> > extended fields. whats more a quesrtion is.. shoudl we remove dirent struct >> > from the eina struct? i don't like that being there. >> >> yes, we should (must) remove it. > > i agree with you - i'm waiting for someone to make a good case for not doing > it > (especially now i moved the d_type info into the eina info struct that always > works).
Damn, you talk a lot while I'm away... I added the dirent to Direct_Info, there was no hard reason other than offer a fast option to query information without having to stat() the file to know if it was a file/dir and other fields could be useful (ino for cedric). I never ever realized it would be such a can of worms, my bad. So while I'm fine with its removal, let's keep the type in Direct_Info as Raster did, but couple of remarks: - I'm quite against creating yet-another enum that just duplicates what's in C posix standard. It just makes code larger as you need conversion switch case that servers no good other than duplication. - If there is no d_type member, just make it DT_UNKNOWN as many filesystem does use that and user is forced to stat() afterwards anyway. Among of these lines, I also would like to put that I really dislike the new eio_file accessors that just acess "struct stat" members. It's just not required, let's avoid going into the glib trap that renames all standards to their own prefix... Every C book out there will explain "stat(file, &st)"... then use "st->st_mtime". If you happen to have queried with &st all the "help" from eio_file_mtime() is do an useless check if st is null. :-/ -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ------------------------------------------------------------------------------ Nokia and AT&T present the 2010 Calling All Innovators-North America contest Create new apps & games for the Nokia N8 for consumers in U.S. and Canada $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store http://p.sf.net/sfu/nokia-dev2dev _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
