[ft-devel] freetype compilation warnings

Hi all, I have just today updated VTK (www.vtk.org) from using freetype 2.3.7 to 2.3.11. The VTK project has a large number and variety of machines doing nightly compilations and some of them are showing compiler warnings from freetype. I'm hoping the freetype devs can look at them, and consider

Re: [ft-devel] freetype compilation warnings

Hi, Thank you for the information, I will check, although I don't have Microsoft VisualStudio compiler. BTW, Could you test revised configure (not commited to git repository yet) for Mac OS X 10.6? http://lists.gnu.org/archive/html/freetype-devel/2009-11/msg00045.html Regards, mpsuzuki On Mon

Re: [ft-devel] freetype compilation warnings

Thanks for the report. > 4 warnings: > I've fixed them in git. > 26 warnings: > > > Some of them look harmless, others look like they should be fixed. Toshiya-san, please

Re: [ft-devel] freetype compilation warnings

On 12/15/09 9:00 AM, Werner LEMBERG said: >Thanks for the report. Thanks for fixing them! Here are a few more from overnight builds, some warnings are duplicates, but some are not: /.../VTK/Utilities/vtkfreetype/src/base/ftdbgmem.c:9

Re: [ft-devel] freetype compilation warnings

On 12/15/09 9:00 AM, Werner LEMBERG said: >Thanks for the report. > >> 4 warnings: >> > >I've fixed them in git. I don't think your fix was right, the warnings are still there:

Re: [ft-devel] freetype compilation warnings

> I don't think your fix was right, the warnings are still there: > > > Note that those lines have 2 comparisons, not sure which it is > complaining about... OK, hopefully it's now really fixed in git. Please test. Werne

Re: [ft-devel] freetype compilation warnings

> > /.../VTK/Utilities/vtkfreetype/src/base/ftdbgmem.c:992: warning: > `_debug_mem_dummy' defined but not used This is expected, more or less: #if FT_DEBUG_MEMORY ... #else /* !FT_DEBUG_MEMORY */ /* ANSI C doesn't like empt

Re: [ft-devel] freetype compilation warnings

On 12/16/09 6:14 PM, Werner LEMBERG said: >> I don't think your fix was right, the warnings are still there: >> >> >> Note that those lines have 2 comparisons, not sure which it is >> complaining about... > >OK, hopefully it's n

Re: [ft-devel] freetype compilation warnings

> I'm afraid it still warns, which doesn't surprise me (I don't think > changing from enum to #define changes the sign of the constant). Hmm. An enumeration is implicitly a signed int, whereas I've always thought that the compiler automatically assigns either signed or unsigned to (positive) con

Re: [ft-devel] freetype compilation warnings

>> Just getting rid of _debug_mem_dummy would cause a problem? Is >> there another way to create a non-empty file? How about a useless >> but harmless #include, like #include ? > > Ah, I haven't thought of that. Sounds like a good idea. Well, after some thinking I now believe that this doesn't

Re: [ft-devel] freetype compilation warnings

On 12/20/09 6:20 PM, Werner LEMBERG said: >>> Just getting rid of _debug_mem_dummy would cause a problem? Is >>> there another way to create a non-empty file? How about a useless >>> but harmless #include, like #include ? >> >> Ah, I haven't thought of that. Sounds like a good idea. > >Well, af

Re: [ft-devel] freetype compilation warnings

>>Yes, this seems to be the cause. However, fixing this is not easy >>(except providing a new macro which is rather unelegant) -- at least >>for me. Any idea how to work around the warning? > > Not off the top of my head. The other question is: how serious is > this warning? Good question. U

Re: [ft-devel] freetype compilation warnings

Werner, There are still some warnings from the VTK nightly builds: (search for "freetype") I believe this is due to: #define ALL_POINTS (FT_UShort*)( -1 ) To me, it seems dangerous to have a pointer type that is not a pointer. Other

Re: [ft-devel] freetype compilation warnings

> There are still some warnings from the VTK nightly builds: > > (search for "freetype") Thanks. > I believe this is due to: > > #define ALL_POINTS (FT_UShort*)( -1 ) > > To me, it seems dangerous to have a pointer type that is not a

Re: [ft-devel] freetype compilation warnings

On 1/9/10 6:40 AM, Werner LEMBERG said: >What about a double cast? > > #define ALL_POINTS (FT_UShort*)(void*)( -1 ) > >Since NULL is normally defined as `(void*)0' I can imagine that the >above works. Can you try this, please? That did not work. :( The warning only changed to: warning C4306:

Re: [ft-devel] freetype compilation warnings

"Sean McBride" wrote: > On 1/9/10 6:40 AM, Werner LEMBERG said: > > >What about a double cast? > > > > #define ALL_POINTS (FT_UShort*)(void*)( -1 ) > > > >Since NULL is normally defined as `(void*)0' I can imagine that the > >above works. Can you try this, please? > > That did not work. :( T

Re: [ft-devel] freetype compilation warnings

On 1/11/10 11:04 AM, Dmitry Timoshkov said: >> >What about a double cast? >> > >> > #define ALL_POINTS (FT_UShort*)(void*)( -1 ) >> > >> >Since NULL is normally defined as `(void*)0' I can imagine that the >> >above works. Can you try this, please? >> >> That did not work. :( The warning only c

Re: [ft-devel] freetype compilation warnings

At 12:28 11/01/2010 -0500, Sean McBride wrote: >#define ALL_POINTS (FT_UShort*)(void*)( ~0UL ) I don't have the compiler in question, so the only way for me to test is commit the change to VTK CVS then wait for the next automated nightly build. :( Anyone here have Visual Studio? Yes, any

Re: [ft-devel] freetype compilation warnings

At 12:28 11/01/2010 -0500, Sean McBride wrote: >> warning C4306: 'type cast' : conversion from 'int' to 'void *' of >greater size [snip] I don't have the compiler in question, so the only way for me to test is commit the change to VTK CVS then wait for the next automated nightly build. :

RE: [ft-devel] freetype compilation warnings

Re: [ft-devel] freetype compilation warnings At 12:28 11/01/2010 -0500, Sean McBride wrote: > >#define ALL_POINTS (FT_UShort*)(void*)( ~0UL ) > >I don't have the compiler in question, so the only way for me to test is >commit the change to VTK CVS then wait for the n

RE: [ft-devel] freetype compilation warnings

Re: [ft-devel] freetype compilation warnings At 12:28 11/01/2010 -0500, Sean McBride wrote: > >#define ALL_POINTS (FT_UShort*)(void*)( ~0UL ) > >I don't have the compiler in question, so the only way for me to test is >commit the change to VTK CVS then wait for the n

Re: [ft-devel] freetype compilation warnings

On 1/12/10 4:43 AM, David Bevan said: >All the proposed solutions assume that there is a (known) integer size >which matches the pointer size. There is: intptr_t. But it's part of C99, which freetype can not require. :( >I would expect something like the following to work (though I don't have >

Re: [ft-devel] freetype compilation warnings

On 1/12/10 11:09 AM, Sean McBride said: >On 1/12/10 4:43 AM, David Bevan said: > >>All the proposed solutions assume that there is a (known) integer size >>which matches the pointer size. > >There is: intptr_t. But it's part of C99, which freetype can not require. :( > >>I would expect something

Re: [ft-devel] freetype compilation warnings

>>>#define ALL_POINTS (FT_UShort*)((FT_Byte*)(NULL) - 1); >> >>Clever! I'll commit this to VTK and we'll see tomorrow. > > Well, this silenced Visual Studio, but now another compiler on another > machine is complaining: > >