On Tue, Feb 21, 2012 at 4:39 PM, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Tuesday, February 21, 2012, Vincent Torri wrote: > >> On Tue, Feb 21, 2012 at 2:17 PM, Gustavo Sverzut Barbieri >> <barbi...@profusion.mobi <javascript:;>> wrote: >> > On Tue, Feb 21, 2012 at 10:43 AM, Vincent Torri >> > <vincent.to...@gmail.com<javascript:;>> >> wrote: >> >> On Tue, Feb 21, 2012 at 12:42 PM, Joerg Sonnenberger >> >> <jo...@britannica.bec.de <javascript:;>> wrote: >> >>> On Tue, Feb 21, 2012 at 11:33:51AM +0100, Vincent Torri wrote: >> >>>> On Tue, Feb 21, 2012 at 9:50 AM, Joerg Sonnenberger >> >>>> <jo...@britannica.bec.de <javascript:;>> wrote: >> >>>> > On Tue, Feb 21, 2012 at 07:23:36AM +0100, Vincent Torri wrote: >> >>>> >> On Tue, Feb 21, 2012 at 1:18 AM, Joerg Sonnenberger >> >>>> >> <jo...@britannica.bec.de <javascript:;>> wrote: >> >>>> >> > On Tue, Feb 21, 2012 at 12:10:47AM +0100, Vincent Torri wrote: >> >>>> >> >> On Mon, Feb 20, 2012 at 11:38 PM, Joerg Sonnenberger >> >>>> >> >> <jo...@britannica.bec.de <javascript:;>> wrote: >> >>>> >> >> > On Mon, Feb 20, 2012 at 11:28:28PM +0100, Lionel Orry wrote: >> >>>> >> >> >> - eina: the __gnu_printf__ format attribute is only valid >> since GCC >> >>>> >> >> >> 4.4. However, we can find __printf__ format before. I'm not >> sure they >> >>>> >> >> >> are equivalent though, so any hints on the fix >> appreciated... (tested >> >>>> >> >> >> with GCC 4.3.4) >> >>>> >> >> > >> >>>> >> >> > They are supposedly equivalent on Linux and HURD. They are not >> >>>> >> >> > equivalent on other systems and arguably using any glibc >> extensions in >> >>>> >> >> > EFL is a bug. >> >>>> >> >> >> >>>> >> >> Why is it a problem ? As it's tested in a GNUC environment, >> explain me >> >>>> >> >> why it will fail, and on which system. >> >>>> >> > >> >>>> >> > Because other systems don't implement the glibc extensions for >> printf? >> >>>> >> >> >>>> >> that's a gcc problem. But you didn't list the systems for which >> >>>> >> gnu_printf is not implemented, and for which the compilation *will >> >>>> >> fail* >> >>>> > >> >>>> > You misunderstand. The problem is not that gnu_printf is not >> recognized >> >>>> > by GCC, but that the underlaying printf implementation may not >> support >> >>>> > the GNU extensions. So it is pretty pointless to mark >> eina_log_print as >> >>>> > supporting the GNU extensions, if that it isn't true about printf. >> The >> >>>> > most trivial example of a GNU extension for printf from memory is >> %m. >> >>>> >> >>>> ok. I had that problem for the Windows port. So I added in it a 'gnu' >> >>>> version of printf, that is provided by the MinGW team (no licence >> >>>> problem, it's PD). >> >>> >> >>> Windows is a bit special as Microsoft doesn't believe in C99 support. >> >>> There are generally no excuses for using the GNU extensions for printf >> >>> -- they are pretty much completely pointless. >> >> >> >> I needed such port for %z and %hh, which are not supported by microsoft >> libc >> > >> > Moreover, if this approach of gnu extensions will be supported, I'll >> > be VERY happy to use %m instead of lengthy '"%s", strerror(errno)' >> > >> > Also, "%s", NULL will work instead of segfault :-) >> >> see evil_print.h evil_printa.c evil_printw.c evil_macro.h and >> evil_macro_pop.h > > > I mean: can we trust this will be the case for every platform? That > includes BSD and Solaris. Will we use your printf in these as well?
You can't assume this, indeed. Vincent ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
