From prasanta.sadhukhan at oracle.com Thu Dec 1 05:05:28 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 1 Dec 2016 10:35:28 +0530 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> Message-ID: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Also, in gtk3_interface.c, there is this change for color.alpha 2219 color.alpha = 0; in gtk3_get_color_for_flags() but it is used in gtk3_get_color_for_state() where it is not initialized 2268 GdkRGBA color; Regards Prasanta On 12/1/2016 1:28 AM, Phil Race wrote: > Hi Goetz, > >> DataBufferNative.c >> Using uninitialized value lockInfo.rasBase when calling >> DBN_GetPixelPointer. > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >> cc 2d-dev. >> >> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>> Hi Vincent, >>> >>> thanks for the quit review! >>> Good catch that I lost the change to p11_mutex.c ... I had to change >>> it and it fell out of my patches. >>> I edited the Last Modified Date, and also updated the copyright >>> messages. >>> New webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>> >>> Best regards, >>> Goetz. >>> >>> (Am I correct that your openJdk name is Vinnie?) >>> >>>> -----Original Message----- >>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>> Sent: Mittwoch, 30. November 2016 14:53 >>>> To: Lindenmaier, Goetz >>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>> >>>> Hello Goetz, >>>> >>>> Please modify the bug summary to reference ECC too. >>>> Your ECC changes look fine but the ?Last Modified Date? line in the >>>> 4 source >>>> code headers will need to be updated/added. >>>> >>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>> webrev. >>>> >>>> Thanks. >>>> >>>> >>>> >>>> >>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>> > wrote: >>>> >>>> Hi, >>>> >>>> I?d like to propose a row of smaller fixes where code is noted >>>> down a >>>> bit questionable. >>>> SAP?s quality process requires that we fix these in our >>>> internal delivery, >>>> and I >>>> Would like to share my fixes with openJdk. Some of these fixes >>>> are of >>>> more >>>> theoretical nature as how I understand the code paths never >>>> allow the >>>> problematic situation, but fixing it nevertheless assures that >>>> nothing is >>>> overseen if the code changes. Most changes are in libawt_xawt, >>>> some >>>> are in libsunec. >>>> >>>> I?d appreciate a review: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>> >>>> Changes in detail: >>>> >>>> awt_InputMethod.c: >>>> >>>> One might overrun the 100 byte fixed-size string >>>> statusWindow->status >>>> by copying text->string.multi_byte without checking the length. >>>> >>>> gtk3_interface.c: >>>> >>>> This less-than-zero comparison of an unsigned value is never true. >>>> >>>> Using uninitialized value color. Field color.alpha is >>>> uninitialized. >>>> E.g. used at gtk3_interface.c:2287. >>>> >>>> XToolkit.c >>>> >>>> Using uninitialized value ret_timeout. >>>> E.g. in XToolkit.c:6809. >>>> >>>> XWindow.c >>>> >>>> Argument is incompatible with corresponding format string >>>> conversion. >>>> >>>> splashscreen_sys.c >>>> >>>> Overflowed or truncated value (or a value computed from an >>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>> (double)gdk_scale : native_scale used as return value. >>>> >>>> ec.c >>>> >>>> Using uninitialized value k.dp when calling mp_clear. >>>> >>>> ecdecode.c >>>> >>>> You might overrun the 291 byte fixed-size string genenc by copying >>>> curveParams->geny without checking the length. >>>> Added sanity check before doing the string concatenation. >>>> >>>> ecl_mult.c >>>> >>>> Using uninitialized value kt.flag when calling >>>> *group->point_mul. (The >>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>> >>>> mpi.c >>>> >>>> Using uninitialized value s. Field s.flag is uninitialized when >>>> calling >>>> s_mp_exch. >>>> Using uninitialized value tmp. Field tmp.flag is uninitialized >>>> when >>>> calling s_mp_exch >>>> Using uninitialized value t.dp when calling mp_clear. >>>> >>>> p11_mutex.c >>>> >>>> Using uninitialized value *ckpInitArgs. Field >>>> ckpInitArgs->flags is >>>> uninitialized when calling memcpy. >>>> >>>> >>>> DataBufferNative.c >>>> >>>> Using uninitialized value lockInfo.rasBase when calling >>>> BN_GetPixelPointer. >>>> >>>> fontpath.c >>>> >>>> You might overrun the 512 byte fixed-size string fontDirPath by >>>> copying >>>> DirP->name[index] without checking the length. >>>> >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From semyon.sadetsky at oracle.com Thu Dec 1 07:44:40 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Thu, 1 Dec 2016 10:44:40 +0300 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: yes, this is a potential issue. But actually cases MID,FOCUS,BLACK,WHITE are never used. But the fix is wrong. It should be color.alpha = 1; --Semyon On 01.12.2016 08:05, Prasanta Sadhukhan wrote: > > Also, in gtk3_interface.c, there is this change for color.alpha > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > but it is used in > gtk3_get_color_for_state() where it is not initialized > > 2268 GdkRGBA color; > Regards > Prasanta > On 12/1/2016 1:28 AM, Phil Race wrote: >> Hi Goetz, >> >>> DataBufferNative.c >>> Using uninitialized value lockInfo.rasBase when calling >>> DBN_GetPixelPointer. >> >> 75 lockInfo.resBase = NULL; >> >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". >> >> And strictly there is no problem since inside DBN_GetPixelPointer >> the code calls ops->Lock which should initialise this. >> A "rasBase" of 0 isn't really any better than a random one .. >> >> Also I don't see why there's a problem here and not in >> the function immediately following since it is the exact same case. >> >> -phil. >> >> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >>> cc 2d-dev. >>> >>> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>>> Hi Vincent, >>>> >>>> thanks for the quit review! >>>> Good catch that I lost the change to p11_mutex.c ... I had to change >>>> it and it fell out of my patches. >>>> I edited the Last Modified Date, and also updated the copyright >>>> messages. >>>> New webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> (Am I correct that your openJdk name is Vinnie?) >>>> >>>>> -----Original Message----- >>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>>> Sent: Mittwoch, 30. November 2016 14:53 >>>>> To: Lindenmaier, Goetz >>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>>> >>>>> Hello Goetz, >>>>> >>>>> Please modify the bug summary to reference ECC too. >>>>> Your ECC changes look fine but the ?Last Modified Date? line in >>>>> the 4 source >>>>> code headers will need to be updated/added. >>>>> >>>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>>> webrev. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>>> > >>>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?d like to propose a row of smaller fixes where code is noted >>>>> down a >>>>> bit questionable. >>>>> SAP?s quality process requires that we fix these in our >>>>> internal delivery, >>>>> and I >>>>> Would like to share my fixes with openJdk. Some of these >>>>> fixes are of >>>>> more >>>>> theoretical nature as how I understand the code paths never >>>>> allow the >>>>> problematic situation, but fixing it nevertheless assures that >>>>> nothing is >>>>> overseen if the code changes. Most changes are in >>>>> libawt_xawt, some >>>>> are in libsunec. >>>>> >>>>> I?d appreciate a review: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>>> >>>>> Changes in detail: >>>>> >>>>> awt_InputMethod.c: >>>>> >>>>> One might overrun the 100 byte fixed-size string >>>>> statusWindow->status >>>>> by copying text->string.multi_byte without checking the length. >>>>> >>>>> gtk3_interface.c: >>>>> >>>>> This less-than-zero comparison of an unsigned value is never >>>>> true. >>>>> >>>>> Using uninitialized value color. Field color.alpha is >>>>> uninitialized. >>>>> E.g. used at gtk3_interface.c:2287. >>>>> >>>>> XToolkit.c >>>>> >>>>> Using uninitialized value ret_timeout. >>>>> E.g. in XToolkit.c:6809. >>>>> >>>>> XWindow.c >>>>> >>>>> Argument is incompatible with corresponding format string >>>>> conversion. >>>>> >>>>> splashscreen_sys.c >>>>> >>>>> Overflowed or truncated value (or a value computed from an >>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>>> (double)gdk_scale : native_scale used as return value. >>>>> >>>>> ec.c >>>>> >>>>> Using uninitialized value k.dp when calling mp_clear. >>>>> >>>>> ecdecode.c >>>>> >>>>> You might overrun the 291 byte fixed-size string genenc by >>>>> copying >>>>> curveParams->geny without checking the length. >>>>> Added sanity check before doing the string concatenation. >>>>> >>>>> ecl_mult.c >>>>> >>>>> Using uninitialized value kt.flag when calling >>>>> *group->point_mul. (The >>>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>>> >>>>> mpi.c >>>>> >>>>> Using uninitialized value s. Field s.flag is uninitialized >>>>> when calling >>>>> s_mp_exch. >>>>> Using uninitialized value tmp. Field tmp.flag is uninitialized >>>>> when >>>>> calling s_mp_exch >>>>> Using uninitialized value t.dp when calling mp_clear. >>>>> >>>>> p11_mutex.c >>>>> >>>>> Using uninitialized value *ckpInitArgs. Field >>>>> ckpInitArgs->flags is >>>>> uninitialized when calling memcpy. >>>>> >>>>> >>>>> DataBufferNative.c >>>>> >>>>> Using uninitialized value lockInfo.rasBase when calling >>>>> BN_GetPixelPointer. >>>>> >>>>> fontpath.c >>>>> >>>>> You might overrun the 512 byte fixed-size string fontDirPath >>>>> by copying >>>>> DirP->name[index] without checking the length. >>>>> >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Thu Dec 1 08:29:57 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 08:29:57 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap> References:

<9e524d4b03a14198a54c2af271c5d9eb@DEWDFE13DE03.global.corp.sap> Message-ID: <792ae9be83a0424bbfec6bff1be5a9be@DEROTE13DE08.global.corp.sap> Hi Christoph, I changed the code in fontpath.c to use snprintf, that seems much better as the concatenated string is a literal anyways. Also, I fixed the spaces. I'll post a new webrev once I'm through all the reviews. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Mittwoch, 30. November 2016 20:47 > To: Lindenmaier, Goetz > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net; 2d- > dev at openjdk.java.net; Vincent Ryan > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding > > Hi Goetz, > > I have some small remarks. > > src/java.desktop/unix/native/common/awt/fontpath.c: > > 247 fontDirPath[sizeof(fontDirPath)-1] = '\0'; > -> you should add spaces left and right of '-' > 248 strncat(fontDirPath, "/fonts.dir", sizeof(fontDirPath) - > strlen(fontDirPath)); > -> I think you need to subtract 1 from the 3rd parameter of strncat ('size_t n') > because man page says: > "If src contains n or more bytes, strncat() writes n+1 bytes to dest (n from src > plus the terminating null byte). Therefore, the size of dest must be at least > strlen(dest)+n+1." > > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c: > > add spaces around '-' in the array index > > The rest looks fine to me. > > Best regards > Christoph > > > -----Original Message----- > > From: security-dev [mailto:security-dev-bounces at openjdk.java.net] On > Behalf > > Of Lindenmaier, Goetz > > Sent: Mittwoch, 30. November 2016 16:41 > > To: Vincent Ryan > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > > Subject: RE: RFR(M): 8170525: Fix minor issues in awt coding > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I had to change > > it and it fell out of my patches. > > I edited the Last Modified Date, and also updated the copyright messages. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > > > > -----Original Message----- > > > From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > > > Sent: Mittwoch, 30. November 2016 14:53 > > > To: Lindenmaier, Goetz > > > Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > > > Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > > > > > > Hello Goetz, > > > > > > Please modify the bug summary to reference ECC too. > > > Your ECC changes look fine but the ?Last Modified Date? line in the 4 source > > > code headers will need to be updated/added. > > > > > > BTW p11_mutex.c is listed below but appears to be missing from the > webrev. > > > > > > Thanks. > > > > > > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > > > > > wrote: > > > > > > Hi, > > > > > > I?d like to propose a row of smaller fixes where code is noted down a > > > bit questionable. > > > SAP?s quality process requires that we fix these in our internal delivery, > > > and I > > > Would like to share my fixes with openJdk. Some of these fixes are of > > > more > > > theoretical nature as how I understand the code paths never allow the > > > problematic situation, but fixing it nevertheless assures that nothing is > > > overseen if the code changes. Most changes are in libawt_xawt, some > > > are in libsunec. > > > > > > I?d appreciate a review: > > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > > > Changes in detail: > > > > > > awt_InputMethod.c: > > > > > > One might overrun the 100 byte fixed-size string statusWindow->status > > > by copying text->string.multi_byte without checking the length. > > > > > > gtk3_interface.c: > > > > > > This less-than-zero comparison of an unsigned value is never true. > > > > > > Using uninitialized value color. Field color.alpha is uninitialized. > > > E.g. used at gtk3_interface.c:2287. > > > > > > XToolkit.c > > > > > > Using uninitialized value ret_timeout. > > > E.g. in XToolkit.c:6809. > > > > > > XWindow.c > > > > > > Argument is incompatible with corresponding format string conversion. > > > > > > splashscreen_sys.c > > > > > > Overflowed or truncated value (or a value computed from an > > > overflowed or truncated value) (gdk_scale > 0) ? native_scale * > > > (double)gdk_scale : native_scale used as return value. > > > > > > ec.c > > > > > > Using uninitialized value k.dp when calling mp_clear. > > > > > > ecdecode.c > > > > > > You might overrun the 291 byte fixed-size string genenc by copying > > > curveParams->geny without checking the length. > > > Added sanity check before doing the string concatenation. > > > > > > ecl_mult.c > > > > > > Using uninitialized value kt.flag when calling *group->point_mul. (The > > > function pointer resolves to ec_GF2m_pt_mul_mont.) > > > > > > mpi.c > > > > > > Using uninitialized value s. Field s.flag is uninitialized when calling > > > s_mp_exch. > > > Using uninitialized value tmp. Field tmp.flag is uninitialized when > > > calling s_mp_exch > > > Using uninitialized value t.dp when calling mp_clear. > > > > > > p11_mutex.c > > > > > > Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > > > uninitialized when calling memcpy. > > > > > > > > > DataBufferNative.c > > > > > > Using uninitialized value lockInfo.rasBase when calling > > > BN_GetPixelPointer. > > > > > > fontpath.c > > > > > > You might overrun the 512 byte fixed-size string fontDirPath by copying > > > DirP->name[index] without checking the length. > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:03:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:03:07 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> Message-ID: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> Hi Phil, > Did you actually compile this ? The variable is called "rasBase", not > "resBase". Yes, I compiled it, and I fixed the error, but that was another repo I use for the coverity checks. Somehow it did not find its way into the webrev. I don't see where ops->Lock() initializes this field. ops->GetRasInfo(env, ops, lockInfo); does so if it resolves to BufImg_GetRasInfo(). I can't look in our code scan results because the issue is gone after fixing it, that lists the path of execution that leads to the issue. If you are sure this is correct I will remove the initialization, else I will also put it into the other method. DBN_GetPixelPointer checks lockInfo->rasBase for NULL and does what looks like the error case if it's NULL. Therefore NULL seemed a good initialization to me. Best regards, Goetz. > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Mittwoch, 30. November 2016 20:59 > To: Sergey Bylokhov ; Lindenmaier, Goetz > ; Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Hi Goetz, > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer. > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > cc 2d-dev. > > > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > >> Hi Vincent, > >> > >> thanks for the quit review! > >> Good catch that I lost the change to p11_mutex.c ... I had to change > >> it and it fell out of my patches. > >> I edited the Last Modified Date, and also updated the copyright > >> messages. > >> New webrev: > >> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > >> > >> Best regards, > >> Goetz. > >> > >> (Am I correct that your openJdk name is Vinnie?) > >> > >>> -----Original Message----- > >>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > >>> Sent: Mittwoch, 30. November 2016 14:53 > >>> To: Lindenmaier, Goetz > >>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net > >>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > >>> > >>> Hello Goetz, > >>> > >>> Please modify the bug summary to reference ECC too. > >>> Your ECC changes look fine but the ?Last Modified Date? line in the > >>> 4 source > >>> code headers will need to be updated/added. > >>> > >>> BTW p11_mutex.c is listed below but appears to be missing from the > >>> webrev. > >>> > >>> Thanks. > >>> > >>> > >>> > >>> > >>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > >>> > > wrote: > >>> > >>> Hi, > >>> > >>> I?d like to propose a row of smaller fixes where code is noted > >>> down a > >>> bit questionable. > >>> SAP?s quality process requires that we fix these in our internal > >>> delivery, > >>> and I > >>> Would like to share my fixes with openJdk. Some of these fixes > >>> are of > >>> more > >>> theoretical nature as how I understand the code paths never > >>> allow the > >>> problematic situation, but fixing it nevertheless assures that > >>> nothing is > >>> overseen if the code changes. Most changes are in libawt_xawt, > >>> some > >>> are in libsunec. > >>> > >>> I?d appreciate a review: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > >>> > >>> Changes in detail: > >>> > >>> awt_InputMethod.c: > >>> > >>> One might overrun the 100 byte fixed-size string > >>> statusWindow->status > >>> by copying text->string.multi_byte without checking the length. > >>> > >>> gtk3_interface.c: > >>> > >>> This less-than-zero comparison of an unsigned value is never true. > >>> > >>> Using uninitialized value color. Field color.alpha is > >>> uninitialized. > >>> E.g. used at gtk3_interface.c:2287. > >>> > >>> XToolkit.c > >>> > >>> Using uninitialized value ret_timeout. > >>> E.g. in XToolkit.c:6809. > >>> > >>> XWindow.c > >>> > >>> Argument is incompatible with corresponding format string > >>> conversion. > >>> > >>> splashscreen_sys.c > >>> > >>> Overflowed or truncated value (or a value computed from an > >>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * > >>> (double)gdk_scale : native_scale used as return value. > >>> > >>> ec.c > >>> > >>> Using uninitialized value k.dp when calling mp_clear. > >>> > >>> ecdecode.c > >>> > >>> You might overrun the 291 byte fixed-size string genenc by copying > >>> curveParams->geny without checking the length. > >>> Added sanity check before doing the string concatenation. > >>> > >>> ecl_mult.c > >>> > >>> Using uninitialized value kt.flag when calling > >>> *group->point_mul. (The > >>> function pointer resolves to ec_GF2m_pt_mul_mont.) > >>> > >>> mpi.c > >>> > >>> Using uninitialized value s. Field s.flag is uninitialized when > >>> calling > >>> s_mp_exch. > >>> Using uninitialized value tmp. Field tmp.flag is uninitialized when > >>> calling s_mp_exch > >>> Using uninitialized value t.dp when calling mp_clear. > >>> > >>> p11_mutex.c > >>> > >>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is > >>> uninitialized when calling memcpy. > >>> > >>> > >>> DataBufferNative.c > >>> > >>> Using uninitialized value lockInfo.rasBase when calling > >>> BN_GetPixelPointer. > >>> > >>> fontpath.c > >>> > >>> You might overrun the 512 byte fixed-size string fontDirPath by > >>> copying > >>> DirP->name[index] without checking the length. > >>> > >> > > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:10:15 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:10:15 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: Hi Prasanta, good point, I added that too. Best regards, Goetz. > -----Original Message----- > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] > Sent: Donnerstag, 1. Dezember 2016 06:05 > To: Phil Race ; Sergey Bylokhov > ; Lindenmaier, Goetz > ; Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Also, in gtk3_interface.c, there is this change for color.alpha > > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > but it is used in > gtk3_get_color_for_state() where it is not initialized > > 2268 GdkRGBA color; > Regards > Prasanta > > On 12/1/2016 1:28 AM, Phil Race wrote: > > > Hi Goetz, > > > > DataBufferNative.c > Using uninitialized value lockInfo.rasBase when calling > DBN_GetPixelPointer. > > > > 75 lockInfo.resBase = NULL; > > Did you actually compile this ? The variable is called "rasBase", not > "resBase". > > And strictly there is no problem since inside DBN_GetPixelPointer > the code calls ops->Lock which should initialise this. > A "rasBase" of 0 isn't really any better than a random one .. > > Also I don't see why there's a problem here and not in > the function immediately following since it is the exact same case. > > -phil. > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > > cc 2d-dev. > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > > > Hi Vincent, > > thanks for the quit review! > Good catch that I lost the change to p11_mutex.c ... I > had to change > it and it fell out of my patches. > I edited the Last Modified Date, and also updated the > copyright messages. > New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > dev/ > > Best regards, > Goetz. > > (Am I correct that your openJdk name is Vinnie?) > > > > -----Original Message----- > From: Vincent Ryan > [mailto:vincent.x.ryan at oracle.com] > Sent: Mittwoch, 30. November 2016 14:53 > To: Lindenmaier, Goetz > > Cc: awt-dev at openjdk.java.net dev at openjdk.java.net> ; security-dev at openjdk.java.net dev at openjdk.java.net> > Subject: Re: RFR(M): 8170525: Fix minor issues > in awt coding > > Hello Goetz, > > Please modify the bug summary to reference > ECC too. > Your ECC changes look fine but the ?Last > Modified Date? line in the 4 source > code headers will need to be updated/added. > > BTW p11_mutex.c is listed below but appears > to be missing from the webrev. > > Thanks. > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, > Goetz > > > wrote: > > Hi, > > I?d like to propose a row of smaller fixes > where code is noted down a > bit questionable. > SAP?s quality process requires that we fix > these in our internal delivery, > and I > Would like to share my fixes with openJdk. > Some of these fixes are of > more > theoretical nature as how I understand the > code paths never allow the > problematic situation, but fixing it > nevertheless assures that nothing is > overseen if the code changes. Most changes > are in libawt_xawt, some > are in libsunec. > > I?d appreciate a review: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > Changes in detail: > > awt_InputMethod.c: > > One might overrun the 100 byte fixed-size > string statusWindow->status > by copying text->string.multi_byte without > checking the length. > > gtk3_interface.c: > > This less-than-zero comparison of an > unsigned value is never true. > > Using uninitialized value color. Field > color.alpha is uninitialized. > E.g. used at gtk3_interface.c:2287. > > XToolkit.c > > Using uninitialized value ret_timeout. > E.g. in XToolkit.c:6809. > > XWindow.c > > Argument is incompatible with > corresponding format string conversion. > > splashscreen_sys.c > > Overflowed or truncated value (or a value > computed from an > overflowed or truncated value) (gdk_scale > 0) > ? native_scale * > (double)gdk_scale : native_scale used as return > value. > > ec.c > > Using uninitialized value k.dp when calling > mp_clear. > > ecdecode.c > > You might overrun the 291 byte fixed-size > string genenc by copying > curveParams->geny without checking the > length. > Added sanity check before doing the string > concatenation. > > ecl_mult.c > > Using uninitialized value kt.flag when calling > *group->point_mul. (The > function pointer resolves to > ec_GF2m_pt_mul_mont.) > > mpi.c > > Using uninitialized value s. Field s.flag is > uninitialized when calling > s_mp_exch. > Using uninitialized value tmp. Field tmp.flag > is uninitialized when > calling s_mp_exch > Using uninitialized value t.dp when calling > mp_clear. > > p11_mutex.c > > Using uninitialized value *ckpInitArgs. Field > ckpInitArgs->flags is > uninitialized when calling memcpy. > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase > when calling > BN_GetPixelPointer. > > fontpath.c > > You might overrun the 512 byte fixed-size > string fontDirPath by copying > DirP->name[index] without checking the length. > > > > > > > From goetz.lindenmaier at sap.com Thu Dec 1 11:13:26 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 1 Dec 2016 11:13:26 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <9d1c3710-7adb-4bb9-26f3-6e13d67b81f5@oracle.com> Message-ID: Ah, no, that is just the field that is initialized with the Result of gtk3_get_color_for_flags() why I need to initialize it there. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 1. Dezember 2016 12:10 > To: 'Prasanta Sadhukhan' ; Phil Race > ; Sergey Bylokhov ; > Vincent Ryan > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues > in awt coding > > Hi Prasanta, > > good point, I added that too. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Prasanta Sadhukhan [mailto:prasanta.sadhukhan at oracle.com] > > Sent: Donnerstag, 1. Dezember 2016 06:05 > > To: Phil Race ; Sergey Bylokhov > > ; Lindenmaier, Goetz > > ; Vincent Ryan > > Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- > > dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor > issues > > in awt coding > > > > Also, in gtk3_interface.c, there is this change for color.alpha > > > > > > 2219 color.alpha = 0; in gtk3_get_color_for_flags() > > but it is used in > > gtk3_get_color_for_state() where it is not initialized > > > > 2268 GdkRGBA color; > > Regards > > Prasanta > > > > On 12/1/2016 1:28 AM, Phil Race wrote: > > > > > > Hi Goetz, > > > > > > > > DataBufferNative.c > > Using uninitialized value lockInfo.rasBase when calling > > DBN_GetPixelPointer. > > > > > > > > 75 lockInfo.resBase = NULL; > > > > Did you actually compile this ? The variable is called "rasBase", not > > "resBase". > > > > And strictly there is no problem since inside DBN_GetPixelPointer > > the code calls ops->Lock which should initialise this. > > A "rasBase" of 0 isn't really any better than a random one .. > > > > Also I don't see why there's a problem here and not in > > the function immediately following since it is the exact same case. > > > > -phil. > > > > On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > > > > > > cc 2d-dev. > > > > On 30.11.16 18:41, Lindenmaier, Goetz wrote: > > > > > > Hi Vincent, > > > > thanks for the quit review! > > Good catch that I lost the change to p11_mutex.c ... I > > had to change > > it and it fell out of my patches. > > I edited the Last Modified Date, and also updated the > > copyright messages. > > New webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > > dev/ > > > > Best regards, > > Goetz. > > > > (Am I correct that your openJdk name is Vinnie?) > > > > > > > > -----Original Message----- > > From: Vincent Ryan > > [mailto:vincent.x.ryan at oracle.com] > > Sent: Mittwoch, 30. November 2016 14:53 > > To: Lindenmaier, Goetz > > > > Cc: awt-dev at openjdk.java.net > dev at openjdk.java.net> ; security-dev at openjdk.java.net > dev at openjdk.java.net> > > Subject: Re: RFR(M): 8170525: Fix minor issues > > in awt coding > > > > Hello Goetz, > > > > Please modify the bug summary to reference > > ECC too. > > Your ECC changes look fine but the ?Last > > Modified Date? line in the 4 source > > code headers will need to be updated/added. > > > > BTW p11_mutex.c is listed below but appears > > to be missing from the webrev. > > > > Thanks. > > > > > > > > > > On 30 Nov 2016, at 13:12, Lindenmaier, > > Goetz > > > > > > wrote: > > > > Hi, > > > > I?d like to propose a row of smaller fixes > > where code is noted down a > > bit questionable. > > SAP?s quality process requires that we fix > > these in our internal delivery, > > and I > > Would like to share my fixes with openJdk. > > Some of these fixes are of > > more > > theoretical nature as how I understand the > > code paths never allow the > > problematic situation, but fixing it > > nevertheless assures that nothing is > > overseen if the code changes. Most changes > > are in libawt_xawt, some > > are in libsunec. > > > > I?d appreciate a review: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ > > > > Changes in detail: > > > > awt_InputMethod.c: > > > > One might overrun the 100 byte fixed-size > > string statusWindow->status > > by copying text->string.multi_byte without > > checking the length. > > > > gtk3_interface.c: > > > > This less-than-zero comparison of an > > unsigned value is never true. > > > > Using uninitialized value color. Field > > color.alpha is uninitialized. > > E.g. used at gtk3_interface.c:2287. > > > > XToolkit.c > > > > Using uninitialized value ret_timeout. > > E.g. in XToolkit.c:6809. > > > > XWindow.c > > > > Argument is incompatible with > > corresponding format string conversion. > > > > splashscreen_sys.c > > > > Overflowed or truncated value (or a value > > computed from an > > overflowed or truncated value) (gdk_scale > 0) > > ? native_scale * > > (double)gdk_scale : native_scale used as return > > value. > > > > ec.c > > > > Using uninitialized value k.dp when calling > > mp_clear. > > > > ecdecode.c > > > > You might overrun the 291 byte fixed-size > > string genenc by copying > > curveParams->geny without checking the > > length. > > Added sanity check before doing the string > > concatenation. > > > > ecl_mult.c > > > > Using uninitialized value kt.flag when calling > > *group->point_mul. (The > > function pointer resolves to > > ec_GF2m_pt_mul_mont.) > > > > mpi.c > > > > Using uninitialized value s. Field s.flag is > > uninitialized when calling > > s_mp_exch. > > Using uninitialized value tmp. Field tmp.flag > > is uninitialized when > > calling s_mp_exch > > Using uninitialized value t.dp when calling > > mp_clear. > > > > p11_mutex.c > > > > Using uninitialized value *ckpInitArgs. Field > > ckpInitArgs->flags is > > uninitialized when calling memcpy. > > > > > > DataBufferNative.c > > > > Using uninitialized value lockInfo.rasBase > > when calling > > BN_GetPixelPointer. > > > > fontpath.c > > > > You might overrun the 512 byte fixed-size > > string fontDirPath by copying > > DirP->name[index] without checking the length. > > > > > > > > > > > > > > From philip.race at oracle.com Thu Dec 1 21:30:58 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 1 Dec 2016 13:30:58 -0800 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> Message-ID: <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com> Sorry. it is ops->GetRasInfo(env, ops, lockInfo); that initialises it .. That is still before the dereference Anyway, what was the reason for updating one function, but not the other. I don't mind the change, but the inconsistency looks odd. -phil. On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote: > Hi Phil, > >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". > Yes, I compiled it, and I fixed the error, but that was another repo > I use for the coverity checks. Somehow it did not find its way into > the webrev. > > I don't see where ops->Lock() initializes this field. > ops->GetRasInfo(env, ops, lockInfo); does so if it resolves > to BufImg_GetRasInfo(). I can't look in our code scan results > because the issue is gone after fixing it, that lists the path > of execution that leads to the issue. > If you are sure this is correct I will remove the initialization, > else I will also put it into the other method. > > DBN_GetPixelPointer checks lockInfo->rasBase for NULL and > does what looks like the error case if it's NULL. Therefore NULL > seemed a good initialization to me. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Phil Race [mailto:philip.race at oracle.com] >> Sent: Mittwoch, 30. November 2016 20:59 >> To: Sergey Bylokhov ; Lindenmaier, Goetz >> ; Vincent Ryan >> Cc: awt-dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net>; security- >> dev at openjdk.java.net >> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues >> in awt coding >> >> Hi Goetz, >> >>> DataBufferNative.c >>> Using uninitialized value lockInfo.rasBase when calling DBN_GetPixelPointer. >> 75 lockInfo.resBase = NULL; >> >> Did you actually compile this ? The variable is called "rasBase", not >> "resBase". >> >> And strictly there is no problem since inside DBN_GetPixelPointer >> the code calls ops->Lock which should initialise this. >> A "rasBase" of 0 isn't really any better than a random one .. >> >> Also I don't see why there's a problem here and not in >> the function immediately following since it is the exact same case. >> >> -phil. >> >> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: >>> cc 2d-dev. >>> >>> On 30.11.16 18:41, Lindenmaier, Goetz wrote: >>>> Hi Vincent, >>>> >>>> thanks for the quit review! >>>> Good catch that I lost the change to p11_mutex.c ... I had to change >>>> it and it fell out of my patches. >>>> I edited the Last Modified Date, and also updated the copyright >>>> messages. >>>> New webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ >>>> >>>> Best regards, >>>> Goetz. >>>> >>>> (Am I correct that your openJdk name is Vinnie?) >>>> >>>>> -----Original Message----- >>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] >>>>> Sent: Mittwoch, 30. November 2016 14:53 >>>>> To: Lindenmaier, Goetz >>>>> Cc: awt-dev at openjdk.java.net; security-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding >>>>> >>>>> Hello Goetz, >>>>> >>>>> Please modify the bug summary to reference ECC too. >>>>> Your ECC changes look fine but the ?Last Modified Date? line in the >>>>> 4 source >>>>> code headers will need to be updated/added. >>>>> >>>>> BTW p11_mutex.c is listed below but appears to be missing from the >>>>> webrev. >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> >>>>> >>>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz >>>>> > >> wrote: >>>>> Hi, >>>>> >>>>> I?d like to propose a row of smaller fixes where code is noted >>>>> down a >>>>> bit questionable. >>>>> SAP?s quality process requires that we fix these in our internal >>>>> delivery, >>>>> and I >>>>> Would like to share my fixes with openJdk. Some of these fixes >>>>> are of >>>>> more >>>>> theoretical nature as how I understand the code paths never >>>>> allow the >>>>> problematic situation, but fixing it nevertheless assures that >>>>> nothing is >>>>> overseen if the code changes. Most changes are in libawt_xawt, >>>>> some >>>>> are in libsunec. >>>>> >>>>> I?d appreciate a review: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt/webrev.01/ >>>>> >>>>> Changes in detail: >>>>> >>>>> awt_InputMethod.c: >>>>> >>>>> One might overrun the 100 byte fixed-size string >>>>> statusWindow->status >>>>> by copying text->string.multi_byte without checking the length. >>>>> >>>>> gtk3_interface.c: >>>>> >>>>> This less-than-zero comparison of an unsigned value is never true. >>>>> >>>>> Using uninitialized value color. Field color.alpha is >>>>> uninitialized. >>>>> E.g. used at gtk3_interface.c:2287. >>>>> >>>>> XToolkit.c >>>>> >>>>> Using uninitialized value ret_timeout. >>>>> E.g. in XToolkit.c:6809. >>>>> >>>>> XWindow.c >>>>> >>>>> Argument is incompatible with corresponding format string >>>>> conversion. >>>>> >>>>> splashscreen_sys.c >>>>> >>>>> Overflowed or truncated value (or a value computed from an >>>>> overflowed or truncated value) (gdk_scale > 0) ? native_scale * >>>>> (double)gdk_scale : native_scale used as return value. >>>>> >>>>> ec.c >>>>> >>>>> Using uninitialized value k.dp when calling mp_clear. >>>>> >>>>> ecdecode.c >>>>> >>>>> You might overrun the 291 byte fixed-size string genenc by copying >>>>> curveParams->geny without checking the length. >>>>> Added sanity check before doing the string concatenation. >>>>> >>>>> ecl_mult.c >>>>> >>>>> Using uninitialized value kt.flag when calling >>>>> *group->point_mul. (The >>>>> function pointer resolves to ec_GF2m_pt_mul_mont.) >>>>> >>>>> mpi.c >>>>> >>>>> Using uninitialized value s. Field s.flag is uninitialized when >>>>> calling >>>>> s_mp_exch. >>>>> Using uninitialized value tmp. Field tmp.flag is uninitialized when >>>>> calling s_mp_exch >>>>> Using uninitialized value t.dp when calling mp_clear. >>>>> >>>>> p11_mutex.c >>>>> >>>>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs->flags is >>>>> uninitialized when calling memcpy. >>>>> >>>>> >>>>> DataBufferNative.c >>>>> >>>>> Using uninitialized value lockInfo.rasBase when calling >>>>> BN_GetPixelPointer. >>>>> >>>>> fontpath.c >>>>> >>>>> You might overrun the 512 byte fixed-size string fontDirPath by >>>>> copying >>>>> DirP->name[index] without checking the length. >>>>> >>> From goetz.lindenmaier at sap.com Fri Dec 2 07:58:56 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Dec 2016 07:58:56 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com> References:

<5835BDC5.2080108@oracle.com> Message-ID: Continuing from thread [1]. Pursuant to comments from the CCC, the patch [2] has been updated. The changes with respect to the previous version of the patch [3] are to clarify the specification of TIFFField(TIFFTag,long) in terms of the constructor?s description and the exceptions it throws, and to add an exception for the case of value >= 4294967296, i.e., above the range of a 32-bit unsigned int. Once this patch is approved the CCC request may be updated. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007963.html [2] http://cr.openjdk.java.net/~bpb/8169725/webrev.01/ [3] http://cr.openjdk.java.net/~bpb/8169725/webrev.00/ On Nov 23, 2016, at 8:03 AM, Philip Race wrote: > +1 > > -phil From brian.burkhalter at oracle.com Tue Dec 6 22:03:49 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 6 Dec 2016 14:03:49 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG Message-ID: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8169728 Patch: http://cr.openjdk.java.net/~bpb/8169728/webrev.00/ To the primary constructor TIFFField(TIFFTag,int,int,Object), add some range checks for TIFF_LONG, TIFF_RATIONAL, and TIFF_IFD_POINTER, and some array size checks for TIFF_RATIONAL and TIFF_SRATIONAL. Does the new IllegalArgumentException case warrant a CCC review? Thanks, Brian From goetz.lindenmaier at sap.com Wed Dec 7 07:20:29 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 07:20:29 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor issues in awt coding In-Reply-To: <58462E8A.6090508@oracle.com> References:

<32226de1-891b-11de-0aa8-58feb9315ef2@oracle.com> <0b89193d-598d-77b0-4c92-0f19b4cea68f@oracle.com> <3857cdca6b17466c866df80f1eb39f55@DEROTE13DE08.global.corp.sap> <65c24a90-7b7a-28c7-d93d-ab365a0b7407@oracle.com> <81c850d0b7034889ab1e38a217313658@DEROTE13DE08.global.corp.sap> <2760159c815240ebaaf8743a4f899d29@DEROTE13DE08.global.corp.sap> <23a39908-37a6-aa9a-f78f-8f60144cdc02@oracle.com> <96c15a8dff544fcdb9dd7f86af83523c@DEROTE13DE08.global.corp.sap> <58462E8A.6090508@oracle.com> Message-ID: <5eeefc4e0a4140b7b9fd02ca0b2a44d4@DEROTE13DE08.global.corp.sap> Hi Phil, does that mean I can push the change, or will this happen through jprt? Best regards, Goetz. > -----Original Message----- > From: Philip Race [mailto:philip.race at oracle.com] > Sent: Tuesday, December 06, 2016 4:21 AM > To: Lindenmaier, Goetz > Cc: Sergey Bylokhov ; awt- > dev at openjdk.java.net; 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor > issues in awt coding > > I didn't eyeball what you changed but JPRT is now happy. > The build passes on all platforms... > > -phil. > > On 12/5/16, 2:47 PM, Lindenmaier, Goetz wrote: > > Hi Phil, > > > > sorry for that! I fixed it, there is an other occurrence, too. > > I double checked all the casts, there was also a mp_flags<-> mp_sign > wrong in mpi.c > > http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/webrev.05/ > > (Also rebased the change) > > > > Best regards, > > Goetz > > > >> -----Original Message----- > >> From: Phil Race [mailto:philip.race at oracle.com] > >> Sent: Monday, December 05, 2016 7:26 PM > >> To: Lindenmaier, Goetz; Sergey Bylokhov > >> > >> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net> > >> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor > >> issues in awt coding > >> > >> I tried it .. and just as well I did. It fails in the crypto code on Mac. > >> > >> jdk/src/jdk.crypto.ec/share/native/libsunec/impl/ec.c:261:12: error: > >> expression which evaluates to zero treated as a null pointer constant of > type > >> 'mp_digit *' (aka 'unsigned long *') [-Werror,-Wnon-literal-null-conversion] > >> k.dp = (mp_digit)0; > >> ^~~~~~~~~~~ > >> 1 error generated. > >> > >> -phil. > >> > >> > >> > >> On 12/3/2016 9:53 AM, Lindenmaier, Goetz wrote: > >>> Hi Phil, > >>> > >>> that would be great, unfortunately I don't have access to JPRT. > >>> > >>> Thanks, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: Phil Race [mailto:philip.race at oracle.com] > >>>> Sent: Friday, December 02, 2016 8:46 PM > >>>> To: Lindenmaier, Goetz; Sergey > Bylokhov > >>>> > >>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net> > >>>> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix minor > >>>> issues in awt coding > >>>> > >>>> I had no other comments, except that it would be good to be sure > >>>> that this builds on all relevant platforms .. using the 'blessed' compilers. > >>>> If you like I can submit a JPRT job for you based on this patch. > >>>> > >>>> -phil. > >>>> > >>>> On 12/01/2016 11:58 PM, Lindenmaier, Goetz wrote: > >>>>> Hi Phil, > >>>>> > >>>>> I added the initialization to the other function. > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt- > dev/webrev.04/ > >>>>> > >>>>> I missed that because Coverity didn't complain. > >>>>> It's not a perfect tool, but it finds sufficient issues > >>>>> to make it worthwhile. Is the other awt code fine? > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Phil Race [mailto:philip.race at oracle.com] > >>>>>> Sent: Donnerstag, 1. Dezember 2016 22:31 > >>>>>> To: Lindenmaier, Goetz; Sergey > >> Bylokhov > >>>>>> ; Vincent Ryan > >>>> > >>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d-dev at openjdk.java.net>; > >>>> security- > >>>>>> dev at openjdk.java.net > >>>>>> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix > minor > >>>> issues > >>>>>> in awt coding > >>>>>> > >>>>>> Sorry. it is > >>>>>> ops->GetRasInfo(env, ops, lockInfo); > >>>>>> that initialises it .. > >>>>>> > >>>>>> > >>>>>> That is still before the dereference > >>>>>> Anyway, what was the reason for updating one function, but not the > >>>> other. > >>>>>> I don't mind the change, but the inconsistency looks odd. > >>>>>> > >>>>>> -phil. > >>>>>> > >>>>>> On 12/01/2016 03:03 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi Phil, > >>>>>>> > >>>>>>>> Did you actually compile this ? The variable is called "rasBase", not > >>>>>>>> "resBase". > >>>>>>> Yes, I compiled it, and I fixed the error, but that was another repo > >>>>>>> I use for the coverity checks. Somehow it did not find its way into > >>>>>>> the webrev. > >>>>>>> > >>>>>>> I don't see where ops->Lock() initializes this field. > >>>>>>> ops->GetRasInfo(env, ops, lockInfo); does so if it resolves > >>>>>>> to BufImg_GetRasInfo(). I can't look in our code scan results > >>>>>>> because the issue is gone after fixing it, that lists the path > >>>>>>> of execution that leads to the issue. > >>>>>>> If you are sure this is correct I will remove the initialization, > >>>>>>> else I will also put it into the other method. > >>>>>>> > >>>>>>> DBN_GetPixelPointer checks lockInfo->rasBase for NULL and > >>>>>>> does what looks like the error case if it's NULL. Therefore NULL > >>>>>>> seemed a good initialization to me. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Phil Race [mailto:philip.race at oracle.com] > >>>>>>>> Sent: Mittwoch, 30. November 2016 20:59 > >>>>>>>> To: Sergey Bylokhov; Lindenmaier, > >>>> Goetz > >>>>>>>> ; Vincent Ryan > >>>> > >>>>>>>> Cc: awt-dev at openjdk.java.net; 2d-dev<2d- > dev at openjdk.java.net>; > >>>> security- > >>>>>>>> dev at openjdk.java.net > >>>>>>>> Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170525: Fix > >> minor > >>>>>> issues > >>>>>>>> in awt coding > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>>> DataBufferNative.c > >>>>>>>>> Using uninitialized value lockInfo.rasBase when calling > >>>>>> DBN_GetPixelPointer. > >>>>>>>> 75 lockInfo.resBase = NULL; > >>>>>>>> > >>>>>>>> Did you actually compile this ? The variable is called "rasBase", not > >>>>>>>> "resBase". > >>>>>>>> > >>>>>>>> And strictly there is no problem since inside DBN_GetPixelPointer > >>>>>>>> the code calls ops->Lock which should initialise this. > >>>>>>>> A "rasBase" of 0 isn't really any better than a random one .. > >>>>>>>> > >>>>>>>> Also I don't see why there's a problem here and not in > >>>>>>>> the function immediately following since it is the exact same case. > >>>>>>>> > >>>>>>>> -phil. > >>>>>>>> > >>>>>>>> On 11/30/2016 10:00 AM, Sergey Bylokhov wrote: > >>>>>>>>> cc 2d-dev. > >>>>>>>>> > >>>>>>>>> On 30.11.16 18:41, Lindenmaier, Goetz wrote: > >>>>>>>>>> Hi Vincent, > >>>>>>>>>> > >>>>>>>>>> thanks for the quit review! > >>>>>>>>>> Good catch that I lost the change to p11_mutex.c ... I had to > >> change > >>>>>>>>>> it and it fell out of my patches. > >>>>>>>>>> I edited the Last Modified Date, and also updated the copyright > >>>>>>>>>> messages. > >>>>>>>>>> New webrev: > >>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525-awt-dev/ > >>>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Goetz. > >>>>>>>>>> > >>>>>>>>>> (Am I correct that your openJdk name is Vinnie?) > >>>>>>>>>> > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: Vincent Ryan [mailto:vincent.x.ryan at oracle.com] > >>>>>>>>>>> Sent: Mittwoch, 30. November 2016 14:53 > >>>>>>>>>>> To: Lindenmaier, Goetz > >>>>>>>>>>> Cc: awt-dev at openjdk.java.net; security- > dev at openjdk.java.net > >>>>>>>>>>> Subject: Re: RFR(M): 8170525: Fix minor issues in awt coding > >>>>>>>>>>> > >>>>>>>>>>> Hello Goetz, > >>>>>>>>>>> > >>>>>>>>>>> Please modify the bug summary to reference ECC too. > >>>>>>>>>>> Your ECC changes look fine but the ?Last Modified Date? line in > >> the > >>>>>>>>>>> 4 source > >>>>>>>>>>> code headers will need to be updated/added. > >>>>>>>>>>> > >>>>>>>>>>> BTW p11_mutex.c is listed below but appears to be missing > from > >>>> the > >>>>>>>>>>> webrev. > >>>>>>>>>>> > >>>>>>>>>>> Thanks. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> On 30 Nov 2016, at 13:12, Lindenmaier, Goetz > >>>>>>>>>>> >>>> > > >>>>>>>> wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I?d like to propose a row of smaller fixes where code is > noted > >>>>>>>>>>> down a > >>>>>>>>>>> bit questionable. > >>>>>>>>>>> SAP?s quality process requires that we fix these in our > internal > >>>>>>>>>>> delivery, > >>>>>>>>>>> and I > >>>>>>>>>>> Would like to share my fixes with openJdk. Some of these > >> fixes > >>>>>>>>>>> are of > >>>>>>>>>>> more > >>>>>>>>>>> theoretical nature as how I understand the code paths > never > >>>>>>>>>>> allow the > >>>>>>>>>>> problematic situation, but fixing it nevertheless assures > that > >>>>>>>>>>> nothing is > >>>>>>>>>>> overseen if the code changes. Most changes are in > >> libawt_xawt, > >>>>>>>>>>> some > >>>>>>>>>>> are in libsunec. > >>>>>>>>>>> > >>>>>>>>>>> I?d appreciate a review: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170525- > >>>> awt/webrev.01/ > >>>>>>>>>>> Changes in detail: > >>>>>>>>>>> > >>>>>>>>>>> awt_InputMethod.c: > >>>>>>>>>>> > >>>>>>>>>>> One might overrun the 100 byte fixed-size string > >>>>>>>>>>> statusWindow->status > >>>>>>>>>>> by copying text->string.multi_byte without checking the length. > >>>>>>>>>>> > >>>>>>>>>>> gtk3_interface.c: > >>>>>>>>>>> > >>>>>>>>>>> This less-than-zero comparison of an unsigned value is > never > >>>> true. > >>>>>>>>>>> Using uninitialized value color. Field color.alpha is > >>>>>>>>>>> uninitialized. > >>>>>>>>>>> E.g. used at gtk3_interface.c:2287. > >>>>>>>>>>> > >>>>>>>>>>> XToolkit.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value ret_timeout. > >>>>>>>>>>> E.g. in XToolkit.c:6809. > >>>>>>>>>>> > >>>>>>>>>>> XWindow.c > >>>>>>>>>>> > >>>>>>>>>>> Argument is incompatible with corresponding format > string > >>>>>>>>>>> conversion. > >>>>>>>>>>> > >>>>>>>>>>> splashscreen_sys.c > >>>>>>>>>>> > >>>>>>>>>>> Overflowed or truncated value (or a value computed from > an > >>>>>>>>>>> overflowed or truncated value) (gdk_scale> 0) ? native_scale * > >>>>>>>>>>> (double)gdk_scale : native_scale used as return value. > >>>>>>>>>>> > >>>>>>>>>>> ec.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value k.dp when calling mp_clear. > >>>>>>>>>>> > >>>>>>>>>>> ecdecode.c > >>>>>>>>>>> > >>>>>>>>>>> You might overrun the 291 byte fixed-size string genenc by > >>>> copying > >>>>>>>>>>> curveParams->geny without checking the length. > >>>>>>>>>>> Added sanity check before doing the string concatenation. > >>>>>>>>>>> > >>>>>>>>>>> ecl_mult.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value kt.flag when calling > >>>>>>>>>>> *group->point_mul. (The > >>>>>>>>>>> function pointer resolves to ec_GF2m_pt_mul_mont.) > >>>>>>>>>>> > >>>>>>>>>>> mpi.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value s. Field s.flag is uninitialized when > >>>>>>>>>>> calling > >>>>>>>>>>> s_mp_exch. > >>>>>>>>>>> Using uninitialized value tmp. Field tmp.flag is uninitialized > >> when > >>>>>>>>>>> calling s_mp_exch > >>>>>>>>>>> Using uninitialized value t.dp when calling mp_clear. > >>>>>>>>>>> > >>>>>>>>>>> p11_mutex.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value *ckpInitArgs. Field ckpInitArgs- > >flags > >> is > >>>>>>>>>>> uninitialized when calling memcpy. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> DataBufferNative.c > >>>>>>>>>>> > >>>>>>>>>>> Using uninitialized value lockInfo.rasBase when calling > >>>>>>>>>>> BN_GetPixelPointer. > >>>>>>>>>>> > >>>>>>>>>>> fontpath.c > >>>>>>>>>>> > >>>>>>>>>>> You might overrun the 512 byte fixed-size string > fontDirPath > >> by > >>>>>>>>>>> copying > >>>>>>>>>>> DirP->name[index] without checking the length. > >>>>>>>>>>> From prasanta.sadhukhan at oracle.com Wed Dec 7 15:30:12 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 7 Dec 2016 21:00:12 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" checkbox is disabled Message-ID: Hi All, Please review a fix for jdk9 where it is seen that "Banner" checkbox in printer dialog is disabled in ubuntu16.10. Bug: https://bugs.openjdk.java.net/browse/JDK-8170579 webrev: http://cr.openjdk.java.net/~psadhukhan/8170579/webrev.00/ Issue was, in ubuntu16.10 the attribute map does not have "job-sheet-supported" attribute returned by CUPS so this category is not added to supported categories [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] so isAttributeCategorySupported() called by ServiceDialog returns false [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l2763] resulting in Banner checkbox getting disabled. Fix is to check if JobSheet category is supported in underlying platform, only then proceed with the test. Regards Prasanta From brian.burkhalter at oracle.com Wed Dec 7 21:07:24 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Dec 2016 13:07:24 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way Message-ID: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> Reprising thread [1]. Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html From philip.race at oracle.com Thu Dec 8 00:56:45 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Dec 2016 16:56:45 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> Message-ID: <5848AFCD.6010304@oracle.com> +1 Yes, it needs a CCC update. A quick "bug fix" one. -phil. On 12/6/16, 2:03 PM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8169728 > Patch: http://cr.openjdk.java.net/~bpb/8169728/webrev.00/ > > To the primary constructor TIFFField(TIFFTag,int,int,Object), add some range checks for TIFF_LONG, TIFF_RATIONAL, and TIFF_IFD_POINTER, and some array size checks for TIFF_RATIONAL and TIFF_SRATIONAL. > > Does the new IllegalArgumentException case warrant a CCC review? > > Thanks, > > Brian From philip.race at oracle.com Thu Dec 8 01:01:53 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Dec 2016 17:01:53 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: <5848AFCD.6010304@oracle.com> References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> <5848AFCD.6010304@oracle.com> Message-ID: <5848B101.3080903@oracle.com> One "PS" why say 4294967295 in the spec where 0xFFFFFFFF is probably more immediately to most programmers that it is not a random choice of number ? -phil On 12/7/16, 4:56 PM, Philip Race wrote: > +1 > > Yes, it needs a CCC update. A quick "bug fix" one. > > -phil. > > On 12/6/16, 2:03 PM, Brian Burkhalter wrote: >> Please review at your convenience: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8169728 >> Patch: http://cr.openjdk.java.net/~bpb/8169728/webrev.00/ >> >> To the primary constructor TIFFField(TIFFTag,int,int,Object), add >> some range checks for TIFF_LONG, TIFF_RATIONAL, and TIFF_IFD_POINTER, >> and some array size checks for TIFF_RATIONAL and TIFF_SRATIONAL. >> >> Does the new IllegalArgumentException case warrant a CCC review? >> >> Thanks, >> >> Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 8 01:03:12 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Dec 2016 17:03:12 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169725: cannot use TIFFField(TIFFTag tag, int value) for TIFF_LONG values greater than Integer.MAX_VALUE In-Reply-To: References:

<5835BDC5.2080108@oracle.com> Message-ID: <5848B150.6050606@oracle.com> Looks OK except for the same question about using 0xFFFFFFFF. -phil. On 12/6/16, 12:31 PM, Brian Burkhalter wrote: > Continuing from thread [1]. > > Pursuant to comments from the CCC, the patch [2] has been updated. The changes with respect to the previous version of the patch [3] are to clarify the specification of TIFFField(TIFFTag,long) in terms of the constructor?s description and the exceptions it throws, and to add an exception for the case of value>= 4294967296, i.e., above the range of a 32-bit unsigned int. > > Once this patch is approved the CCC request may be updated. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007963.html > [2] http://cr.openjdk.java.net/~bpb/8169725/webrev.01/ > [3] http://cr.openjdk.java.net/~bpb/8169725/webrev.00/ > > On Nov 23, 2016, at 8:03 AM, Philip Race wrote: > >> +1 >> >> -phil From brian.burkhalter at oracle.com Thu Dec 8 01:04:54 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Dec 2016 17:04:54 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: <5848B101.3080903@oracle.com> References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> <5848AFCD.6010304@oracle.com> <5848B101.3080903@oracle.com> Message-ID: No particular reason. I suspect you are correct that it is more recognizable so I?ll change it. Thanks, Brian On Dec 7, 2016, at 5:01 PM, Philip Race wrote: > One "PS" > why say 4294967295 in the spec where 0xFFFFFFFF is probably > more immediately to most programmers that it is not a random > choice of number ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Dec 8 01:09:15 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Dec 2016 17:09:15 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169725: cannot use TIFFField(TIFFTag tag, int value) for TIFF_LONG values greater than Integer.MAX_VALUE In-Reply-To: <5848B150.6050606@oracle.com> References:

<5835BDC5.2080108@oracle.com> <5848B150.6050606@oracle.com> Message-ID: I was expecting that; will update. Thanks, Brian On Dec 7, 2016, at 5:03 PM, Philip Race wrote: > Looks OK except for the same question about using 0xFFFFFFFF. > > -phil. > > On 12/6/16, 12:31 PM, Brian Burkhalter wrote: >> Continuing from thread [1]. >> >> Pursuant to comments from the CCC, the patch [2] has been updated. The changes with respect to the previous version of the patch [3] are to clarify the specification of TIFFField(TIFFTag,long) in terms of the constructor?s description and the exceptions it throws, and to add an exception for the case of value>= 4294967296, i.e., above the range of a 32-bit unsigned int. >> >> Once this patch is approved the CCC request may be updated. >> >> Thanks, >> >> Brian >> >> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007963.html >> [2] http://cr.openjdk.java.net/~bpb/8169725/webrev.01/ >> [3] http://cr.openjdk.java.net/~bpb/8169725/webrev.00/ >> >> On Nov 23, 2016, at 8:03 AM, Philip Race wrote: >> >>> +1 >>> >>> -phil From brian.burkhalter at oracle.com Thu Dec 8 01:34:34 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Dec 2016 17:34:34 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169725: cannot use TIFFField(TIFFTag tag, int value) for TIFF_LONG values greater than Integer.MAX_VALUE In-Reply-To: References:

<5835BDC5.2080108@oracle.com> <5848B150.6050606@oracle.com> Message-ID: <5FD58FF5-67A2-43DE-80D3-F9B6174E38E5@oracle.com> The patch has been updated as suggested and the existing test has been modified to verify the changes: http://cr.openjdk.java.net/~bpb/8169725/webrev.02/ Thanks, Brian On Dec 7, 2016, at 5:09 PM, Brian Burkhalter wrote: > I was expecting that; will update. > > Thanks, > > Brian > > On Dec 7, 2016, at 5:03 PM, Philip Race wrote: > >> Looks OK except for the same question about using 0xFFFFFFFF. >> >> -phil. >> >> On 12/6/16, 12:31 PM, Brian Burkhalter wrote: >>> Continuing from thread [1]. >>> >>> Pursuant to comments from the CCC, the patch [2] has been updated. The changes with respect to the previous version of the patch [3] are to clarify the specification of TIFFField(TIFFTag,long) in terms of the constructor?s description and the exceptions it throws, and to add an exception for the case of value>= 4294967296, i.e., above the range of a 32-bit unsigned int. >>> >>> Once this patch is approved the CCC request may be updated. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007963.html >>> [2] http://cr.openjdk.java.net/~bpb/8169725/webrev.01/ >>> [3] http://cr.openjdk.java.net/~bpb/8169725/webrev.00/ >>> >>> On Nov 23, 2016, at 8:03 AM, Philip Race wrote: >>> >>>> +1 >>>> >>>> -phil > From philip.race at oracle.com Thu Dec 8 02:41:59 2016 From: philip.race at oracle.com (Philip Race) Date: Wed, 07 Dec 2016 18:41:59 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169725: cannot use TIFFField(TIFFTag tag, int value) for TIFF_LONG values greater than Integer.MAX_VALUE In-Reply-To: <5FD58FF5-67A2-43DE-80D3-F9B6174E38E5@oracle.com> References:

<5835BDC5.2080108@oracle.com> <5848B150.6050606@oracle.com> <5FD58FF5-67A2-43DE-80D3-F9B6174E38E5@oracle.com> Message-ID: <5848C877.4040500@oracle.com> +1 -phil. On 12/7/16, 5:34 PM, Brian Burkhalter wrote: > The patch has been updated as suggested and the existing test has been modified to verify the changes: > > http://cr.openjdk.java.net/~bpb/8169725/webrev.02/ > > Thanks, > > Brian > > On Dec 7, 2016, at 5:09 PM, Brian Burkhalter wrote: > >> I was expecting that; will update. >> >> Thanks, >> >> Brian >> >> On Dec 7, 2016, at 5:03 PM, Philip Race wrote: >> >>> Looks OK except for the same question about using 0xFFFFFFFF. >>> >>> -phil. >>> >>> On 12/6/16, 12:31 PM, Brian Burkhalter wrote: >>>> Continuing from thread [1]. >>>> >>>> Pursuant to comments from the CCC, the patch [2] has been updated. The changes with respect to the previous version of the patch [3] are to clarify the specification of TIFFField(TIFFTag,long) in terms of the constructor?s description and the exceptions it throws, and to add an exception for the case of value>= 4294967296, i.e., above the range of a 32-bit unsigned int. >>>> >>>> Once this patch is approved the CCC request may be updated. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-November/007963.html >>>> [2] http://cr.openjdk.java.net/~bpb/8169725/webrev.01/ >>>> [3] http://cr.openjdk.java.net/~bpb/8169725/webrev.00/ >>>> >>>> On Nov 23, 2016, at 8:03 AM, Philip Race wrote: >>>> >>>>> +1 >>>>> >>>>> -phil From philip.race at oracle.com Thu Dec 8 20:01:03 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 8 Dec 2016 12:01:03 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8039273: Font related files should not be modified in ${java.home}/lib Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8039273 Webrev : http://cr.openjdk.java.net/~prr/8039273/ A CCC request and documentation are being prepared. -phil From brian.burkhalter at oracle.com Thu Dec 8 21:14:00 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Dec 2016 13:14:00 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> <5848AFCD.6010304@oracle.com> <5848B101.3080903@oracle.com> Message-ID: <3534B5B5-FA34-4CBC-A96B-16456903C2D5@oracle.com> The patch has been updated as suggested and the test has been modified to verify the changes [1]. Note that this patch is with respect to the repository with the patch for [2] already applied. Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-December/007993.html [2] https://bugs.openjdk.java.net/browse/JDK-8169725 On Dec 7, 2016, at 5:04 PM, Brian Burkhalter wrote: > No particular reason. I suspect you are correct that it is more recognizable so I?ll change it. > > Thanks, > > Brian > > On Dec 7, 2016, at 5:01 PM, Philip Race wrote: > >> One "PS" >> why say 4294967295 in the spec where 0xFFFFFFFF is probably >> more immediately to most programmers that it is not a random >> choice of number ? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 8 21:43:00 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 8 Dec 2016 13:43:00 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> References: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> Message-ID: I think that spec. looks good so you can at least proceed with the CCC. -phil. On 12/07/2016 01:07 PM, Brian Burkhalter wrote: > Reprising thread [1]. > > Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html > Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ > Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead > > Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html From brian.burkhalter at oracle.com Fri Dec 9 01:43:07 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Dec 2016 17:43:07 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: References: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> Message-ID: <37D6F2F8-BE4E-48A3-A84D-78E12F5FE508@oracle.com> Here is an updated patch http://cr.openjdk.java.net/~bpb/8154058/webrev.02/ which differs from the previous one only in terms of the test which has been updated to verify that: 1) essential metadata are not affected by the settings of ignoreMetadata and readUnknownTags; 2) non-essential metadata with a recognized tag are suppressed by ignoreMetadata == true, but when ignoreMetadata == false are unaffected by the setting of readUnknownTags; 3) metadata with an unrecognized tag are read if and only if ignoreMetadata == false and readUnknownTags == true. Thanks, Brian On Dec 8, 2016, at 1:43 PM, Phil Race wrote: > I think that spec. looks good so you can at least proceed with the CCC. > > -phil. > > On 12/07/2016 01:07 PM, Brian Burkhalter wrote: >> Reprising thread [1]. >> >> Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html >> Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ >> Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead >> >> Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. >> >> Thanks, >> >> Brian >> >> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html > From david.buck at oracle.com Fri Dec 9 02:26:48 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 9 Dec 2016 11:26:48 +0900 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8170954: non-ASCII characters in lcms and harfbuzz break Windows builds on some locales Message-ID: <584A1668.2060902@oracle.com> Hi! Please review this trivial makefile change to disable a problematic warning. bug report: https://bugs.openjdk.java.net/browse/JDK-8170954 webrev: http://cr.openjdk.java.net/~dbuck/jdk8170954_ver00/ Cheers, -Buck From philip.race at oracle.com Fri Dec 9 03:07:02 2016 From: philip.race at oracle.com (Philip Race) Date: Thu, 08 Dec 2016 19:07:02 -0800 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8170954: non-ASCII characters in lcms and harfbuzz break Windows builds on some locales In-Reply-To: <584A1668.2060902@oracle.com> References: <584A1668.2060902@oracle.com> Message-ID: <584A1FD6.2090807@oracle.com> This is fine by me. These are imported libraries so we just disable the warnings rather than fix them. The only question I had is that US English is the only supported build environment and RE builds will always use that .. everything else is "good luck", Unless something changed to affect that. -phil. On 12/8/16, 6:26 PM, David Buck wrote: > Hi! > > Please review this trivial makefile change to disable a problematic > warning. > > bug report: https://bugs.openjdk.java.net/browse/JDK-8170954 > webrev: http://cr.openjdk.java.net/~dbuck/jdk8170954_ver00/ > > Cheers, > -Buck > > From david.buck at oracle.com Fri Dec 9 05:00:15 2016 From: david.buck at oracle.com (David Buck) Date: Fri, 9 Dec 2016 14:00:15 +0900 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8170954: non-ASCII characters in lcms and harfbuzz break Windows builds on some locales In-Reply-To: <584A1FD6.2090807@oracle.com> References: <584A1668.2060902@oracle.com> <584A1FD6.2090807@oracle.com> Message-ID: <584A3A5F.9010407@oracle.com> Hi! Phil, Thank you for the review! > The only question I had is that US English is > the only supported build environment and > RE builds will always use that .. everything else is "good luck", > Unless something changed to affect that. As I mentioned in the bug, we don't currently document the requirement to build on US English locale in any external resource that I could find. We may need to add something in the future, most likely on the official build platforms page [0].. But even if we do decide not to "support" building on non-English locales in any official capacity, this "fix" is simple and safe enough that I strongly believe that we should still do it to make participating in OpenJDK easier for non-English Windows users. Cheers, -Buck [0] https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms On 2016/12/09 12:07, Philip Race wrote: > This is fine by me. These are imported libraries so > we just disable the warnings rather than fix them. > > The only question I had is that US English is > the only supported build environment and > RE builds will always use that .. everything else is "good luck", > Unless something changed to affect that. > > -phil. > > On 12/8/16, 6:26 PM, David Buck wrote: >> Hi! >> >> Please review this trivial makefile change to disable a problematic >> warning. >> >> bug report: https://bugs.openjdk.java.net/browse/JDK-8170954 >> webrev: http://cr.openjdk.java.net/~dbuck/jdk8170954_ver00/ >> >> Cheers, >> -Buck >> >> From goetz.lindenmaier at sap.com Fri Dec 9 07:57:54 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 9 Dec 2016 07:57:54 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. Message-ID: Hi, This change fixes some minor issues found in our code scans. I hope this correctly addresses corelib and serviceability issues. Please review: http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.01/ Best regards, Goetz. Changes in detail: hg-ot-font.cc Looks like assignment instead of compare. Use extra if(). hg-ot_layout-gpos-table.hh valueFormat is passed to apply(), where it is used as an array with two elements: line 621: valueFormats[1].get_len(); It was correct as there are actually two fields in the struct that have the same layout as an array. ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h In ThaiShaping.cpp:307 conState is passed to getNextState() where it is in the end used to index to thaiStateTable. thaiStateTable has 52 elements. But conState is initialized to 0xFF == 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access. OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with index < scriptCodeCount, but only contains scriptCodeCount-1 elements. I added a size entry to the enums, and use that for sizing the array and checking the size. jctrans.c if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it will access MCU_buffer[0]. (jcphuff.c:487) cmserr.c Must check return value of ftell. cmsgamma.c Out/out/in are used as arrays in called function. cmslut.c Out[] may be used uninitialized. cmstypes.c Must check return value of Tell. The negative outcome should not be passed to Seek. cmsxform.c Using uninitialized element of array wIn when calling *p->FromInput. (The function pointer resolves to Pack1Byte.) Using uninitialized element of array fIn when calling *p->FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) Using uninitialized element of array fIn when calling *p->FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) PLATFORM_API_LinuxOS_ALSA_Ports.c Using uninitialized element of array controls when calling *creator->newCompoundControl. (The function pointer resolves to PORT_NewCompoundControl.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Dec 9 08:22:27 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 9 Dec 2016 13:52:27 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: References: Message-ID: Hi All, In continuation with the below mail, the issue is "collate" option is not checked for linux. Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ Proposed fix is to disable collate option for linux in printer dialog. Regards Prasanta On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: > > Hi Phil, > > I was investigating JDK-8170352: The collate option is not checked and > I found that CUPS does not report collate as supported attribute. > > It is removed from printRequestAttrib > [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] > so we do not look for collate-supported attribute in CUPS. Infact, > getAttMap does not have any "collate-supported" attribute too!! > Also, this code > [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] > has been added [for 8016737] > to remove SheetCollate from supported attributes. > > In light of this, I think we should disabled collate option from our > print dialog even for Toolkit based PrintJob. It seems, from this code > http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 > it is enabled if we specify in testcase > /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); > /in which case isAWT set to true. > even though selection is determined by attribute support > [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] > > I could not find why it is hardcoded to setEnabled(true) for > "Selection". Do you know? mercurial history shows that line from jdk7 > and I could not find previous history. > I think there also, we should check for "scSupported" to enable > sheetcollate? Anyways, "Selection" option is not there in linux. > Please let me know your views. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Dec 9 08:42:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 9 Dec 2016 09:42:49 +0100 Subject: [OpenJDK 2D-Dev] RFR(XXS): 8170954: non-ASCII characters in lcms and harfbuzz break Windows builds on some locales In-Reply-To: <584A1668.2060902@oracle.com> References: <584A1668.2060902@oracle.com> Message-ID: Looks ok to me. /Erik On 2016-12-09 03:26, David Buck wrote: > Hi! > > Please review this trivial makefile change to disable a problematic > warning. > > bug report: https://bugs.openjdk.java.net/browse/JDK-8170954 > webrev: http://cr.openjdk.java.net/~dbuck/jdk8170954_ver00/ > > Cheers, > -Buck > > From naoto.sato at oracle.com Fri Dec 9 17:44:54 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Dec 2016 09:44:54 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8039273: Font related files should not be modified in ${java.home}/lib In-Reply-To: References: Message-ID: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com> Hi Phil, In FontConfiguration.java, line 193-195 can be inserted just after line 191, as fontConfigFile is guaranteed to be non-null if userConfigFile is non null. Otherwise it looks good to me. Naoto On 12/8/16 12:01 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8039273 > Webrev : http://cr.openjdk.java.net/~prr/8039273/ > > A CCC request and documentation are being prepared. > > -phil From brian.burkhalter at oracle.com Fri Dec 9 19:18:23 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Dec 2016 11:18:23 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: <3534B5B5-FA34-4CBC-A96B-16456903C2D5@oracle.com> References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> <5848AFCD.6010304@oracle.com> <5848B101.3080903@oracle.com> <3534B5B5-FA34-4CBC-A96B-16456903C2D5@oracle.com> Message-ID: <7AAB30E2-A5D6-410E-B821-A94122A0B94D@oracle.com> Forgot to include a link to the updated patch: http://cr.openjdk.java.net/~bpb/8169728/webrev.01/ Thanks, Brian On Dec 8, 2016, at 1:14 PM, Brian Burkhalter wrote: > The patch has been updated as suggested and the test has been modified to verify the changes [1]. Note that this patch is with respect to the repository with the patch for [2] already applied. > > Thanks, > > Brian > > [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-December/007993.html > [2] https://bugs.openjdk.java.net/browse/JDK-8169725 > > On Dec 7, 2016, at 5:04 PM, Brian Burkhalter wrote: > >> No particular reason. I suspect you are correct that it is more recognizable so I?ll change it. >> >> Thanks, >> >> Brian >> >> On Dec 7, 2016, at 5:01 PM, Philip Race wrote: >> >>> One "PS" >>> why say 4294967295 in the spec where 0xFFFFFFFF is probably >>> more immediately to most programmers that it is not a random >>> choice of number ? >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Dec 9 21:38:35 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 9 Dec 2016 13:38:35 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8169728: Missing sign checks in TIFFField(TIFFTag tag, int type, int count, Object data) for TIFFTag.TIFF_LONG In-Reply-To: <7AAB30E2-A5D6-410E-B821-A94122A0B94D@oracle.com> References: <7F3C1149-B114-4765-89E5-C03B2695DC16@oracle.com> <5848AFCD.6010304@oracle.com> <5848B101.3080903@oracle.com> <3534B5B5-FA34-4CBC-A96B-16456903C2D5@oracle.com> <7AAB30E2-A5D6-410E-B821-A94122A0B94D@oracle.com> Message-ID: +1 -phil. On 12/09/2016 11:18 AM, Brian Burkhalter wrote: > Forgot to include a link to the updated patch: > > http://cr.openjdk.java.net/~bpb/8169728/webrev.01/ > > > Thanks, > > Brian > > On Dec 8, 2016, at 1:14 PM, Brian Burkhalter > > wrote: > >> The patch has been updated as suggested and the test has been >> modified to verify the changes [1]. Note that this patch is with >> respect to the repository with the patch for [2] already applied. >> >> Thanks, >> >> Brian >> >> [1] >> http://mail.openjdk.java.net/pipermail/2d-dev/2016-December/007993.html >> [2] https://bugs.openjdk.java.net/browse/JDK-8169725 >> >> On Dec 7, 2016, at 5:04 PM, Brian Burkhalter >> > wrote: >> >>> No particular reason. I suspect you are correct that it is more >>> recognizable so I?ll change it. >>> >>> Thanks, >>> >>> Brian >>> >>> On Dec 7, 2016, at 5:01 PM, Philip Race >> > wrote: >>> >>>> One "PS" >>>> why say4294967295in the spec where 0xFFFFFFFF is probably >>>> more immediately to most programmers that it is not a random >>>> choice of number ? >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Dec 9 23:28:10 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 9 Dec 2016 15:28:10 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: References:

Message-ID: <06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> Regarding being hard-coded for "Selection", the point there is that in the AWT code path we always generate Postscript, whereas in the 2D path we may send some other content. Since we generate Postscript my instinct here is that Collate should always work since that gets embedded in the Postscript. The CUPS filter should then do whatever is necessary to generate the right number of collated or uncollated copies for the printer. I tracked down the changeset that has the code you reference http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you read the bug report for that : https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes clear (sort of) that this was a workaround for the oddity that Collate worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea was to stop saying it was supported. That is very annoying of course and I'd love to know if we've rechecked from the source that "CUPS does not report collate as a supported attribute" It is mentioned in CUPS docs. https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS Also the fix you are proposing doesn't seem to change anything that will help the test. It expects Collate to be checked. Doesn't it ? -phil. On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: > > Hi All, > > In continuation with the below mail, the issue is "collate" option is > not checked for linux. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 > > webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ > > Proposed fix is to disable collate option for linux in printer dialog. > > Regards > Prasanta > On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >> >> Hi Phil, >> >> I was investigating JDK-8170352: The collate option is not checked >> and I found that CUPS does not report collate as supported attribute. >> >> It is removed from printRequestAttrib >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >> so we do not look for collate-supported attribute in CUPS. Infact, >> getAttMap does not have any "collate-supported" attribute too!! >> Also, this code >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >> has been added [for 8016737] >> to remove SheetCollate from supported attributes. >> >> In light of this, I think we should disabled collate option from our >> print dialog even for Toolkit based PrintJob. It seems, from this code >> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >> it is enabled if we specify in testcase >> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >> /in which case isAWT set to true. >> even though selection is determined by attribute support >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >> >> I could not find why it is hardcoded to setEnabled(true) for >> "Selection". Do you know? mercurial history shows that line from jdk7 >> and I could not find previous history. >> I think there also, we should check for "scSupported" to enable >> sheetcollate? Anyways, "Selection" option is not there in linux. >> Please let me know your views. >> >> Regards >> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Sat Dec 10 08:19:58 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 10 Dec 2016 13:49:58 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: <06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> References:

<06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> Message-ID: <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> On 12/10/2016 4:58 AM, Phil Race wrote: > Regarding being hard-coded for "Selection", the point there is that in > the AWT code path we always generate Postscript, whereas in the 2D > path we may send some other content. Since we generate Postscript my > instinct here is that Collate should always work since that gets > embedded in the Postscript. The CUPS filter should then do whatever is > necessary to generate the right number of collated or uncollated > copies for the printer. I tracked down the changeset that has the code > you reference > http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you read > the bug report for that : > https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes clear > (sort of) that this was a workaround for the oddity that Collate > worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea was to > stop saying it was supported. That is very annoying of course and I'd > love to know if we've rechecked from the source that "CUPS does not > report collate as a supported attribute" I checked getAttMap (response received from cups) http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767 and there is no "collate-supported" attribute in there. > It is mentioned in CUPS docs. > https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS > Also the fix you are proposing doesn't seem to change anything that > will help the test. It expects Collate to be checked. Doesn't it ? The fix does not directly help the test. The idea is to have the test call first isAttributeCategorySupprted(SheetCollate.class) and only execute the test if it is supported. It is mentioned inthe bug report. Since, now our code returns false for SheetCollate attribute, my fix will disable the collate option to prevent anomaly of returning false for support but enabling the collate option. Regards Prasanta > -phil. > > > On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: >> >> Hi All, >> >> In continuation with the below mail, the issue is "collate" option is >> not checked for linux. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 >> >> webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ >> >> Proposed fix is to disable collate option for linux in printer dialog. >> >> Regards >> Prasanta >> On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >>> >>> Hi Phil, >>> >>> I was investigating JDK-8170352: The collate option is not checked >>> and I found that CUPS does not report collate as supported attribute. >>> >>> It is removed from printRequestAttrib >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >>> so we do not look for collate-supported attribute in CUPS. Infact, >>> getAttMap does not have any "collate-supported" attribute too!! >>> Also, this code >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >>> has been added [for 8016737] >>> to remove SheetCollate from supported attributes. >>> >>> In light of this, I think we should disabled collate option from our >>> print dialog even for Toolkit based PrintJob. It seems, from this code >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >>> it is enabled if we specify in testcase >>> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >>> /in which case isAWT set to true. >>> even though selection is determined by attribute support >>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >>> >>> I could not find why it is hardcoded to setEnabled(true) for >>> "Selection". Do you know? mercurial history shows that line from >>> jdk7 and I could not find previous history. >>> I think there also, we should check for "scSupported" to enable >>> sheetcollate? Anyways, "Selection" option is not there in linux. >>> Please let me know your views. >>> >>> Regards >>> Prasanta >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Tue Dec 13 13:29:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 13 Dec 2016 13:29:07 +0000 Subject: [OpenJDK 2D-Dev] [ping] RE: RFR(M): 8170798: Fix minor issues in java2d and sound coding. Message-ID: Could someone please have a look at these changes? Thanks, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Freitag, 9. Dezember 2016 08:58 > To: 2d-dev <2d-dev at openjdk.java.net>; 'sound-dev at openjdk.java.net' dev at openjdk.java.net> > Subject: RFR(M): 8170798: Fix minor issues in java2d and sound coding. > > Hi, > > > > This change fixes some minor issues found in our code scans. > > I hope this correctly addresses corelib and serviceability issues. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.01/ > > > > Best regards, > > Goetz. > > > > Changes in detail: > > > > hg-ot-font.cc > > Looks like assignment instead of compare. Use extra if(). > > > hg-ot_layout-gpos-table.hh > > valueFormat is passed to apply(), where it is used as an array with two > elements: > line 621: valueFormats[1].get_len(); > It was correct as there are actually two fields in the struct that have the > same layout as an array. > > > ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h > > > In ThaiShaping.cpp:307 conState is passed to getNextState() where it is in the > end used to index to thaiStateTable. > thaiStateTable has 52 elements. But conState is initialized to 0xFF == 255 in > ThaiShaping.cpp:296. This can result in an out-of-bounds access. > > OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with index < > scriptCodeCount, but only contains scriptCodeCount-1 elements. > > I added a size entry to the enums, and use that for sizing the array and checking > the size. > > > jctrans.c > > if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it will > access MCU_buffer[0]. (jcphuff.c:487) > > > > cmserr.c > > Must check return value of ftell. > > > cmsgamma.c > > Out/out/in are used as arrays in called function. > > > cmslut.c > > Out[] may be used uninitialized. > > > cmstypes.c > > Must check return value of Tell. The negative outcome should not be passed to > Seek. > > > cmsxform.c > > Using uninitialized element of array wIn when calling *p->FromInput. (The > function pointer resolves to Pack1Byte.) > Using uninitialized element of array fIn when calling *p->FromInputFloat. (The > function pointer resolves to PackDoublesFromFloat.) > Using uninitialized element of array fIn when calling *p->FromInputFloat. (The > function pointer resolves to PackDoublesFromFloat.) > > > PLATFORM_API_LinuxOS_ALSA_Ports.c > > Using uninitialized element of array controls when calling *creator- > >newCompoundControl. (The function pointer resolves to > PORT_NewCompoundControl.) > > From prasanta.sadhukhan at oracle.com Tue Dec 13 16:08:26 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 13 Dec 2016 21:38:26 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" checkbox is disabled In-Reply-To: References: Message-ID: <5227445d-36c7-85a3-9d78-c8061e6e568a@oracle.com> Gentle reminder for review.... Regards Prasanta On 12/7/2016 9:00 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 where it is seen that "Banner" checkbox > in printer dialog is disabled in ubuntu16.10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170579 > webrev: http://cr.openjdk.java.net/~psadhukhan/8170579/webrev.00/ > > Issue was, in ubuntu16.10 the attribute map does not have > "job-sheet-supported" attribute returned by CUPS > so this category is not added to supported categories > [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] > > so isAttributeCategorySupported() called by ServiceDialog returns > false > [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l2763] > resulting in Banner checkbox getting disabled. > > Fix is to check if JobSheet category is supported in underlying > platform, only then proceed with the test. > > Regards > Prasanta From philip.race at oracle.com Tue Dec 13 19:54:56 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Dec 2016 11:54:56 -0800 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. In-Reply-To: References: Message-ID: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> Hi Goetz, Comments in-line but first some general points. (1) I notice you prepared the webrev against jdk9/dev. It should be prepared against jdk9/client - which is where it should also be pushed. (2) However most of these changes are in a 3rd party imported library. We don't edit these unless there is a good reason. Instead we would report them to up-stream and import next time we upgrade. So only a subset of these make sense to fix in JDK .. otherwise we'll just blow them away when we upgrade. In particular this means the changes to (a) harfbuzz (b) littlecms which are actively maintained externally and we upgrade periodically. Local changes may make sense in (c) ICU layout (d) libjpeg6b since these are at a different stage in their life Having said that see the comments in-line. -phil On 12/08/2016 11:57 PM, Lindenmaier, Goetz wrote: > > Hi, > > This change fixes some minor issues found in our code scans. > > I hope this correctly addresses corelib and serviceability issues. > > Please review: > > http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.01/ > > > Best regards, > > Goetz. > > Changes in detail: > > hg-ot-font.cc > > Looks like assignment instead of compare. Use extra if(). > This is a stylistic change. You will need to convince Behdad. > > > hg-ot_layout-gpos-table.hh > > valueFormat is passed to apply(), where it is used as an array with > two elements: > line 621: valueFormats[1].get_len(); > It was correct as there are actually two fields in the struct that > have the > same layout as an array. > This also needs to go to the harfbuzz mailing list. > > > ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h > > > In ThaiShaping.cpp:307 conState is passed to getNextState() where it > is in the end used to index to thaiStateTable. > thaiStateTable has 52 elements. But conState is initialized to 0xFF == > 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access. > This is not entered unconditionally, so consState should be updated before we reach there. However the check is harmless so should be fine. > > OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with > index < scriptCodeCount, but only contains scriptCodeCount-1 elements. > > I added a size entry to the enums, and use that for sizing the array > and checking the size. > I am fairly sure you didn't include all of these changes in the webrev. I see only the use for sizing the array > > > jctrans.c > > if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it > will access MCU_buffer[0]. (jcphuff.c:487) > > It is hard to prove with static analysis but it seems like the block above does the initialisation. So I don't strongly object to this but I also don't see that the case for it is proven. > > cmserr.c > > Must check return value of ftell. > > > cmsgamma.c > > Out/out/in are used as arrays in called function. > > > cmslut.c > > Out[] may be used uninitialized. > > > cmstypes.c > > Must check return value of Tell. The negative outcome should not be > passed to Seek. > > > cmsxform.c > > Using uninitialized element of array wIn when calling *p->FromInput. > (The function pointer resolves to Pack1Byte.) > Using uninitialized element of array fIn when calling > *p->FromInputFloat. (The function pointer resolves to > PackDoublesFromFloat.) > Using uninitialized element of array fIn when calling > *p->FromInputFloat. (The function pointer resolves to > PackDoublesFromFloat.) > All of the above should be proposed to the upstream littlecms list > > > > PLATFORM_API_LinuxOS_ALSA_Ports.c > > Using uninitialized element of array controls when calling > *creator->newCompoundControl. (The function pointer resolves to > PORT_NewCompoundControl.) > So it seems like the elements at indices from controlCount to 10 may not be initialised but I don't see how this would be a problem since PORT_NewCompoundControl has no hardwired "10" .. it just uses controlCount. In any case this would seem better addressed by the same kind of memset after stack allocation that you proposed for the jpeg case. -phil. -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Dec 13 20:09:33 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 13 Dec 2016 12:09:33 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <37D6F2F8-BE4E-48A3-A84D-78E12F5FE508@oracle.com> References: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> <37D6F2F8-BE4E-48A3-A84D-78E12F5FE508@oracle.com> Message-ID: This should be the final patch. The actual implementation code is unchanged from webrev.01, which was approved in terms of the spec change, which has also now been approved by the CCC. This patch differs from webrev.02 only in terms of renaming ReadParamTest to ReadUnknownTagsTest, and changing the ignoreMetadata settings in MultiPageImageTIFFFieldTest and TIFFImageReadParamTest from true to false. These latter two changes are needed as previously non-essential fields in recognized tag sets were read even if ignoreMetadata was true, which is now not the case. Thanks, Brian On Dec 8, 2016, at 5:43 PM, Brian Burkhalter wrote: > Here is an updated patch > > http://cr.openjdk.java.net/~bpb/8154058/webrev.02/ > > which differs from the previous one only in terms of the test which has been updated to verify that: > > 1) essential metadata are not affected by the settings of ignoreMetadata and readUnknownTags; > 2) non-essential metadata with a recognized tag are suppressed by ignoreMetadata == true, but when ignoreMetadata == false are unaffected by the setting of readUnknownTags; > 3) metadata with an unrecognized tag are read if and only if ignoreMetadata == false and readUnknownTags == true. > > Thanks, > > Brian > > On Dec 8, 2016, at 1:43 PM, Phil Race wrote: > >> I think that spec. looks good so you can at least proceed with the CCC. >> >> -phil. >> >> On 12/07/2016 01:07 PM, Brian Burkhalter wrote: >>> Reprising thread [1]. >>> >>> Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html >>> Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ >>> Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead >>> >>> Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html From philip.race at oracle.com Tue Dec 13 20:10:49 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Dec 2016 12:10:49 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> References:

<06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> Message-ID: <71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com> Hi, Thanks for checking that. The bit I don't like here is that the end-user can then no longer ask for collation at all on Linux even though it has some chance of working on some versions. Hmm .. http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set --- In our cups class we were doing a cupsAddOption("copies", "2",.. and cupsAddOption("Collate", "True", .. commands (see examples below). It turns out the the cups "copies" command was killing the Collating if it set to 2. Like the orientation postscript/cups conflict you need to set the cups copies value to 1 to get the collation to work. The postscript file already knows its going to print out, for example 2 copies. --- We set NumCopies in the Postscript along with collate :- mPSStream.print(isCollated() ? " /Collate true":""); mPSStream.print(" /NumCopies " +getCopiesInt()); So when we exec we also do "lp -# 2 .. " or whatever do set copies. Does it help if we stop doing that for the collated case ? -phil. On 12/10/2016 12:19 AM, Prasanta Sadhukhan wrote: > > > > On 12/10/2016 4:58 AM, Phil Race wrote: >> Regarding being hard-coded for "Selection", the point there is that >> in the AWT code path we always generate Postscript, whereas in the 2D >> path we may send some other content. Since we generate Postscript my >> instinct here is that Collate should always work since that gets >> embedded in the Postscript. The CUPS filter should then do whatever >> is necessary to generate the right number of collated or uncollated >> copies for the printer. I tracked down the changeset that has the >> code you reference >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you read >> the bug report for that : >> https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes >> clear (sort of) that this was a workaround for the oddity that >> Collate worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea >> was to stop saying it was supported. That is very annoying of course >> and I'd love to know if we've rechecked from the source that "CUPS >> does not report collate as a supported attribute" > I checked getAttMap (response received from cups) > http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767 > and there is no "collate-supported" attribute in there. >> It is mentioned in CUPS docs. >> https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS >> Also the fix you are proposing doesn't seem to change anything that >> will help the test. It expects Collate to be checked. Doesn't it ? > The fix does not directly help the test. The idea is to have the test > call first isAttributeCategorySupprted(SheetCollate.class) and only > execute the test if it is supported. It is mentioned inthe bug report. > Since, now our code returns false for SheetCollate attribute, my fix > will disable the collate option to prevent anomaly of returning false > for support but enabling the collate option. > > Regards > Prasanta >> -phil. >> >> >> On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: >>> >>> Hi All, >>> >>> In continuation with the below mail, the issue is "collate" option >>> is not checked for linux. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 >>> >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ >>> >>> Proposed fix is to disable collate option for linux in printer dialog. >>> >>> Regards >>> Prasanta >>> On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >>>> >>>> Hi Phil, >>>> >>>> I was investigating JDK-8170352: The collate option is not checked >>>> and I found that CUPS does not report collate as supported attribute. >>>> >>>> It is removed from printRequestAttrib >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >>>> so we do not look for collate-supported attribute in CUPS. Infact, >>>> getAttMap does not have any "collate-supported" attribute too!! >>>> Also, this code >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >>>> has been added [for 8016737] >>>> to remove SheetCollate from supported attributes. >>>> >>>> In light of this, I think we should disabled collate option from >>>> our print dialog even for Toolkit based PrintJob. It seems, from >>>> this code >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >>>> it is enabled if we specify in testcase >>>> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >>>> /in which case isAWT set to true. >>>> even though selection is determined by attribute support >>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >>>> >>>> I could not find why it is hardcoded to setEnabled(true) for >>>> "Selection". Do you know? mercurial history shows that line from >>>> jdk7 and I could not find previous history. >>>> I think there also, we should check for "scSupported" to enable >>>> sheetcollate? Anyways, "Selection" option is not there in linux. >>>> Please let me know your views. >>>> >>>> Regards >>>> Prasanta >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Tue Dec 13 20:14:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 13 Dec 2016 12:14:52 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: References: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> <37D6F2F8-BE4E-48A3-A84D-78E12F5FE508@oracle.com> Message-ID: <7B9BAD50-2507-4B64-8D5A-B159654BB1CD@oracle.com> Here?s the link to the most recent patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.03/ Sorry for the omission. Thanks, Brian On Dec 13, 2016, at 12:09 PM, Brian Burkhalter wrote: > This should be the final patch. The actual implementation code is unchanged from webrev.01, which was approved in terms of the spec change, which has also now been approved by the CCC. This patch differs from webrev.02 only in terms of renaming ReadParamTest to ReadUnknownTagsTest, and changing the ignoreMetadata settings in MultiPageImageTIFFFieldTest and TIFFImageReadParamTest from true to false. These latter two changes are needed as previously non-essential fields in recognized tag sets were read even if ignoreMetadata was true, which is now not the case. > > Thanks, > > Brian > > On Dec 8, 2016, at 5:43 PM, Brian Burkhalter wrote: > >> Here is an updated patch >> >> http://cr.openjdk.java.net/~bpb/8154058/webrev.02/ >> >> which differs from the previous one only in terms of the test which has been updated to verify that: >> >> 1) essential metadata are not affected by the settings of ignoreMetadata and readUnknownTags; >> 2) non-essential metadata with a recognized tag are suppressed by ignoreMetadata == true, but when ignoreMetadata == false are unaffected by the setting of readUnknownTags; >> 3) metadata with an unrecognized tag are read if and only if ignoreMetadata == false and readUnknownTags == true. >> >> Thanks, >> >> Brian >> >> On Dec 8, 2016, at 1:43 PM, Phil Race wrote: >> >>> I think that spec. looks good so you can at least proceed with the CCC. >>> >>> -phil. >>> >>> On 12/07/2016 01:07 PM, Brian Burkhalter wrote: >>>> Reprising thread [1]. >>>> >>>> Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html >>>> Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ >>>> Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead >>>> >>>> Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. >>>> >>>> Thanks, >>>> >>>> Brian >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html From philip.race at oracle.com Tue Dec 13 20:19:10 2016 From: philip.race at oracle.com (Phil Race) Date: Tue, 13 Dec 2016 12:19:10 -0800 Subject: [OpenJDK 2D-Dev] OpenJDK 2D-Dev] [9] RFR JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way In-Reply-To: <7B9BAD50-2507-4B64-8D5A-B159654BB1CD@oracle.com> References: <148100A0-6757-472D-B5C8-155508FF3B27@oracle.com> <37D6F2F8-BE4E-48A3-A84D-78E12F5FE508@oracle.com> <7B9BAD50-2507-4B64-8D5A-B159654BB1CD@oracle.com> Message-ID: <7427eb54-77d5-4374-3c94-cdb29818c28f@oracle.com> +1 -phil. On 12/13/2016 12:14 PM, Brian Burkhalter wrote: > Here?s the link to the most recent patch: > > http://cr.openjdk.java.net/~bpb/8154058/webrev.03/ > > Sorry for the omission. > > Thanks, > > Brian > > On Dec 13, 2016, at 12:09 PM, Brian Burkhalter wrote: > >> This should be the final patch. The actual implementation code is unchanged from webrev.01, which was approved in terms of the spec change, which has also now been approved by the CCC. This patch differs from webrev.02 only in terms of renaming ReadParamTest to ReadUnknownTagsTest, and changing the ignoreMetadata settings in MultiPageImageTIFFFieldTest and TIFFImageReadParamTest from true to false. These latter two changes are needed as previously non-essential fields in recognized tag sets were read even if ignoreMetadata was true, which is now not the case. >> >> Thanks, >> >> Brian >> >> On Dec 8, 2016, at 5:43 PM, Brian Burkhalter wrote: >> >>> Here is an updated patch >>> >>> http://cr.openjdk.java.net/~bpb/8154058/webrev.02/ >>> >>> which differs from the previous one only in terms of the test which has been updated to verify that: >>> >>> 1) essential metadata are not affected by the settings of ignoreMetadata and readUnknownTags; >>> 2) non-essential metadata with a recognized tag are suppressed by ignoreMetadata == true, but when ignoreMetadata == false are unaffected by the setting of readUnknownTags; >>> 3) metadata with an unrecognized tag are read if and only if ignoreMetadata == false and readUnknownTags == true. >>> >>> Thanks, >>> >>> Brian >>> >>> On Dec 8, 2016, at 1:43 PM, Phil Race wrote: >>> >>>> I think that spec. looks good so you can at least proceed with the CCC. >>>> >>>> -phil. >>>> >>>> On 12/07/2016 01:07 PM, Brian Burkhalter wrote: >>>>> Reprising thread [1]. >>>>> >>>>> Issue: http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html >>>>> Patch: http://cr.openjdk.java.net/~bpb/8154058/webrev.01/ >>>>> Doc: http://cr.openjdk.java.net/~bpb/8154058/tiff_metadata.html#MetadataIssuesRead >>>>> >>>>> Note that this is a preliminary version as an improved test will be needed. A CCC review will be in order however so it would be best to get far enough to submit a request. >>>>> >>>>> Thanks, >>>>> >>>>> Brian >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/2d-dev/2016-August/007449.html From prasanta.sadhukhan at oracle.com Wed Dec 14 09:40:13 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 14 Dec 2016 15:10:13 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: <71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com> References:

<06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> <71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com> Message-ID: Hi Phil, On 12/14/2016 1:40 AM, Phil Race wrote: > Hi, > > Thanks for checking that. > > The bit I don't like here is that the end-user can then no longer ask > for collation > at all on Linux even though it has some chance of working on some > versions. > This is the case even without my change and collate option is disabled for PrinterJob. My fix (?) makes it disabled for PrintJob too. > Hmm .. > > http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set > --- > In our cups class we were doing a cupsAddOption("copies", "2",.. and > cupsAddOption("Collate", "True", .. commands (see examples below). It > turns out the the cups "copies" command was killing the Collating if > it set to 2. Like the orientation postscript/cups conflict you need to > set the cups copies value to 1 to get the collation to work. The > postscript file already knows its going to print out, for example 2 > copies. > --- > > We set NumCopies in the Postscript along with collate :- > mPSStream.print(isCollated() ? " /Collate true":""); > mPSStream.print(" /NumCopies " +getCopiesInt()); > > So when we exec we also do "lp -# 2 .. " or whatever do set copies. > We are setting copies to 1 in http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l735. One thing is that, in my testing in ubuntu14.04 "collation" is working and "uncollation" is not working. When I print 2 copies and do not select "collate" option in printer dialog [I enabled collate option by commenting out the isLinux check from http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] then, it prints Page 0, Page 1, Page 0, Page 1 [same as, when I checked "collate" option] in my Ricoh printer in double-sided print. I think for uncollation, it should print Page 0, Page 0 back-to-back in 1 copy and Page1-Page1 in another copy, right? Regards Prasanta > Does it help if we stop doing that for the collated case ? > > > -phil. > > On 12/10/2016 12:19 AM, Prasanta Sadhukhan wrote: >> >> >> >> On 12/10/2016 4:58 AM, Phil Race wrote: >>> Regarding being hard-coded for "Selection", the point there is that >>> in the AWT code path we always generate Postscript, whereas in the >>> 2D path we may send some other content. Since we generate Postscript >>> my instinct here is that Collate should always work since that gets >>> embedded in the Postscript. The CUPS filter should then do whatever >>> is necessary to generate the right number of collated or uncollated >>> copies for the printer. I tracked down the changeset that has the >>> code you reference >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you >>> read the bug report for that : >>> https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes >>> clear (sort of) that this was a workaround for the oddity that >>> Collate worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea >>> was to stop saying it was supported. That is very annoying of course >>> and I'd love to know if we've rechecked from the source that "CUPS >>> does not report collate as a supported attribute" >> I checked getAttMap (response received from cups) >> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767 >> and there is no "collate-supported" attribute in there. >>> It is mentioned in CUPS docs. >>> https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS >>> Also the fix you are proposing doesn't seem to change anything that >>> will help the test. It expects Collate to be checked. Doesn't it ? >> The fix does not directly help the test. The idea is to have the test >> call first isAttributeCategorySupprted(SheetCollate.class) and only >> execute the test if it is supported. It is mentioned inthe bug report. >> Since, now our code returns false for SheetCollate attribute, my fix >> will disable the collate option to prevent anomaly of returning false >> for support but enabling the collate option. >> >> Regards >> Prasanta >>> -phil. >>> >>> >>> On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: >>>> >>>> Hi All, >>>> >>>> In continuation with the below mail, the issue is "collate" option >>>> is not checked for linux. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 >>>> >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ >>>> >>>> Proposed fix is to disable collate option for linux in printer dialog. >>>> >>>> Regards >>>> Prasanta >>>> On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi Phil, >>>>> >>>>> I was investigating JDK-8170352: The collate option is not checked >>>>> and I found that CUPS does not report collate as supported attribute. >>>>> >>>>> It is removed from printRequestAttrib >>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >>>>> so we do not look for collate-supported attribute in CUPS. Infact, >>>>> getAttMap does not have any "collate-supported" attribute too!! >>>>> Also, this code >>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >>>>> has been added [for 8016737] >>>>> to remove SheetCollate from supported attributes. >>>>> >>>>> In light of this, I think we should disabled collate option from >>>>> our print dialog even for Toolkit based PrintJob. It seems, from >>>>> this code >>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >>>>> it is enabled if we specify in testcase >>>>> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >>>>> /in which case isAWT set to true. >>>>> even though selection is determined by attribute support >>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >>>>> >>>>> I could not find why it is hardcoded to setEnabled(true) for >>>>> "Selection". Do you know? mercurial history shows that line from >>>>> jdk7 and I could not find previous history. >>>>> I think there also, we should check for "scSupported" to enable >>>>> sheetcollate? Anyways, "Selection" option is not there in linux. >>>>> Please let me know your views. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Wed Dec 14 09:45:47 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 09:45:47 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. In-Reply-To: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> References: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> Message-ID: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> Hi Phil, thanks for looking at my change! Updated webrev: http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.02/ Best regards, Goetz. > (1) I notice you prepared the webrev against jdk9/dev. > It should be prepared against jdk9/client - which is where it should also be > pushed. I'll move to client. > (2) However most of these changes are in a 3rd party imported library. > We don't edit these unless there is a good reason. Instead we would report > them to up-stream and import next time we upgrade. > So only a subset of these make sense to fix in JDK .. otherwise we'll just blow > them away when we upgrade. > > In particular this means the changes to > (a) harfbuzz > (b) littlecms > which are actively maintained externally and we upgrade periodically. OK, I removed these changes. But submitting upstream will probably mean that I don't get the fixes into jdk9 any more. > Local changes may make sense in > (c) ICU layout > (d) libjpeg6b > since these are at a different stage in their life > > Having said that see the comments in-line. > > -phil > > > On 12/08/2016 11:57 PM, Lindenmaier, Goetz wrote: > > Changes in detail: > > hb-ot-font.cc > Looks like assignment instead of compare. Use extra if(). > This is a stylistic change. You will need to convince Behdad. Yes. The code scan complains about it, but it was correct. But I would like to get it fixed. It helps to get these false positives out of the way, as we have to do these scans over and over again, and maybe other users of openJdk, too. > hb-ot_layout-gpos-table.hh > valueFormat is passed to apply(), where it is used as an array with two > elements: > line 621: valueFormats[1].get_len(); > It was correct as there are actually two fields in the struct that have the > same layout as an array. > This also needs to go to the harfbuzz mailing list. OK, I'll try to run the scan on the harfbuzz sources and fix stuff there. But I don't think I'll get any changes I make in harfbuzz into jdk9 at this stage. So shouldn't I push it here, anyways? > ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h > In ThaiShaping.cpp:307 conState is passed to getNextState() where it is > in the end used to index to thaiStateTable. > thaiStateTable has 52 elements. But conState is initialized to 0xFF == > 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access. > This is not entered unconditionally, so consState should be updated > before we reach there. However the check is harmless so should be fine. Thanks. > OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with > index < scriptCodeCount, but only contains scriptCodeCount-1 elements. > I added a size entry to the enums, and use that for sizing the array and > checking the size. > I am fairly sure you didn't include all of these changes in the webrev. > I see only the use for sizing the array. Sorry, the comment is mixed up. I added the size entry to the enum for the conState issue. The array size OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is needed because OpenTypeLayoutEngine::scriptTags is accessed with an index that runs to scriptCodeCount. That's the case because it's dual to indicClassTables if I remember correctly. See OpenTypeLayoutEngine::getScriptTag() that potentially accesses scriptTags[] at scriptCodeCount-1. > jctrans. > if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it > will access MCU_buffer[0]. (jcphuff.c:487) > It is hard to prove with static analysis but it seems like the block above does the > initialisation. > So I don't strongly object to this but I also don't see that the case for it is > proven. > > cmserr.c > Must check return value of ftell. > > cmsgamma.c > Out/out/in are used as arrays in called function. > > cmslut.c > Out[] may be used uninitialized. > > cmstypes.c > Must check return value of Tell. The negative outcome should not be > passed to Seek. > > cmsxform.c > Using uninitialized element of array wIn when calling *p->FromInput. > (The function pointer resolves to Pack1Byte.) > Using uninitialized element of array fIn when calling *p-> > FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) > Using uninitialized element of array fIn when calling *p-> > FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) > All of the above should be proposed to the upstream littlecms list. Ok, I'll try that. But that leaves the same issue: it will not reach jdk9 anymore? > PLATFORM_API_LinuxOS_ALSA_Ports.c > Using uninitialized element of array controls when calling *creator-> > newCompoundControl. (The function pointer resolves to > PORT_NewCompoundControl.) > > So it seems like the elements at indices from controlCount to 10 may not > be initialised but I don't see how this would be a problem since > PORT_NewCompoundControl > has no hardwired "10" .. it just uses controlCount. > In any case this would seem better addressed by the same kind of memset > after stack allocation that you proposed for the jpeg case. Fixed. (I thought it's cheaper to initialize only the rest, and more simple for the C-compiler to remove where useless.) From sergey.bylokhov at oracle.com Wed Dec 14 18:28:55 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 14 Dec 2016 21:28:55 +0300 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. In-Reply-To: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> References: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> Message-ID: Hello. >> So it seems like the elements at indices from controlCount to 10 may not >> be initialised but I don't see how this would be a problem since >> PORT_NewCompoundControl >> has no hardwired "10" .. it just uses controlCount. >> In any case this would seem better addressed by the same kind of memset >> after stack allocation that you proposed for the jpeg case. > Fixed. (I thought it's cheaper to initialize only the rest, and more simple > for the C-compiler to remove where useless.) It seems that some other implementations of PORT_NewCompoundControl can have the same issue, like in : PLATFORM_API_BsdOS_ALSA_Ports.c and PLATFORM_API_SolarisOS_Ports.c. Should we apply the same memset there to make them in sync? From philip.race at oracle.com Wed Dec 14 18:37:02 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Dec 2016 10:37:02 -0800 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. In-Reply-To: <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> References: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> Message-ID: +1 to the changes you have here. Comments on the upstream issues in-line. -phil. On 12/14/2016 01:45 AM, Lindenmaier, Goetz wrote: > Hi Phil, > > thanks for looking at my change! > Updated webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.02/ > > Best regards, > Goetz. > >> (1) I notice you prepared the webrev against jdk9/dev. >> It should be prepared against jdk9/client - which is where it should also be >> pushed. > I'll move to client. > >> (2) However most of these changes are in a 3rd party imported library. >> We don't edit these unless there is a good reason. Instead we would report >> them to up-stream and import next time we upgrade. >> So only a subset of these make sense to fix in JDK .. otherwise we'll just blow >> them away when we upgrade. >> >> In particular this means the changes to >> (a) harfbuzz >> (b) littlecms >> which are actively maintained externally and we upgrade periodically. > OK, I removed these changes. But submitting upstream will probably mean > that I don't get the fixes into jdk9 any more. > >> Local changes may make sense in >> (c) ICU layout >> (d) libjpeg6b >> since these are at a different stage in their life >> >> Having said that see the comments in-line. >> >> -phil >> >> >> On 12/08/2016 11:57 PM, Lindenmaier, Goetz wrote: >> >> Changes in detail: >> >> hb-ot-font.cc >> Looks like assignment instead of compare. Use extra if(). >> This is a stylistic change. You will need to convince Behdad. > Yes. The code scan complains about it, but it was correct. But I would > like to get it fixed. It helps to get these false positives out of the way, as > we have to do these scans over and over again, and maybe other users of > openJdk, too. > >> hb-ot_layout-gpos-table.hh >> valueFormat is passed to apply(), where it is used as an array with two >> elements: >> line 621: valueFormats[1].get_len(); >> It was correct as there are actually two fields in the struct that have the >> same layout as an array. >> This also needs to go to the harfbuzz mailing list. > OK, I'll try to run the scan on the harfbuzz sources and fix stuff there. > But I don't think I'll get any changes I make in harfbuzz into jdk9 at > this stage. So shouldn't I push it here, anyways? There is about a 90% chance I will push an updated harfbuzz into JDK9 So your changes will get blown away But if you get them into upstream soon then I'd pull them in that way. If upstream says no .. then I would not want to maintain these in JDK. > >> ScriptAndLanguageTags.cpp, ThaiShaping.cpp/.h >> In ThaiShaping.cpp:307 conState is passed to getNextState() where it is >> in the end used to index to thaiStateTable. >> thaiStateTable has 52 elements. But conState is initialized to 0xFF == >> 255 in ThaiShaping.cpp:296. This can result in an out-of-bounds access. >> This is not entered unconditionally, so consState should be updated >> before we reach there. However the check is harmless so should be fine. > Thanks. > >> OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is accessed with >> index < scriptCodeCount, but only contains scriptCodeCount-1 elements. >> I added a size entry to the enums, and use that for sizing the array and >> checking the size. >> I am fairly sure you didn't include all of these changes in the webrev. >> I see only the use for sizing the array. > Sorry, the comment is mixed up. I added the size entry to the enum for the conState issue. > The array size OpenTypeLayoutEngine::scriptTags[scriptCodeCount] is needed because > OpenTypeLayoutEngine::scriptTags is accessed with an index that runs to scriptCodeCount. > That's the case because it's dual to indicClassTables if I remember correctly. > See OpenTypeLayoutEngine::getScriptTag() that potentially accesses scriptTags[] at > scriptCodeCount-1. Ok. >> jctrans. >> if cinfo->entropy->encode_mcu resolves to encode_mcu_AC_first() it >> will access MCU_buffer[0]. (jcphuff.c:487) >> It is hard to prove with static analysis but it seems like the block above does the >> initialisation. >> So I don't strongly object to this but I also don't see that the case for it is >> proven. >> >> cmserr.c >> Must check return value of ftell. >> >> cmsgamma.c >> Out/out/in are used as arrays in called function. >> >> cmslut.c >> Out[] may be used uninitialized. >> >> cmstypes.c >> Must check return value of Tell. The negative outcome should not be >> passed to Seek. >> >> cmsxform.c >> Using uninitialized element of array wIn when calling *p->FromInput. >> (The function pointer resolves to Pack1Byte.) >> Using uninitialized element of array fIn when calling *p-> >> FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) >> Using uninitialized element of array fIn when calling *p-> >> FromInputFloat. (The function pointer resolves to PackDoublesFromFloat.) >> All of the above should be proposed to the upstream littlecms list. > Ok, I'll try that. But that leaves the same issue: it will not reach jdk9 anymore? It still might. Again we like to keep these libraries up-to-date. > >> PLATFORM_API_LinuxOS_ALSA_Ports.c >> Using uninitialized element of array controls when calling *creator-> >> newCompoundControl. (The function pointer resolves to >> PORT_NewCompoundControl.) >> >> So it seems like the elements at indices from controlCount to 10 may not >> be initialised but I don't see how this would be a problem since >> PORT_NewCompoundControl >> has no hardwired "10" .. it just uses controlCount. >> In any case this would seem better addressed by the same kind of memset >> after stack allocation that you proposed for the jpeg case. > Fixed. (I thought it's cheaper to initialize only the rest, and more simple > for the C-compiler to remove where useless.) > From avinuela at gmv.com Wed Dec 14 15:46:42 2016 From: avinuela at gmv.com (=?iso-8859-1?Q?Alvaro_Vi=F1uela_Carnicero?=) Date: Wed, 14 Dec 2016 15:46:42 +0000 Subject: [OpenJDK 2D-Dev] PostScript PrintJob LANDSCAPE computes wrong value for getStringBounds Message-ID: <1362D213B7103346A591F9E31529E5C24AC6D2@ptmexchange3.gmv.es> Hello, We have been experienced misalignment of text when using a StreamPrintServiceFactory or StreamPrintService to create a print job for printing (text and graphics) to postscript with landscape attribute. A similar error was reported in JBS with title: "PostScript PrintJob LANDSCAPE computes wrong value for getStringBounds" https://bugs.openjdk.java.net/browse/JDK-8159061?jql=labels%20%3D%20jdk-port Using the Bugtest provided in this bug, we could verify correct behaviour on opend-jdk_1.6.0_24, but not in opend-jdk_1.8.0_65 and opend-jdk_1.8.0_111 as in our application that was correctly printing in old openjdk version. As also mentioned in reported bug, error is not reproducible (as in our application too) using jdk binaries. Bug was closed because it is not reproducible on jdk binaries. Is there any possibility to solved this bug on future openjdk releases?. Are we forced to use jdk binaries to get this issue solved?. Thank you very much in advance for your help. Best regards, ?lvaro. P Please consider the environment before printing this e-mail. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Wed Dec 14 19:15:08 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 14 Dec 2016 20:15:08 +0100 Subject: [OpenJDK 2D-Dev] RFR(S): 8171248: Minor HarfBuzz fixes to pacify Coverity code scan Message-ID: Hi, can I please have a review for the following small changes which fix some Coverity code scan issues in the Harfbuzz library: https://bugs.openjdk.java.net/browse/JDK-8171248 http://cr.openjdk.java.net/~simonis/webrevs/2016/8171248/ These changes only make sense if they are also accepted in the upstream HarfBuzz repository. I've therefore send out a pull request with the same changes and kindly requested Behdad to accept them upstream: https://github.com/behdad/harfbuzz/pull/377 Following are the details of the fix: we regularly run Coverity code scans on the OpenJDK sources and recently discovered two issues with HarfBuzz. While the discovered issues are not real errors, we think that fixing them my be nevertheless worthwile in order to increase the readability of the source code. We just wanted to ask, if you are willing to accept these changes in the upstream HarfBuzz repository because only then it would make sense to also fix them in the OpenJDK copy of HarfBuzz. The first issue found by Coverity is the last of the following four lines from src/hb-ot-font.cc: if (!subtable) subtable = cmap->find_subtable (0, 2); if (!subtable) subtable = cmap->find_subtable (0, 1); if (!subtable) subtable = cmap->find_subtable (0, 0); if (!subtable)(subtable = cmap->find_subtable (3, 0)) && (symbol = true); >From the whole context it really took me some time to understand that 'symbol' should only be set to true if 'subtable' is set from 'cmap->find_subtable (3, 0)'. Coverity reports an "assignment instead of compare" which is a false positive, but we think the could would be much more readable if changed to look as follows: if (!subtable) { subtable = cmap->find_subtable (3, 0); if (subtable) symbol = true; } The second issue is related to the following definition in src/hb-ot-layout-gpos-table.hh: ValueFormat valueFormat1; /* Defines the types of data in * ValueRecord1--for the first glyph * in the pair--may be zero (0) */ ValueFormat valueFormat2; /* Defines the types of data in * ValueRecord2--for the second glyph * in the pair--may be zero (0) */ Throughout hb-ot-layout-gpos-table.hh, '&valueFormat1' is used as if it were an array of two ValueFormat objects. While extremely unlikely, a compiler could theoretically insert padding between 'valueFormat1' and 'valueFormat2' which would make the code incorrect. We would therefore propose to simply change the previous definiton into a real array: ValueFormat valueFormat[2]; /* [0] Defines the types of data in * ValueRecord1--for the first glyph * in the pair--may be zero (0) */ /* [1] Defines the types of data in * ValueRecord2--for the second glyph * in the pair--may be zero (0) */ and change the code which uses 'valueFormat' accordingly. Thank youand best regards, Volker From philip.race at oracle.com Wed Dec 14 21:16:07 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Dec 2016 13:16:07 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8039273: Font related files should not be modified in ${java.home}/lib In-Reply-To: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com> References: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com> Message-ID: <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com> The fix has been updated. http://cr.openjdk.java.net/~prr/8039273.1/ 2nd reviewer anyone ? -phil. On 12/09/2016 09:44 AM, Naoto Sato wrote: > Hi Phil, > > In FontConfiguration.java, line 193-195 can be inserted just after > line 191, as fontConfigFile is guaranteed to be non-null if > userConfigFile is non null. Otherwise it looks good to me. > > Naoto > > On 12/8/16 12:01 PM, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273 >> Webrev : http://cr.openjdk.java.net/~prr/8039273/ >> >> A CCC request and documentation are being prepared. >> >> -phil From philip.race at oracle.com Wed Dec 14 21:20:59 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Dec 2016 13:20:59 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: References:

<06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> <71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com> Message-ID: <65b9d9c0-6a1a-3e47-761b-27aebe206488@oracle.com> On 12/14/2016 01:40 AM, Prasanta Sadhukhan wrote: > > Hi Phil, > > > On 12/14/2016 1:40 AM, Phil Race wrote: >> Hi, >> >> Thanks for checking that. >> >> The bit I don't like here is that the end-user can then no longer ask >> for collation >> at all on Linux even though it has some chance of working on some >> versions. >> > This is the case even without my change and collate option is disabled > for PrinterJob. > My fix (?) makes it disabled for PrintJob too. Ah yes. >> Hmm .. >> >> http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set >> --- >> In our cups class we were doing a cupsAddOption("copies", "2",.. and >> cupsAddOption("Collate", "True", .. commands (see examples below). It >> turns out the the cups "copies" command was killing the Collating if >> it set to 2. Like the orientation postscript/cups conflict you need >> to set the cups copies value to 1 to get the collation to work. The >> postscript file already knows its going to print out, for example 2 >> copies. >> --- >> >> We set NumCopies in the Postscript along with collate :- >> mPSStream.print(isCollated() ? " /Collate true":""); >> mPSStream.print(" /NumCopies " +getCopiesInt()); >> >> So when we exec we also do "lp -# 2 .. " or whatever do set copies. >> > We are setting copies to 1 in > http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l735. OK. > > One thing is that, in my testing in ubuntu14.04 "collation" is working > and "uncollation" is not working. When I print 2 copies and do not > select "collate" option in printer dialog [I enabled collate option by > commenting out the isLinux check from > http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] > > then, it prints Page 0, Page 1, Page 0, Page 1 [same as, when I > checked "collate" option] in my Ricoh printer in double-sided print. I > think for uncollation, it should print Page 0, Page 0 back-to-back in > 1 copy and Page1-Page1 in another copy, right? Yes, uncollated should be as you say. What is going on ??? Is this for PrinterJob or PrintJob or both ? I need to configure a printer on my Ubuntu .. I lost them recently when my hard drive went bad. -phil.. > > Regards > Prasanta >> Does it help if we stop doing that for the collated case ? >> >> >> -phil. >> >> On 12/10/2016 12:19 AM, Prasanta Sadhukhan wrote: >>> >>> >>> >>> On 12/10/2016 4:58 AM, Phil Race wrote: >>>> Regarding being hard-coded for "Selection", the point there is that >>>> in the AWT code path we always generate Postscript, whereas in the >>>> 2D path we may send some other content. Since we generate >>>> Postscript my instinct here is that Collate should always work >>>> since that gets embedded in the Postscript. The CUPS filter should >>>> then do whatever is necessary to generate the right number of >>>> collated or uncollated copies for the printer. I tracked down the >>>> changeset that has the code you reference >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you >>>> read the bug report for that : >>>> https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes >>>> clear (sort of) that this was a workaround for the oddity that >>>> Collate worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the idea >>>> was to stop saying it was supported. That is very annoying of >>>> course and I'd love to know if we've rechecked from the source that >>>> "CUPS does not report collate as a supported attribute" >>> I checked getAttMap (response received from cups) >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767 >>> and there is no "collate-supported" attribute in there. >>>> It is mentioned in CUPS docs. >>>> https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS >>>> Also the fix you are proposing doesn't seem to change anything that >>>> will help the test. It expects Collate to be checked. Doesn't it ? >>> The fix does not directly help the test. The idea is to have the >>> test call first isAttributeCategorySupprted(SheetCollate.class) and >>> only execute the test if it is supported. It is mentioned inthe bug >>> report. >>> Since, now our code returns false for SheetCollate attribute, my fix >>> will disable the collate option to prevent anomaly of returning >>> false for support but enabling the collate option. >>> >>> Regards >>> Prasanta >>>> -phil. >>>> >>>> >>>> On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: >>>>> >>>>> Hi All, >>>>> >>>>> In continuation with the below mail, the issue is "collate" option >>>>> is not checked for linux. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ >>>>> >>>>> Proposed fix is to disable collate option for linux in printer dialog. >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi Phil, >>>>>> >>>>>> I was investigating JDK-8170352: The collate option is not >>>>>> checked and I found that CUPS does not report collate as >>>>>> supported attribute. >>>>>> >>>>>> It is removed from printRequestAttrib >>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >>>>>> so we do not look for collate-supported attribute in CUPS. >>>>>> Infact, getAttMap does not have any "collate-supported" attribute >>>>>> too!! >>>>>> Also, this code >>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >>>>>> has been added [for 8016737] >>>>>> to remove SheetCollate from supported attributes. >>>>>> >>>>>> In light of this, I think we should disabled collate option from >>>>>> our print dialog even for Toolkit based PrintJob. It seems, from >>>>>> this code >>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >>>>>> it is enabled if we specify in testcase >>>>>> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >>>>>> /in which case isAWT set to true. >>>>>> even though selection is determined by attribute support >>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >>>>>> >>>>>> I could not find why it is hardcoded to setEnabled(true) for >>>>>> "Selection". Do you know? mercurial history shows that line from >>>>>> jdk7 and I could not find previous history. >>>>>> I think there also, we should check for "scSupported" to enable >>>>>> sheetcollate? Anyways, "Selection" option is not there in linux. >>>>>> Please let me know your views. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Dec 14 23:25:17 2016 From: philip.race at oracle.com (Phil Race) Date: Wed, 14 Dec 2016 15:25:17 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR 8170352: The collate option is not checked In-Reply-To: <65b9d9c0-6a1a-3e47-761b-27aebe206488@oracle.com> References:

<06b1dd80-c128-4eeb-ae58-2ede9badf60c@oracle.com> <5bac0cf5-f5a8-7a31-1416-f141c9d6ba0d@oracle.com> <71938210-24da-b2f0-6256-bf8d65321c3c@oracle.com> <65b9d9c0-6a1a-3e47-761b-27aebe206488@oracle.com> Message-ID: With a hacked JDK 9 (so that collate is not disabled) I can print either collated or un-collated. This is on Ubuntu 16.04 with HP CP4525 testing this is a pain since the spooler hangs in "processing" after every job and I need to kill the process and restart the printer. That is not a JDK problem since (a) outside our scope and (b) same problem with libreoffice printing .. But it makes me think that we should be looking at reverting 8016737 .. not extending it. -phil. On 12/14/2016 01:20 PM, Phil Race wrote: > > > On 12/14/2016 01:40 AM, Prasanta Sadhukhan wrote: >> >> Hi Phil, >> >> >> On 12/14/2016 1:40 AM, Phil Race wrote: >>> Hi, >>> >>> Thanks for checking that. >>> >>> The bit I don't like here is that the end-user can then no longer >>> ask for collation >>> at all on Linux even though it has some chance of working on some >>> versions. >>> >> This is the case even without my change and collate option is >> disabled for PrinterJob. >> My fix (?) makes it disabled for PrintJob too. > > Ah yes. >>> Hmm .. >>> >>> http://stackoverflow.com/questions/31056278/postscript-file-is-not-collating-when-cups-copies-is-set >>> --- >>> In our cups class we were doing a cupsAddOption("copies", "2",.. and >>> cupsAddOption("Collate", "True", .. commands (see examples below). >>> It turns out the the cups "copies" command was killing the Collating >>> if it set to 2. Like the orientation postscript/cups conflict you >>> need to set the cups copies value to 1 to get the collation to work. >>> The postscript file already knows its going to print out, for >>> example 2 copies. >>> --- >>> >>> We set NumCopies in the Postscript along with collate :- >>> mPSStream.print(isCollated() ? " /Collate true":""); >>> mPSStream.print(" /NumCopies " +getCopiesInt()); >>> >>> So when we exec we also do "lp -# 2 .. " or whatever do set copies. >>> >> We are setting copies to 1 in >> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l735. > > OK. > >> >> One thing is that, in my testing in ubuntu14.04 "collation" is >> working and "uncollation" is not working. When I print 2 copies and >> do not select "collate" option in printer dialog [I enabled collate >> option by commenting out the isLinux check from >> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >> >> then, it prints Page 0, Page 1, Page 0, Page 1 [same as, when I >> checked "collate" option] in my Ricoh printer in double-sided print. >> I think for uncollation, it should print Page 0, Page 0 back-to-back >> in 1 copy and Page1-Page1 in another copy, right? > > Yes, uncollated should be as you say. > What is going on ??? Is this for PrinterJob or PrintJob or both ? > I need to configure a printer on my Ubuntu .. I lost them recently > when my hard drive went bad. > > -phil.. > >> >> Regards >> Prasanta >>> Does it help if we stop doing that for the collated case ? >>> >>> >>> -phil. >>> >>> On 12/10/2016 12:19 AM, Prasanta Sadhukhan wrote: >>>> >>>> >>>> >>>> On 12/10/2016 4:58 AM, Phil Race wrote: >>>>> Regarding being hard-coded for "Selection", the point there is >>>>> that in the AWT code path we always generate Postscript, whereas >>>>> in the 2D path we may send some other content. Since we generate >>>>> Postscript my instinct here is that Collate should always work >>>>> since that gets embedded in the Postscript. The CUPS filter should >>>>> then do whatever is necessary to generate the right number of >>>>> collated or uncollated copies for the printer. I tracked down the >>>>> changeset that has the code you reference >>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/dead66347eca If you >>>>> read the bug report for that : >>>>> https://bugs.openjdk.java.net/browse/JDK-8016737 then it becomes >>>>> clear (sort of) that this was a workaround for the oddity that >>>>> Collate worked on Ubuntu 12.04 but not on Ubuntu 13.04, so the >>>>> idea was to stop saying it was supported. That is very annoying of >>>>> course and I'd love to know if we've rechecked from the source >>>>> that "CUPS does not report collate as a supported attribute" >>>> I checked getAttMap (response received from cups) >>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767 >>>> and there is no "collate-supported" attribute in there. >>>>> It is mentioned in CUPS docs. >>>>> https://opensource.apple.com/source/cups/cups-62/doc/spm.shtml?txt#CONSTANTS >>>>> Also the fix you are proposing doesn't seem to change anything >>>>> that will help the test. It expects Collate to be checked. Doesn't >>>>> it ? >>>> The fix does not directly help the test. The idea is to have the >>>> test call first isAttributeCategorySupprted(SheetCollate.class) and >>>> only execute the test if it is supported. It is mentioned inthe bug >>>> report. >>>> Since, now our code returns false for SheetCollate attribute, my >>>> fix will disable the collate option to prevent anomaly of returning >>>> false for support but enabling the collate option. >>>> >>>> Regards >>>> Prasanta >>>>> -phil. >>>>> >>>>> >>>>> On 12/09/2016 12:22 AM, Prasanta Sadhukhan wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> In continuation with the below mail, the issue is "collate" >>>>>> option is not checked for linux. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170352 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8170352/webrev.00/ >>>>>> >>>>>> Proposed fix is to disable collate option for linux in printer >>>>>> dialog. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 12/8/2016 4:23 PM, Prasanta Sadhukhan wrote: >>>>>>> >>>>>>> Hi Phil, >>>>>>> >>>>>>> I was investigating JDK-8170352: The collate option is not >>>>>>> checked and I found that CUPS does not report collate as >>>>>>> supported attribute. >>>>>>> >>>>>>> It is removed from printRequestAttrib >>>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l167] >>>>>>> so we do not look for collate-supported attribute in CUPS. >>>>>>> Infact, getAttMap does not have any "collate-supported" >>>>>>> attribute too!! >>>>>>> Also, this code >>>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1062] >>>>>>> has been added [for 8016737] >>>>>>> to remove SheetCollate from supported attributes. >>>>>>> >>>>>>> In light of this, I think we should disabled collate option from >>>>>>> our print dialog even for Toolkit based PrintJob. It seems, from >>>>>>> this code >>>>>>> http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1251 >>>>>>> it is enabled if we specify in testcase >>>>>>> /job.setDefaultSelection(JobAttributes.DefaultSelectionType.SELECTION); >>>>>>> /in which case isAWT set to true. >>>>>>> even though selection is determined by attribute support >>>>>>> [http://hg.openjdk.java.net/jdk9/client/jdk/file/a21bac70753d/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1320] >>>>>>> >>>>>>> I could not find why it is hardcoded to setEnabled(true) for >>>>>>> "Selection". Do you know? mercurial history shows that line from >>>>>>> jdk7 and I could not find previous history. >>>>>>> I think there also, we should check for "scSupported" to enable >>>>>>> sheetcollate? Anyways, "Selection" option is not there in linux. >>>>>>> Please let me know your views. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Thu Dec 15 05:50:59 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Thu, 15 Dec 2016 11:20:59 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8170578: The Pages Range From in print dialog is disabled Message-ID: <39f21e6d-78fb-6486-0260-620f42a63ccb@oracle.com> Hi All, Please review a testbug fix for jdk9 for an issue where it it seen that PageRanges option is disabled in printer dialog in ubuntu16.10. Bug: https://bugs.openjdk.java.net/browse/JDK-8170578 webrev: http://cr.openjdk.java.net/~psadhukhan/8170578/webrev.00/ Issue was, in ubuntu16.10 the attribute map [obtained here http://hg.openjdk.java.net/jdk9/client/jdk/file/dc658d7dde90/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1767] does not have "pageranges-supported" attribute returned by CUPS so this category is not added to supported categories [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/unix/classes/sun/print/IPPPrintService.java#l1030] so isAttributeCategorySupported() called by ServiceDialog returns false [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java.desktop/share/classes/sun/print/ServiceDialog.java#l1141] resulting in PageRanges option getting disabled. Fix is to check if PageRanges category is supported in underlying platform, only then proceed with the test. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergey.bylokhov at oracle.com Thu Dec 15 13:16:15 2016 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 15 Dec 2016 16:16:15 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8039273: Font related files should not be modified in ${java.home}/lib In-Reply-To: <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com> References: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com> <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com> Message-ID: Hi, Phil. > The fix has been updated. > http://cr.openjdk.java.net/~prr/8039273.1/ > 2nd reviewer anyone ? Looks fine. I assume that SecurityException from File.exists() is expected, or the code is executed under doPriviliged() block. > > -phil. > > > On 12/09/2016 09:44 AM, Naoto Sato wrote: >> Hi Phil, >> >> In FontConfiguration.java, line 193-195 can be inserted just after line 191, as fontConfigFile is guaranteed to be non-null if userConfigFile is non null. Otherwise it looks good to me. >> >> Naoto >> >> On 12/8/16 12:01 PM, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273 >>> Webrev : http://cr.openjdk.java.net/~prr/8039273/ >>> >>> A CCC request and documentation are being prepared. >>> >>> -phil > From arturrataj at gmail.com Thu Dec 15 13:30:41 2016 From: arturrataj at gmail.com (Artur Rataj) Date: Thu, 15 Dec 2016 14:30:41 +0100 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux Message-ID: Hello, I discussed the problem on dev-build http://mail.openjdk.java.net/pipermail/build-dev/2016-December/018353.html but have been redirected here, thanks Eric! I would like to ask why OpenJDK on Linux has by default an inferior font rendering quality, when there are OpenJDK variants also for Linux which can render the same fonts with a very high quality. I described the problem in more detail and with images here: https://stackoverflow.com/questions/41149451/a-method-of-getting-a-linux-jdk -tarball-with-freetype-like-font-rendering Best regards, Artur -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 15 22:26:59 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Dec 2016 14:26:59 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8039273: Font related files should not be modified in ${java.home}/lib In-Reply-To: References: <5f67a5f7-1e12-64fa-0c33-5413769b461d@oracle.com> <15bc5a48-1644-cf33-3e57-49d08b7f07d4@oracle.com> Message-ID: <49f06120-8c70-ff35-5726-8874a0d0a74e@oracle.com> This whole fontconfig lookup logic is in a doPrivileged. And the code is already opening the directory in the findImpl method called just below the new exists() call. -phil. On 12/15/2016 05:16 AM, Sergey Bylokhov wrote: > Hi, Phil. > >> The fix has been updated. >> http://cr.openjdk.java.net/~prr/8039273.1/ >> 2nd reviewer anyone ? > Looks fine. I assume that SecurityException from File.exists() is expected, or the code is executed under doPriviliged() block. > >> -phil. >> >> >> On 12/09/2016 09:44 AM, Naoto Sato wrote: >>> Hi Phil, >>> >>> In FontConfiguration.java, line 193-195 can be inserted just after line 191, as fontConfigFile is guaranteed to be non-null if userConfigFile is non null. Otherwise it looks good to me. >>> >>> Naoto >>> >>> On 12/8/16 12:01 PM, Phil Race wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039273 >>>> Webrev : http://cr.openjdk.java.net/~prr/8039273/ >>>> >>>> A CCC request and documentation are being prepared. >>>> >>>> -phil From philip.race at oracle.com Thu Dec 15 23:54:07 2016 From: philip.race at oracle.com (Phil Race) Date: Thu, 15 Dec 2016 15:54:07 -0800 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux In-Reply-To: References: Message-ID: <032b301f-b046-61cc-1d48-1e920b3665c2@oracle.com> Yes, this is the right place. As I started to say on that list, it seems to me that this may be a font-specific problem. Fonts have hints. I've seen similar issues when the hints are poor. Unfortunately there is no easy way to know if they are poor. Some clients/apps/rendering systems by policy ignore hints so they may look OK, but then they may not look as good on a case where the hints were good and important. If I knew exactly what font you were using I could look at it. Note that Java 2D most definitely does use a fontrasteriser. Oracle's builds use a one that ships with the JDK binaries (not source) All openjdk builds use freetype. On Linux this means Ubuntu's openjdk will use the exact same copy of freetype as used for rendering the rest of your desktop! So if it looks bad with that, it will look bad on your desktop unless the font is interpreted differently. I expect Android Studio uses the same platform freetype, and if you are using the same font there that is why I think it may be down to hinting. I looked through all the fonts on 16.04 but didn't see a problem with "#" So (off-list) email me the exact font and the size and rendering options you are using. -phil. On 12/15/2016 05:30 AM, Artur Rataj wrote: > Hello, I discussed the problem on dev-build > > http://mail.openjdk.java.net/ > pipermail/build-dev/2016-December/018353.html > > but have been redirected here, thanks Eric! > > I would like to ask why OpenJDK on Linux has by default an inferior > font rendering quality, when there are OpenJDK variants also for > Linux which can render the same fonts with a very high quality. > > I described the problem in more detail and with images here: > > https://stackoverflow.com/questions/41149451/a-method-of-getting-a-linux-jdk-tarball-with-freetype-like-font-rendering > > Best regards, > Artur > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arturrataj at gmail.com Fri Dec 16 00:32:47 2016 From: arturrataj at gmail.com (Artur Rataj) Date: Fri, 16 Dec 2016 01:32:47 +0100 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux In-Reply-To: <032b301f-b046-61cc-1d48-1e920b3665c2@oracle.com> References: <032b301f-b046-61cc-1d48-1e920b3665c2@oracle.com> Message-ID: On Fri, Dec 16, 2016 at 12:54 AM, Phil Race wrote: > > As I started to say on that list, it seems to me that this may be a > font-specific problem. > Fonts have hints. I've seen similar issues when the hints are poor. > > Unfortunately there is no easy way to know if they are poor. > Some clients/apps/rendering systems by policy ignore hints so they may look > OK, > but then they may not look as good on a case where the hints were good and > important. > If I knew exactly what font you were using I could look at it. > The problem is more or less visible in a number of fonts, including the standard ones used by Java in dialogs, and several very high quality fonts supplied with Ubuntu. Of course, the actual differences vary with fonts. Also, the poor quality of font rendering of Java/Linux is known. This why there are the patches, the alternative "fixed" versions of OpenJDK etc. > Oracle's builds use a one that ships with the JDK binaries (not source) > All openjdk builds use freetype. On Linux this means Ubuntu's openjdk will > use the exact same copy of freetype as used for rendering the rest of your > desktop! > Thanks, so I was wrong. Then, it might be a misconfigured freetype, a buggy interface to freetype or whatever. > So if it looks bad with that, it will look bad on your desktop unless the > font is interpreted differently. > Not true. The particular font, like a lot of the other (if you wish, I may send you example images), is badly rendered only in Java. Other Freetype apps render these fonts very well, thanks to the exceptional quality of that library. If I run Netbeans with its standard fonts and --jdk-home of the Android Studio jdk, the GUI quality is immediately improved, thanks to the fonts rendered as expected from a properly supported Freetype. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Fri Dec 16 07:11:06 2016 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 15 Dec 2016 23:11:06 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" Message-ID: Hello Prasanta I believe the 'Banner Page' setting on Print dialog maps to the JobSheets attribute category. If this is right, the logic to check support for JobSheets attribute category is correct. Few corner cases that I observed with BannerTest: . The test-case does not bail-out when run without any printer installed on Ubuntu. . Secondly, how do we handle multiple printers installed on the machine . The capabilities will vary across printers -> a printer may not support printing BannerPage . I believe, the test case should bail-out safely if the particular printer doesn't support BannerPage . The logic in other test-case within webrev- TestCheckSystemDefaultBannerOption.java, seems to handle both these conditions Thanks & Have a good day Prahalad N. ---------------------------------------------------------------------- Message: 1 Date: Tue, 13 Dec 2016 21:38:26 +0530 From: Prasanta Sadhukhan To: Philip Race , 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" checkbox is disabled Message-ID: <5227445d-36c7-85a3-9d78-c8061e6e568a at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Gentle reminder for review.... Regards Prasanta On 12/7/2016 9:00 PM, Prasanta Sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 where it is seen that "Banner" checkbox > in printer dialog is disabled in ubuntu16.10. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170579 > webrev: http://cr.openjdk.java.net/~psadhukhan/8170579/webrev.00/ > > Issue was, in ubuntu16.10 the attribute map does not have > "job-sheet-supported" attribute returned by CUPS so this category is > not added to supported categories > [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java > .desktop/unix/classes/sun/print/IPPPrintService.java#l1030] > > so isAttributeCategorySupported() called by ServiceDialog returns > false > [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java > .desktop/share/classes/sun/print/ServiceDialog.java#l2763] > resulting in Banner checkbox getting disabled. > > Fix is to check if JobSheet category is supported in underlying > platform, only then proceed with the test. > > Regards > Prasanta ------------------------------ From prasanta.sadhukhan at oracle.com Fri Dec 16 08:45:16 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 16 Dec 2016 14:15:16 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" checkbox is disabled In-Reply-To: References: Message-ID: <51778985-98e1-b637-9420-64b1c813a753@oracle.com> Thanks for the review. Yes, we need to bail out initially itself in BannerTest if there is no printer installed. We do not need to check for default banner option in BannerTest as opposed to TestCheckSystemDefaultBannerOption.java because the test checks if we can get Banner page once we "select" Banner checkbox, so it will override the printer default banner option. Modified webrev: http://cr.openjdk.java.net/~psadhukhan/8170579/webrev.01/ Regards Prasanta On 12/16/2016 12:41 PM, Prahalad Kumar Narayanan wrote: > Hello Prasanta > > I believe the 'Banner Page' setting on Print dialog maps to the JobSheets attribute category. > If this is right, the logic to check support for JobSheets attribute category is correct. > > Few corner cases that I observed with BannerTest: > . The test-case does not bail-out when run without any printer installed on Ubuntu. > . Secondly, how do we handle multiple printers installed on the machine > . The capabilities will vary across printers -> a printer may not support printing BannerPage > . I believe, the test case should bail-out safely if the particular printer doesn't support BannerPage > > . The logic in other test-case within webrev- TestCheckSystemDefaultBannerOption.java, seems to handle both these conditions > > Thanks & Have a good day > > Prahalad N. > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 13 Dec 2016 21:38:26 +0530 > From: Prasanta Sadhukhan > To: Philip Race , 2d-dev > <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [9] RFR 8170579: The "Banner page" > checkbox is disabled > Message-ID: <5227445d-36c7-85a3-9d78-c8061e6e568a at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Gentle reminder for review.... > > Regards > Prasanta > > > On 12/7/2016 9:00 PM, Prasanta Sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9 where it is seen that "Banner" checkbox >> in printer dialog is disabled in ubuntu16.10. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170579 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8170579/webrev.00/ >> >> Issue was, in ubuntu16.10 the attribute map does not have >> "job-sheet-supported" attribute returned by CUPS so this category is >> not added to supported categories >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java >> .desktop/unix/classes/sun/print/IPPPrintService.java#l1030] >> >> so isAttributeCategorySupported() called by ServiceDialog returns >> false >> [http://hg.openjdk.java.net/jdk9/client/jdk/file/7f09d558b044/src/java >> .desktop/share/classes/sun/print/ServiceDialog.java#l2763] >> resulting in Banner checkbox getting disabled. >> >> Fix is to check if JobSheet category is supported in underlying >> platform, only then proceed with the test. >> >> Regards >> Prasanta > > > ------------------------------ From alexey.ushakov at jetbrains.com Fri Dec 16 09:31:35 2016 From: alexey.ushakov at jetbrains.com (Alexey Ushakov) Date: Fri, 16 Dec 2016 12:31:35 +0300 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux In-Reply-To: References: <032b301f-b046-61cc-1d48-1e920b3665c2@oracle.com> Message-ID: Hi Artur, > So if it looks bad with that, it will look bad on your desktop unless the font is interpreted differently. > > Not true. The particular font, like a lot of the other (if you wish, I may send you example images), is badly rendered only in Java. Other Freetype apps render these fonts very well, thanks to the exceptional quality of that library. > > If I run Netbeans with its standard fonts and --jdk-home of the Android Studio jdk, the GUI quality is immediately improved, thanks to the fonts rendered as expected from a properly supported Freetype. Actually we (at JetBrains) have made some changes to use fontconfig hints in freetype rendering. Best Regards, Alexey > On 16 Dec 2016, at 03:32, Artur Rataj wrote: > > > > On Fri, Dec 16, 2016 at 12:54 AM, Phil Race > wrote: > > As I started to say on that list, it seems to me that this may be a font-specific problem. > Fonts have hints. I've seen similar issues when the hints are poor. > > Unfortunately there is no easy way to know if they are poor. > Some clients/apps/rendering systems by policy ignore hints so they may look OK, > but then they may not look as good on a case where the hints were good and important. > If I knew exactly what font you were using I could look at it. > > The problem is more or less visible in a number of fonts, including the standard ones used by Java in dialogs, and several very high quality fonts supplied with Ubuntu. Of course, the actual differences vary with fonts. > > Also, the poor quality of font rendering of Java/Linux is known. This why there are the patches, the alternative "fixed" versions of OpenJDK etc. > > > Oracle's builds use a one that ships with the JDK binaries (not source) > All openjdk builds use freetype. On Linux this means Ubuntu's openjdk will > use the exact same copy of freetype as used for rendering the rest of your desktop! > > Thanks, so I was wrong. Then, it might be a misconfigured freetype, a buggy interface to freetype or whatever. > > So if it looks bad with that, it will look bad on your desktop unless the font is interpreted differently. > > Not true. The particular font, like a lot of the other (if you wish, I may send you example images), is badly rendered only in Java. Other Freetype apps render these fonts very well, thanks to the exceptional quality of that library. > > If I run Netbeans with its standard fonts and --jdk-home of the Android Studio jdk, the GUI quality is immediately improved, thanks to the fonts rendered as expected from a properly supported Freetype. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Fri Dec 16 10:00:52 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 16 Dec 2016 11:00:52 +0100 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux In-Reply-To: References: Message-ID: On Thu, Dec 15, 2016 at 2:30 PM, Artur Rataj wrote: > Hello, I discussed the problem on dev-build > > http://mail.openjdk.java.net/pipermail/build-dev/2016-December/018353.html > > but have been redirected here, thanks Eric! > > I would like to ask why OpenJDK on Linux has by default an inferior font > rendering quality, when there are OpenJDK variants also for Linux which can > render the same fonts with a very high quality. > > I described the problem in more detail and with images here: > > https://stackoverflow.com/questions/41149451/a-method-of-getting-a-linux-jdk-tarball-with-freetype-like-font-rendering > You don't compare two versions of OpenJDK in your article on stack overflow. You compare a version of OpenJDK with a version of Oracle JDK: OpenJDK Runtime Environment (build 1.8.0_76-release-b03) vs. Java(TM) SE Runtime Environment (build 1.8.0_122-ea-b04) As Phil already mentioned, Oracle JKD comes with a different, built-in font renderer (called t2k) which is not part of OpenJDK. There exist no official "OpenJDK early access" builds. You probably refer to the builds from https://jdk8.java.net/download.html but theses are actually Oracle JDK builds which contain the t2k font renderer. So you compare t2k vs freetype! Regards, Volker > Best regards, > Artur > From goetz.lindenmaier at sap.com Fri Dec 16 10:28:48 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 16 Dec 2016 10:28:48 +0000 Subject: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and sound coding. In-Reply-To: References: <38bf7910-554c-81bb-81b5-50fd65146cfe@oracle.com> <2a7e83eee95c49f8b9ccb6c1af87261c@DEROTE13DE08.global.corp.sap> Message-ID: <27d6fe4853074a1595082aae18fed8c3@DEROTE13DE08.global.corp.sap> Hi Sergey, Good catch, I added the memsets to the two other files, too. Sorrry it took that long, I just wanted to make sure it causes no upsets on solaris or BSD, I had to fix our build first. New webrev: http://cr.openjdk.java.net/~goetz/wr16/8170798-java2d_sound/webrev.03/ This ran through all our testing successfully. I'll push it Monday to client if there are no objections. Best regards, Goetz. > -----Original Message----- > From: Sergey Bylokhov [mailto:sergey.bylokhov at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 19:29 > To: Lindenmaier, Goetz > Cc: Phil Race ; 2d-dev <2d-dev at openjdk.java.net>; > sound-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR(M): 8170798: Fix minor issues in java2d and > sound coding. > > Hello. > > >> So it seems like the elements at indices from controlCount to 10 may not > >> be initialised but I don't see how this would be a problem since > >> PORT_NewCompoundControl > >> has no hardwired "10" .. it just uses controlCount. > >> In any case this would seem better addressed by the same kind of memset > >> after stack allocation that you proposed for the jpeg case. > > Fixed. (I thought it's cheaper to initialize only the rest, and more simple > > for the C-compiler to remove where useless.) > > It seems that some other implementations of PORT_NewCompoundControl can > have the same issue, like in : > PLATFORM_API_BsdOS_ALSA_Ports.c and PLATFORM_API_SolarisOS_Ports.c. > Should we apply the same memset there to make them in sync? From arturrataj at gmail.com Fri Dec 16 10:30:40 2016 From: arturrataj at gmail.com (Artur Rataj) Date: Fri, 16 Dec 2016 11:30:40 +0100 Subject: [OpenJDK 2D-Dev] Font rendering quality in Linux In-Reply-To: References:

Message-ID: Hi Volker, in at least one case (Android Studio openjdk 1.8.0_76-release vs openjdk 1.8.0-internal which I compiled myself with Freetype enabled) I compared two Openjdks, and they render fonts very differently. I also compared Ubuntu Openjdk to apps which use Freetype for sure (e.g. the text editor Pluma) and the rendering difference is mostly just as large. But Oracle Jdk which, according to you, does not use Freetype, renders the fonts just like Openjdk which must use Freetype. Why it is like that, I don't know. On 16 Dec 2016 11:00, "Volker Simonis"