Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
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
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
2012/1/17 Erik Dahlstrom e...@opera.com Hi, after I submitted my first patches I found a bunch of other PIC issues. I see that you have fixed some of the same things I found too, mostly missing includes to the various error-headerfiles, and a bunch of unitialized variables for clazz and the various PIC modules, and pointer dereferences of the same. One example of that, there are plenty more: diff --git a/modules/libfreetype/include/**freetype/internal/ftdriver.h b/modules/libfreetype/include/**freetype/internal/ftdriver.h index bbb9ddd..333f908 100644 --- a/modules/libfreetype/include/**freetype/internal/ftdriver.h +++ b/modules/libfreetype/include/**freetype/internal/ftdriver.h @@ -366,11 +366,11 @@ FT_BEGIN_HEADER FT_Create_Class_##class_( FT_Librarylibrary, \ FT_Module_Class** output_class ) \ { \ -FT_Driver_Class clazz; \ +FT_Driver_Class clazz = NULL; \ FT_Error error; \ FT_Memorymemory = library-memory; \ \ -if ( FT_ALLOC( clazz, sizeof(*clazz) ) ) \ +if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) ) \ return error; \ \ error = class_##_pic_init( library ); \ I think It would be simpler to fix FT_ALLOC() to perform a dummy NULL assignment on the first parameter for this specific compiler. If you prefer I can send another patch with those changes. 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. 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 -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed __**_ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/**mailman/listinfo/freetype-**develhttps://lists.nongnu.org/mailman/listinfo/freetype-devel ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
Dear Erik, Could you notice the current status of your efforts to replace sizeof(*xxx_p) by sizeof(xxx) in FreeType2 source code? Recently I've searched some tools to automate such translation, but I could not find easy tools, so I think the manual work is needed. suzuki toshiya wrote: -if ( FT_ALLOC( clazz, sizeof(*clazz) ) +if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) If you prefer I can send another patch with those changes. Ahhh... although I'm not sure whether ANSI C requests that sizeof(*xxx_p) works as sizeof(xxx), I think such modification is not bad idea. BTW, sizeof(*xxx_p) style coding is refused by the compiler? or linker? 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, 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, but prohibiting the second example will make the maintainability worse. The second example is refused by BREW official compiler? 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
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
Hi, after I submitted my first patches I found a bunch of other PIC issues. I see that you have fixed some of the same things I found too, mostly missing includes to the various error-headerfiles, and a bunch of unitialized variables for clazz and the various PIC modules, and pointer dereferences of the same. One example of that, there are plenty more: diff --git a/modules/libfreetype/include/freetype/internal/ftdriver.h b/modules/libfreetype/include/freetype/internal/ftdriver.h index bbb9ddd..333f908 100644 --- a/modules/libfreetype/include/freetype/internal/ftdriver.h +++ b/modules/libfreetype/include/freetype/internal/ftdriver.h @@ -366,11 +366,11 @@ FT_BEGIN_HEADER FT_Create_Class_##class_( FT_Library library, \ FT_Module_Class** output_class )\ { \ -FT_Driver_Class clazz; \ +FT_Driver_Class clazz = NULL; \ FT_Error error; \ FT_Memorymemory = library-memory; \ \ -if ( FT_ALLOC( clazz, sizeof(*clazz) ) ) \ +if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) ) \ return error; \ \ error = class_##_pic_init( library );\ If you prefer I can send another patch with those changes. 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. 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 -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel
Re: [ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
Dear Erik, Of course, I want to receive the patch to improve (rather, I should call restore) PIC build. I wish if my overhaul have not made you troubled. Erik Dahlstrom wrote: diff --git a/modules/libfreetype/include/freetype/internal/ftdriver.h b/modules/libfreetype/include/freetype/internal/ftdriver.h index bbb9ddd..333f908 100644 --- a/modules/libfreetype/include/freetype/internal/ftdriver.h +++ b/modules/libfreetype/include/freetype/internal/ftdriver.h @@ -366,11 +366,11 @@ FT_BEGIN_HEADER FT_Create_Class_##class_( FT_Library library, \ FT_Module_Class** output_class )\ { \ -FT_Driver_Class clazz; \ +FT_Driver_Class clazz = NULL; \ FT_Error error; \ FT_Memorymemory = library-memory; \ \ -if ( FT_ALLOC( clazz, sizeof(*clazz) ) ) \ +if ( FT_ALLOC( clazz, sizeof(FT_Driver_ClassRec) ) ) \ return error; \ \ error = class_##_pic_init( library );\ If you prefer I can send another patch with those changes. Ahhh... although I'm not sure whether ANSI C requests that sizeof(*xxx_p) works as sizeof(xxx), I think such modification is not bad idea. BTW, sizeof(*xxx_p) style coding is refused by the compiler? or linker? 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
[ft-devel] Testing PIC mode code (Re: Fixes for some compile and link errors when using FT_CONFIG_OPTION_PIC)
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