From dev-return-62424-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Mon Feb 5 23:03:13 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id A6FF1180647 for ; Mon, 5 Feb 2018 23:03:13 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 96BD0160C4B; Mon, 5 Feb 2018 22:03:13 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id B85DF160C3B for ; Mon, 5 Feb 2018 23:03:12 +0100 (CET) Received: (qmail 45221 invoked by uid 500); 5 Feb 2018 22:03:11 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 45210 invoked by uid 99); 5 Feb 2018 22:03:11 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Feb 2018 22:03:11 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 47EF2C1DD4 for ; Mon, 5 Feb 2018 22:03:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.528 X-Spam-Level: X-Spam-Status: No, score=-0.528 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.972] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id TVuughqtO4hB for ; Mon, 5 Feb 2018 22:03:10 +0000 (UTC) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id EC5EE5F33F for ; Mon, 5 Feb 2018 22:03:09 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 76B1C21097 for ; Mon, 5 Feb 2018 23:03:08 +0100 (CET) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 3zb1mp1cvmz9rxW for ; Mon, 5 Feb 2018 23:03:06 +0100 (CET) Subject: Re: SvpGlyphPeer::RemovingGlyph() compile error To: dev@openoffice.apache.org References: <18b9cceb-bc2d-6665-8201-0788915d2035@Apache.org> From: Peter Kovacs Organization: Open Office Project Message-ID: Date: Mon, 5 Feb 2018 23:03:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US If you speak for underlying Issues, you might refer to this? I have stashed this change in /main/basebmp/inc/basebmp/scanlineformats.hxx and I do not like the existing implementation. namespace basebmp { /* Current implementation */ namespace Format { static const sal_Int32 NONE = 0; static const sal_Int32 ONE_BIT_MSB_GREY = (sal_Int32)0x01; static const sal_Int32 ONE_BIT_LSB_GREY = (sal_Int32)0x02; static const sal_Int32 ONE_BIT_MSB_PAL = (sal_Int32)0x03; static const sal_Int32 ONE_BIT_LSB_PAL = (sal_Int32)0x04; static const sal_Int32 FOUR_BIT_MSB_GREY = (sal_Int32)0x05; static const sal_Int32 FOUR_BIT_LSB_GREY = (sal_Int32)0x06; static const sal_Int32 FOUR_BIT_MSB_PAL = (sal_Int32)0x07; static const sal_Int32 FOUR_BIT_LSB_PAL = (sal_Int32)0x08; static const sal_Int32 EIGHT_BIT_PAL = (sal_Int32)0x09; static const sal_Int32 EIGHT_BIT_GREY = (sal_Int32)0x0A; static const sal_Int32 SIXTEEN_BIT_LSB_TC_MASK = (sal_Int32)0x0B; static const sal_Int32 SIXTEEN_BIT_MSB_TC_MASK = (sal_Int32)0x0C; static const sal_Int32 TWENTYFOUR_BIT_TC_MASK = (sal_Int32)0x0D; static const sal_Int32 THIRTYTWO_BIT_TC_MASK = (sal_Int32)0x0E; static const sal_Int32 THIRTYTWO_BIT_TC_MASK_ARGB = (sal_Int32)0x0F; static const sal_Int32 MAX = (sal_Int32)0x0F; } /* what it should be enum class Format : sal_Int32 { NONE = 0 , ONE_BIT_MSB_GREY = 0x01 , ONE_BIT_LSB_GREY = 0x02 , ONE_BIT_MSB_PAL = 0x03 , ONE_BIT_LSB_PAL = 0x04 , FOUR_BIT_MSB_GREY = 0x05 , FOUR_BIT_LSB_GREY = 0x06 , FOUR_BIT_MSB_PAL = 0x07 , FOUR_BIT_LSB_PAL = 0x08 , EIGHT_BIT_PAL = 0x09 , EIGHT_BIT_GREY = 0x0A , SIXTEEN_BIT_LSB_TC_MASK = 0x0B , SIXTEEN_BIT_MSB_TC_MASK = 0x0C , TWENTYFOUR_BIT_TC_MASK = 0x0D , THIRTYTWO_BIT_TC_MASK = 0x0E , THIRTYTWO_BIT_TC_MASK_ARGB = 0x0F , MAX = 0x0F }; */ } I do not feel well with the test options. The basic Idea I wanted to go with was to write a specific test, compile it on CentOS 6 (where old and new stuff should work.) And make sure possible out put is the same (Blackbox testing) Locate all Uses would be also necessary in order to check. Thats where I got stuck on this topic. Please note that enumn class is pretty new. So I do not know if it works on CentOS 6. I just thought I do write the best code for me and worry about Compiler Version issue as a later step. Also another Idea could be to cut out the code and replace it with a general better design. But then we need to find the user story to it. Which is a lot of digging. And I dont think the code is that bad on first glance. On 05.02.2018 19:34, Don Lewis wrote: > 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-unsubscribe@openoffice.apache.org >>> For additional commands, e-mail: dev-help@openoffice.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org >> For additional commands, e-mail: dev-help@openoffice.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org > For additional commands, e-mail: dev-help@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org For additional commands, e-mail: dev-help@openoffice.apache.org