Forgot to reply on-list, sorry 2012/2/1 David Turner <da...@freetype.org>
> > > 2012/1/28 suzuki toshiya <mpsuz...@hiroshima-u.ac.jp> > >> >> Also I've checked ANSI C (C89) spec draft, available on: >> http://flash-gordon.me.uk/ansi.c.txt >> In the description of sizeof operator, I could not find explicit >> permission to pass the variable (not the type) to sizeof operator, >> > > The sizeof operator can take a "unary expression" as its argument, which > includes simple variable designators. > The only constraint is that the expression must have a known type at > compile time, so "sizeof varname" is completely legal. > The parenthesis are only needed for "sizeof (typename)" > > >> but I could find examples doing such: >> >> extern void *alloc(); >> double *dp = alloc(sizeof *dp); >> >> or >> >> sizeof array / sizeof array[0] >> >> I think prohibiting the first example and rewriting it as >> "double* dp = alloc(sizeof(double));" does not make the maintainability >> worse, > > > It does make maintainability worse because it prevents handy macros like > FT_NEW or FT_NEW_ARRAY from working properly. > Besides, it's not forbidden in any way by the standard. > > >> but prohibiting the second example will make the maintainability >> worse. The second example is refused by BREW "official" compiler? >> >> The second example is refused because the first sizeof operator gets the > expression "array / sizeof array[0]" which isn't valid. > It should work if written as: > > (sizeof array)/(sizeof array[0]) > or > sizeof(array)/sizeof(array[0]) > > >> I think the second example is quite widely used, and some consideration >> is needed. >> >> I understand that many companies in embedded system market are selling >> stubborn SDKs whose compilers are not conforming to C89 and the companies >> had already lost how to maintain their SDKs, but I don't know appropriate >> & well-defined subset of C89 to modify FreeType2 to fit it. >> >> Regards, >> mpsuzuki >> >> >> >> >> >> >> Regarding testing of the PIC mode, yes you can test it on Linux even >> >> though PIC isn't normally required there. The linker that has issues >> >> with strings and array initializations like in ftobjs.c is for the Brew >> >> platform. >> > >> > Thanks. I heard that BREW's official SDK is based on ARM RVCT >> > compiler in Microsoft Visual C++ IDE. I don't have MSVC IDE, >> > but I will check if there is any free-charged version of RVCT >> > compiler. >> > >> > Regards, >> > mpsuzuki >> > >> >> On Tue, 17 Jan 2012 07:54:40 +0100, suzuki toshiya >> >> <mpsuz...@hiroshima-u.ac.jp> wrote: >> >> >> >>> During the overhaul for PIC build, I found that cache subsystem >> >>> of FreeType2 is not ready for PIC build, thus the demo programs >> >>> doing rasterization (e.g. ftview, ftbench) cannot be built. >> >>> Thus I can check if the code is compilable, but cannot check >> >>> if the code is working. Maybe most expected direction is the >> >>> porting of the cache subsystem for PIC build (even if there is >> >>> no real user of it on embedded system), but extending some demo >> >>> programs for FreeType2 without cache subsystem would be easier >> >>> first step. >> >>> >> >>> # I assume FreeType2 built in PIC mode will work in the operating >> >>> # system that PIC mode is NOT required (e.g. Linux). If it's >> >>> # misunderstanding, please let me know. >> >>> >> >>> Any comments? >> >>> >> >>> Regards, >> >>> mpsuzuki >> >>> >> >>> suzuki toshiya wrote: >> >>>> Dear Erik, >> >>>> >> >>>> I have made some overhaul for PIC build, and, your patch to >> >>>> modify resource fork support for PIC build is applied with >> >>>> some coding style changing. Please check whether GIT head >> >>>> works on your platform. >> >>>> >> >>>> BTW, >> >>>> >> >>>> diff --git a/src/base/ftobjs.c b/src/base/ftobjs.c >> >>>> index 1a5a327..fc687f5 100644 >> >>>> --- a/src/base/ftobjs.c >> >>>> +++ b/src/base/ftobjs.c >> >>>> @@ -4533,7 +4533,9 @@ >> >>>> */ >> >>>> { >> >>>> FT_UInt m, n; >> >>>> - const char* driver_name[] = { "type42", NULL }; >> >>>> + const char* driver_name[2]; >> >>>> + driver_name[0] = "type42"; >> >>>> + driver_name[1] = NULL; >> >>>> >> >>>> >> >>>> for ( m = 0; >> >>>> >> >>>> is not committed yet, because I want to know which linker complains >> >>>> about such initialization. If possible, please let me know 1 example >> >>>> to be documented in ChangeLog. I'm not saying "there should not be >> >>>> such linker", just I want to know 1 example, for good documentation. >> >>>> Sorry for troubling you. >> >>>> >> >>>> Regards, >> >>>> mpsuzuki >> >>>> >> >>>> suzuki toshiya wrote: >> >>>>> Dear Erik, >> >>>>> >> >>>>> Sorry for your trouble and thank you for providing a patch, >> >>>>> I will check it in this weekend. Please give me a few days. >> >>>>> >> >>>>> Regards, >> >>>>> mpsuzuki >> >>>>> >> >>>>> Werner LEMBERG wrote: >> >>>>>>> The commits in question are both dealing with compilation of >> >>>>>>> 'complex' structures and static globals. >> >>>>>> Thanks for the patch. Toshiya-san, can you have a look and take >> care >> >>>>>> of it, please? >> >>>>>> >> >>>>>> >> >>>>>> Werner >> >> >> > >> > >> > _______________________________________________ >> > Freetype-devel mailing list >> > Freetype-devel@nongnu.org >> > https://lists.nongnu.org/mailman/listinfo/freetype-devel >> >> >> _______________________________________________ >> Freetype-devel mailing list >> Freetype-devel@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/freetype-devel >> > >
_______________________________________________ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
