Proposal to fix the procedure move for string_type

[jvdp1]

Issue (see #731 and #735 for more detail): seg fault occurs when the input and output string_type variable is the same in move:

call move( from, from)

@band-a-prend @nkevy @awvwgk Would this proposition work for you? Could you test it with GCC 13, please?

Fixes #731 and #735

[nkevy]

@jvdp1 yes your pull request fixed test string_intrisic
Start 42: string_intrinsic 42/57 Test #42: string_intrinsic ................. Passed 0.11 sec
cmake version 3.27.4
Apple clang version 12.0.5 (clang-1205.0.22.11)
Target: x86_64-apple-darwin20.6.0
MacOS 11.7.4

Kind Regards,
@nkevy

[band-a-prend]

@jvdp1
I'm not sure why it's required this way

if(from%raw .eq. to%raw)then
         deallocate(from%raw)

Does the initial (allocated) string str will be dealocated now if try to do move(str, str)?
Or the from%raw or to%raw already called additional allocation?

But with GCC 13 all tests are passed now with proposed patches.

[jvdp1]

It is to mimick the intrinsic move_alloc that deallocates FROM in the process. I will checks the specs and clarify them if needef Le lun. 4 sept. 2023, 09:59, Sergey Torokhov ***@***.***> a écrit :

…

@jvdp1 <https://github.com/jvdp1> I'm not sure why it's required this way if(from%raw .eq. to%raw)then deallocate(from%raw) Does the initial (allocated) string str will be dealocated now if try to do move(str, str)? Or the from%raw or to%raw already called additional allocation? But with GCC 13 all tests are passed now with proposed patches. — Reply to this email directly, view it on GitHub <#736 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD5RO7B5ZUTDQQDYUPCYMCDXYWC5FANCNFSM6AAAAAA4JGKCM4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[band-a-prend]

@jvdp1
If it works as expected then it's ok. I'm just half-asleep :)
Great thanks for fix!

[jvdp1]

@awvwgk I pushed your changes, but then the test "move: test case 8" failed.

So, what should be the value of from after call move(from, from)? Should it be deallocated (as assumed previously), or should it contains the value of from?

[awvwgk]

This changes the behaviour from undefined to copying to self will be a no-op. We would need to update the test and the specs, but I think it makes more sense this way.

[jvdp1]

This changes the behaviour from undefined to copying to self will be a no-op. We would need to update the test and the specs, but I think it makes more sense this way.

Ok. I modified both the tests and specs with the "new" behaviour. Could you @awvwgk have another check, please?

[awvwgk]

Looks good to me now