On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Fri, 7 Mar 2025 15:11:09 GMT, Magnus Ihse Bursie wrote:
> So, Daniel pointed out some irrelevant changes that you tried to sneak in. :)
> I think he is right that these should be reverted. I don't see anyone
> complaining about removing `-Zc:wchar_t-` though, or the necessary follow-up
> fi
On Fri, 7 Mar 2025 12:00:24 GMT, Magnus Ihse Bursie wrote:
>> Oops, didn't mean to do that. Oh well, will update this again later
>
> @TheShermanTanker This seems like a good fix to make VSC++ behave according
> to standard. I think it should be resurrected.
@magicus I think this was closed by
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since
On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote:
>>> I do wonder if mutex support can be implemented for Windows with
>>> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
>>> would be nice to have. Shame threads.h is not available with some Visual
>>> Studio versi
On Fri, 8 Nov 2024 13:10:48 GMT, Alexey Semenyuk wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove global memHandle, would've liked to keep it as a comment :(
>
> src/jdk.
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Wed, 30 Oct 2024 06:27:22 GMT, Chris Plummer wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request conta
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request incrementally with one additional
commit since the last r
On Sat, 26 Oct 2024 04:35:09 GMT, Julian Waters wrote:
> I do wonder if mutex support can be implemented for Windows with
> Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it
> would be nice to have. Shame threads.h is not available with some Visual
> S
On Sun, 27 Oct 2024 06:25:02 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase.
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 14:22:28 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and
On Thu, 24 Oct 2024 07:11:16 GMT, David Holmes wrote:
> > the way I did it I'd have to force push
>
> That should not be the case. You can just anti-delta changes.
I did it in a really inefficient way, by checking out all files except for the
files that I wanted to stay. I could not figure out
ith help from reviewers, so I recommend anyone
> reviewing who knows more about the code than I do to see whether there is
> indeed a bug that needs fixing in a different way than what I did
Julian Waters has refreshed the contents of this pull request, and previous
commits have been remov
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Wed, 23 Oct 2024 16:51:23 GMT, Chris Plummer wrote:
>> I wasn't sure whether the global memHandle not being used was a bug, so I
>> commented out the local one. I missed the line 88 one because it wasn't
>> flagged. If it really isn't needed I'll remove that one instead
>
> I'm not sure what
On Tue, 22 Oct 2024 18:03:12 GMT, Chris Plummer wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Tue, 22 Oct 2024 09:40:35 GMT, David Holmes wrote:
> > Aren't the dt_shmem and jdwp changes related to HotSpot?
>
> Nope. That's core-svc - the non-hotspot side of serviceability. :)
Oh, well I guess you learn something new everyday :)
-
PR Comment: https://git.openjdk.org/jdk/
On Tue, 22 Oct 2024 01:40:11 GMT, David Holmes wrote:
> > and whatever team is responsible for HotSpot debugging.
>
> I don't see anything hotspot related here.
>
> I think you would be better off splitting this up into distinct issues and
> PRs for different areas. I expect the client team in
After 8339120, gcc began catching many different instances of unused code in
the Windows specific codebase. Some of these seem to be bugs. I've taken the
effort to mark out all the relevant globals and locals that trigger the unused
warnings and addressed all of them by commenting out the code a
On Mon, 21 Oct 2024 14:34:30 GMT, Julian Waters wrote:
> After 8339120, gcc began catching many different instances of unused code in
> the Windows specific codebase. Some of these seem to be bugs. I've taken the
> effort to mark out all the relevant globals and locals th
On Sat, 5 Oct 2024 07:49:37 GMT, SendaoYan wrote:
> Hi all,
> This PR fix some typos bugs for RISC-V, and a typo bug in test directory.
> Trivial fix, no risk.
Looks good regardless
src/hotspot/cpu/riscv/methodHandles_riscv.cpp line 447:
> 445: }
> 446: }
> 447:
This whitespace dele
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling usi
On Sat, 24 Aug 2024 05:12:42 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Sat, 24 Aug 2024 05:06:18 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
On Tue, 16 Jul 2024 08:59:20 GMT, Julian Waters wrote:
>> snprintf has been available for all officially and unofficially supported
>> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
>> forever. snprintf is conforming to C99 since the start wh
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Mon, 15 Jul 2024 16:30:02 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> USe os::snprintf in HotSpot
>
> src/jdk.jdwp.agent/windows/native/libjdwp/util_md
On Fri, 12 Jul 2024 06:29:34 GMT, Julian Waters wrote:
> snprintf has been available for all officially and unofficially supported
> compilers for Windows, Visual Studio since version 2015 and gcc since, well,
> forever. snprintf is conforming to C99 since the start when compiling usi
he buffer was terminated early, as seen here:
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/snprintf-snprintf-snprintf-l-snwprintf-snwprintf-l?view=msvc-170
>
> Reviews Required: 2 for HotSpot, jdk.hotspot.agent, and jdk.jdwp.agent, 1 for
> awt and jdk.accessibility, 1 for java.ba
On Fri, 12 Jul 2024 19:18:09 GMT, Kim Barrett wrote:
> This should be using `os::snprintf` rather than `snprintf`. Rationale is in
> the comment here:
>
> https://github.com/openjdk/jdk/blob/1f6e106b45e5109224e13d70f1a40c9e666ec2ab/src/hotspot/share/runtime/os.cpp#L118-L126
>
> And yes, I know
snprintf has been available for all officially and unofficially supported
compilers for Windows, Visual Studio since version 2015 and gcc since, well,
forever. snprintf is conforming to C99 since the start when compiling using
gcc, and 2015 when using Visual Studio. Since it conforms to C99 and
On Fri, 7 Jun 2024 13:01:15 GMT, SendaoYan wrote:
>> As confusing as they are, unfortunately GitHub UI does not render extra
>> trailing newlines. This is the only one I could find with grepWin.
>
> I find the extra trailing newlines through below shell command:
>
> for i in `find . -iname "Mak
On Fri, 7 Jun 2024 07:29:39 GMT, SendaoYan wrote:
>> Hi all,
>> This PR several extra empty spaces and extra empty lines in several
>> Makefiles. It's trivial fix, no risk.
>>
>> Thanks.
>
> SendaoYan has updated the pull request incrementally with one additional
> commit since the last revi
On Fri, 7 Jun 2024 07:26:39 GMT, SendaoYan wrote:
>> test/jdk/java/rmi/reliability/benchmark/bench/rmi/Makefile line 1:
>>
>>> 1: #
>>
>> This file change is dubious:
>> 1. It does not have any trailing whitespace that can fail the skara checks.
>> 2. If the duplicate blank lines in the end of
On Fri, 5 Apr 2024 06:31:16 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Include memory header in sspi.cpp
- RAII in s
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with two additional
commits since the last revision:
- Revert some changes in ssp
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Revert some changes for now in sspi.cpp
On Fri, 19 Jan 2024 01:57:40 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
On Fri, 19 Jan 2024 19:42:20 GMT, Daniel Jeliński wrote:
> AFAICT these changes are not necessary.
>
> ### C++11 §6.7/3:
> > [...] A program that jumps from a point where a variable with automatic
> > storage duration is not in scope to a point where it is in scope is
> > ill-formed **unless t
On Fri, 19 Jan 2024 18:43:39 GMT, Weijun Wang wrote:
> The permissive- option you mentioned in the previous PR.
Ah, it goes here:
> The permissive- option you mentioned in the previous PR.
Ah, alright. That goes here:
https://github.com/openjdk/jdk/blob/cbfbaee6eb8d8303a10128cb23ea5021cb8385
On Fri, 19 Jan 2024 17:31:27 GMT, Weijun Wang wrote:
> The code change looks better. Can you show me where I can add this compiler
> switch so that I can try it myself a little?
Hm? I'm not too sure what compiler switch you are referring to
-
PR Comment: https://git.openjdk.org/jd
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
std:: qualifier sspi.cpp
-
Chang
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments in sspi.cpp
On Tue, 16 Jan 2024 17:42:43 GMT, Weijun Wang wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the remaining case in sspi.cpp
>
> src/java.security.jgss/windows/native/li
On Tue, 16 Jan 2024 17:36:20 GMT, Weijun Wang wrote:
>> Julian Waters has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix the remaining case in sspi.cpp
>
> src/java.security.jgss/windows/native/li
On Wed, 10 Jan 2024 12:53:48 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Fix the remaining case in sspi.cpp
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Fix most but not all methods in sspi.cpp
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought
On Tue, 5 Dec 2023 15:07:15 GMT, Weijun Wang wrote:
> I still don't like this solution:
>
> 1. Duplicated lines.
> 2. There are other `goto`s in this file. I know they happen to be unaffected,
> but if `goto` is not recommended in C++ it looks unfair to remove some and
> keep some.
>
> Can we
On Mon, 4 Dec 2023 14:49:24 GMT, Weijun Wang wrote:
> I don't like all those duplicated lines. Why do you think the previous fix is
> a hack? I would guess the C++ designers are also not happy of this
> restriction so they provide us a way to avoid it. Maybe they will enhance it
> again someti
. As mentioned, this unfortunately
> does increase duplicate code, but is the cleanest solution I could come up
> with for the labels
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, where initialization of locals in
>> sspi were jumped over by gotos to a certain label. I changed the
On Fri, 17 Nov 2023 15:44:52 GMT, Thomas Stuefe wrote:
> > > > > Can you please describe the problem you are trying to solve, and why
> > > > > you think it is worth solving. You describe the thought process you
> > > > > went through while doing the patch and possibly some other, older
> > >
On Fri, 17 Nov 2023 14:13:58 GMT, Thomas Stuefe wrote:
> > > Can you please describe the problem you are trying to solve, and why you
> > > think it is worth solving. You describe the thought process you went
> > > through while doing the patch and possibly some other, older patch. As it
> > >
On Fri, 17 Nov 2023 13:49:22 GMT, Thomas Stuefe wrote:
> Can you please describe the problem you are trying to solve, and why you
> think it is worth solving. You describe the thought process you went through
> while doing the patch and possibly some other, older patch. As it is, reading
> the
On Thu, 16 Nov 2023 04:40:53 GMT, Julian Waters wrote:
>> I regret not actually addressing the issues with the goto labels in
>> https://github.com/openjdk/jdk/pull/15996, I've as such fixed the issues
>> with them properly this time, by simply deleting the labels and d
his unfortunately does increase
> duplicate code, but is the cleanest solution I could come up with for the
> labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
NULL to nullptr in sspi.cpp
-
Changes:
- all:
his unfortunately does increase
> duplicate code, but is the cleanest solution I could come up with for the
> labels
Julian Waters has updated the pull request incrementally with one additional
commit since the last revision:
Missed labels in sspi.cpp
-
Changes:
- all: http
I regret not actually addressing the issues with the goto labels in
https://github.com/openjdk/jdk/pull/15996, I've as such fixed the issues with
them properly this time, by simply deleting the labels and duplicating the code
where they're used. As mentioned, this unfortunately does increase dup
On Sat, 30 Sep 2023 06:26:10 GMT, Julian Waters wrote:
> Prepares java.security.jgss for the permissive- compiler switch by
>
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in
> N
On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters wrote:
>> Prepares java.security.jgss for the permissive- compiler switch by
>>
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declara
On Tue, 3 Oct 2023 02:55:09 GMT, Julian Waters wrote:
>> Prepares java.security.jgss for the permissive- compiler switch by
>>
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declara
On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
On Tue, 3 Oct 2023 02:47:02 GMT, Julian Waters wrote:
>> Well, SO offers a speculative answer:
>> https://stackoverflow.com/a/14274292
>> the modified form is not more safe, but the standard does not forbid it.
>
> I tested the new approach on gcc, it worked, so I'll
On Tue, 3 Oct 2023 14:13:14 GMT, Weijun Wang wrote:
> I'm OK with the fix. So separating the declaration and the assignment
> effectively place all the declarations at the beginning of the block and give
> them default values?
It doesn't place them at the start of the block, the difference is
On Tue, 3 Oct 2023 02:29:28 GMT, Julian Waters wrote:
>> Prepares java.security.jgss for the permissive- compiler switch by
>>
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declara
On Mon, 2 Oct 2023 12:27:17 GMT, Daniel Jeliński wrote:
>> I agree that it's ugly, but at the time I couldn't think of another way to
>> solve the issue. By any chance, why does splitting it out into separate
>> declaration assignment work? Last I remember, it still jumps over the local
>> eve
> Prepares java.security.jgss for the permissive- compiler switch by
>
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in
> NativeCreds.c, as the definition is static
Julian Waters
> Prepares java.security.jgss for the permissive- compiler switch by
>
> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
> - Adding a static modifier to a mismatched method declaration in
> NativeCreds.c, as the definition is static
Julian Waters
On Mon, 2 Oct 2023 07:57:57 GMT, Daniel Jeliński wrote:
>> Prepares java.security.jgss for the permissive- compiler switch by
>>
>> - Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
>> - Adding a static modifier to a mismatched method declaration in
>> NativeCreds.c, as t
Prepares java.security.jgss for the permissive- compiler switch by
- Adding scopes so goto doesn't jump over unitialized locals in sspi.cpp
- Adding a static modifier to a mismatched method declaration in NativeCreds.c,
as the definition is static
-
Commit messages:
- Prepare secur
On Tue, 1 Aug 2023 01:52:24 GMT, Julian Waters wrote:
> We should set the -permissive- flag for the Microsoft Visual C compiler, as
> was requested by the now backed out
> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
> the Visual C compiler much less
On Thu, 28 Sep 2023 03:12:03 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Vis
code quality on Windows in the future.
Julian Waters has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 26 commits:
- Merge branch 'openjdk:master' into patch-10
- Merge branch 'master' into patch-10
- Document
1 - 100 of 205 matches
Mail list logo
