There is at least one other place in this code that uses the
rGlyphData.ExtDataRef().meInfo to Format::NONE comparision.

I think there are some deeper problems in this code.  Unfortunately
I won't have another chance to dig into it until the end of this week.

Something else to think about is how to test this code.

On  2 Feb, Peter Kovacs wrote:
> It does also not compile on gcc 7.xx
> 
> So I did change the code and it compiles
> 
>     if( rGlyphData.ExtDataRef().mpData != NULL )
> 
> But I think it has to be
> 
>     if( rGlyphData.ExtDataRef().mpData != NULL && 
> rGlyphData.ExtDataRef().mpData != Format::NONE)
> 
> 
> You can work around this issue in gcc by setting some flags that allows 
> the use of Format::NONE directly. But i concider this as not so good.
> 
> All the best
> Peter
> 
> On 30.01.2018 21:01, Don Lewis wrote:
>> When doing a build with clang 6, which defaults to c++14, I get a
>> compile error in SvpGlyphPeer::RemovingGlyph() in
>> vcl/unx/headless/svptext.cxx on this line:
>>
>>      if( rGlyphData.ExtDataRef().mpData != Format::NONE )
>>
>> This isn't too surprising since Format::NONE is an integer and mpData is
>> a pointer.
>>
>> There are a couple of ways that I thought of fixing this.  One is to
>> change the right side of the comparision to NULL, the other is to change
>> the left side to use meInfo.
>>
>> Then I used OpenGrok to dig through the code, and the only assignments
>> to meInfo that I found were in main/vcl/unx/generic/gdi/gcach_xpeer.cxx
>> and use the values from this enum:
>>    enum { INFO_EMPTY=0, INFO_PIXMAP, INFO_XRENDER, INFO_RAWBMP, 
>> INFO_MULTISCREEN };
>>
>> This makes no sense given the other comparisions to meInfo in
>> svptext.cxx and the code in SvpGlyphPeer::GetGlyphBmp() starting on line
>> 92 of that file.  There is a call to rServerFont.SetExtended() that gets
>> the value of nBmpFormat, but that sets private member mnExtInfo in class
>> ServerFont in glyphcache.hxx, whereas meInfo is a struct field where the
>> struct is a private member of class GlyphData.
>>
>> Thoughts?
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Reply via email to