Hi David,
On 01/23/20 15:46 pm, David Holmes wrote:
>
> So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed
> for by the jlong size variable. On 64-bit overflow is not possible
> because jlong is signed and size_t is not.
>
> So we only need an overflow check on 32-bit.
OK.
Hi Nick,
I've cc'd Kim as our C++ expert.
Kim I have a query below if we're entering UB territory ...
On 23/01/2020 6:02 pm, Nick Gasson wrote:
Hi David,
On 01/23/20 15:46 pm, David Holmes wrote:
So on 32-bit size_t is 32-bit and so may have ~half the capacity allowed
for by the jlong size
Looks good to me.
+1
-- Kevin
On 1/22/2020 8:37 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
- Fixed by forcing signing even if runtime already signed.
- Original implementation was not taken in consideration that runtime
can be signed (JDK itself is signe
Hi Mandy,
Thanks for your thoughts. :)
I've asked around, and there don't appear to be any details
regarding real-life customer scenarios that can be shared.
I realise this doesn't exactly help my case.
As for the volume of output, I hoped to address that via the
inclusion of the regex check, t
On 1/23/20 10:22 AM, David Holmes wrote:
> That aside IIRC the overflow check is not ideal here because we already
> enter undefined behaviour territory inside align_up if we actually
> overflow.
How is that possible? size_t is an unsigned type, and unsigned types
never overflow. On a 32-bit box
looks good.
/Andy
On 1/22/2020 11:37 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
- Fixed by forcing signing even if runtime already signed.
- Original implementation was not taken in consideration that runtime
can be signed (JDK itself is signed from which
Hi Paul,
yes, other potential changes in low level I/O should probably happen
first. Will check.
On 1/22/20 3:31 PM, Paul Sandoz wrote:
My sense is it is fixing a marginal case for the less dominant platform where
this is less likely arise, whereas for the dominant platform there is still a
Looks good.
- Alexey
On 1/22/2020 11:37 PM, Alexander Matveev wrote:
Please review the jpackage fix for bug [1] at [2].
- Fixed by forcing signing even if runtime already signed.
- Original implementation was not taken in consideration that runtime
can be signed (JDK itself is signed from whi
I am glad to see that people are making progress on this front. Did you see the
points I raised about the new arguments and inputs that need to be provided in
order to build code-signed packages that can pass Apple’s current notarization
requirements in Catalina? I am currently successfully nota
Please review cleanup of package-info.java files use of -> {@code}.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-doc-cleanup-8215361-1/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8215361
Thanks, Roger
Hi Roger
Overall looks OK with the exception of
java.sql.rowset/share/classes/com/sun/rowset/package-info.java
——
- * CachedRowSetImpl - The
javax.sql.rowset.CachedRowSet interface
+ * {@code CachedRowSetImpl} - The
javax.sql.rowset.CachedRowSet interface
There are a few entries t
Hi Roger,
Looks good to me.
Although they are in the original src, I would put spaces between
"{@code SerialBlob}" and "class"/"object", at line 50,52 in
javax/sql/rowset/serial/package-info.java
Naoto
On 1/23/20 12:18 PM, Roger Riggs wrote:
Please review cleanup of package-info.java files
Yes, I can see those too. That suggests that the change was not performed
automatically. Which makes sense, since sometimes nested tags need to be
"turned inside out", e.g. ... -> {@code ...}.
{@code java.net.URL url = rowset.getURL(1);}
Will it be rendered as intended? Otherwise looks
On 24/01/2020 12:41 am, Andrew Haley wrote:
On 1/23/20 10:22 AM, David Holmes wrote:
That aside IIRC the overflow check is not ideal here because we already
enter undefined behaviour territory inside align_up if we actually
overflow.
How is that possible? size_t is an unsigned type, and unsign
On 23/01/2020 22:59, David Holmes wrote:
On 24/01/2020 12:41 am, Andrew Haley wrote:
On 1/23/20 10:22 AM, David Holmes wrote:
That aside IIRC the overflow check is not ideal here because we already
enter undefined behaviour territory inside align_up if we actually
overflow.
How is that poss
Hi Maurizio,
On 24/01/2020 9:27 am, Maurizio Cimadamore wrote:
On 23/01/2020 22:59, David Holmes wrote:
On 24/01/2020 12:41 am, Andrew Haley wrote:
On 1/23/20 10:22 AM, David Holmes wrote:
That aside IIRC the overflow check is not ideal here because we already
enter undefined behaviour terri
Hi David,
On 01/24/20 12:17 pm, David Holmes wrote:
>>
>> That said, memory segments are not the only clients of
>> Unsafe::allocateMemory - so if we decided that overflow is an issue
>> that should be handled in clients, fine, but at least it should be
>> evident somewhere in the javadoc of Unsaf
Hi Nick,
On 24/01/2020 3:32 pm, Nick Gasson wrote:
Hi David,
On 01/24/20 12:17 pm, David Holmes wrote:
That said, memory segments are not the only clients of
Unsafe::allocateMemory - so if we decided that overflow is an issue
that should be handled in clients, fine, but at least it should be
18 matches
Mail list logo
