On Wednesday, October 18, 2023 at 3:14:33 AM UTC-7, h47...@gmail.com wrote:
> On Wednesday, October 18, 2023 at 5:38:23 AM UTC+2, Jake Hamby (Solid State Jake) wrote:
> > "perl.c" is in the parent directory of where the test is run, so it compiles, links, and prints "define" to SYS$OUTPUT in the normal case. But when compiled with /main=posix_exit defined, the same program immediately kills not just the process but the running DCL script. Very bizarre.
> In the shown code there is no "return" in main and a "}" is missing. A cut & paste error?
> After adding a "return 0;" and "}" the code works for me - IA64 and x86.
>
> If that doesn't fix your porblem, check $STATUS or enable image accounting to see the exit status after running the image.

Ok, I see where the problem is. I did forget to paste the final "}", but the code that's failing doesn't have a "return 0;" and should still work.

The main() function in C/C++ is special in that it returns int but isn't required to have a return statement. Falling off the end is perfectly valid and should return success.

https://en.cppreference.com/w/cpp/language/main_function

In this case, $STATUS is correctly %X00000001, except with CC and /main=posix_exit. In that case, it's returning %X1035A00A. So it's definitely a bug in VSI C, but not Clang, and the reason it's not printing anything is the same reason that "exit %X1035A00A" isn't printing anything.

$ cc/version
VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 V9.2-1

There's nothing wrong with fcntl() at all. The problem is entirely in the C compiler returning the wrong status for /main=posix_exit and falling off the end of main().

Regards,
Jake Hamby

On 10/18/23 5:08 PM, Jake Hamby (Solid State Jake) wrote:
> The problem is entirely in the C compiler returning the wrong status
> for /main=posix_exit and falling off the end of main().

Are you sure it's the C compiler? I doubt that option will work when
building Perl because of its own exit handling, which gives you run-time
control over how exit behavior works. By default, it uses the CRTL
default where "exit 1;" gives you a generic failure and "exit 0;" gives
you a generic success, but you can ask for the exit status to be
interpreted as a VMS condition code:

$ perl -e "exit 1;"
%SYSTEM-F-ABORT, abort
$ show symbol $status
$STATUS == "%X0000002C"
$ perl -e "use vmsish 'exit'; exit 1;"
$ show symbol $status
$STATUS == "%X00000001"

Then there is the logical name PERL_VMS_POSIX_EXIT, which tries to
encode a one-byte POSIX exit status somewhere in one of the upper bytes
of a VMS condition value, meanwhile setting the (hopefully) appropriate
severity bits in the low byte.

Implementing all this stuff couldn't be done by relying on the CRTL's
exit().

On Thursday, October 19, 2023 at 12:08:09 AM UTC+2, Jake Hamby (Solid State Jake) wrote:
....
> Ok, I see where the problem is. I did forget to paste the final "}", but the code that's failing doesn't have a "return 0;" and should still work.

The missing "}" made me wonder if there were more lines missing, which could have included a return statement.
> The main() function in C/C++ is special in that it returns int but isn't required to have a return statement. Falling off the end is perfectly valid and should return success.
>
> https://en.cppreference.com/w/cpp/language/main_function
>
> In this case, $STATUS is correctly %X00000001, except with CC and /main=posix_exit. In that case, it's returning %X1035A00A. So it's definitely a bug in VSI C, but not Clang, and the reason it's not printing anything is the same reason that "exit %X1035A00A" isn't printing anything.

I agree, it's a bug that without an explicit return statement the $STATUS is not a success status.

The URL points to a C++ page, which contains a pointer to a C page. There it says that prior to C99 the exit status without an explicit return statement was undefined. The default for the C compiler on VMS claims to be C99 compliant. Explicitly specifying C99 with the /STANDARD qualifier doesn't change anything, here. And, as you probably know, the /MAIN qualifier is ignored by the current C++ compiler on x86.

In the status code, if bit 0x10000000 is set, no message is printed.
$ exit %X1035A00A
$ exit %X035A00A
%C-E-NOMSG, Message number 0035A00A
$ set message sys$message:decc$msg
$ exit %X035A00A
%C-E-EXIT1, exit value 1
$ It seems, the correct status should be %X1035A009.

On Thursday, October 19, 2023 at 12:03:42 AM UTC-7, h47...@gmail.com wrote:
> On Thursday, October 19, 2023 at 12:08:09 AM UTC+2, Jake Hamby (Solid State Jake) wrote:
> ...
> > Ok, I see where the problem is. I did forget to paste the final "}", but the code that's failing doesn't have a "return 0;" and should still work.
> The missing "}" made me wonder if there were more lines missing, which could have included a return statement.
> > The main() function in C/C++ is special in that it returns int but isn't required to have a return statement. Falling off the end is perfectly valid and should return success.
> >
> > https://en.cppreference.com/w/cpp/language/main_function
> >
> > In this case, $STATUS is correctly %X00000001, except with CC and /main=posix_exit. In that case, it's returning %X1035A00A. So it's definitely a bug in VSI C, but not Clang, and the reason it's not printing anything is the same reason that "exit %X1035A00A" isn't printing anything.
> I agree, it's a bug that without an explicit return statement the $STATUS is not a success status.
>
> The URL points to a C++ page, which contains a pointer to a C page. There it says that prior to C99 the exit status without an explicit return statement was undefined. The default for the C compiler on VMS claims to be C99 compliant. Explicitly specifying C99 with the /STANDARD qualifier doesn't change anything, here. And, as you probably know, the /MAIN qualifier is ignored by the current C++ compiler on x86.
>
> In the status code, if bit 0x10000000 is set, no message is printed.
> $ exit %X1035A00A
> $ exit %X035A00A
> %C-E-NOMSG, Message number 0035A00A
> $ set message sys$message:decc$msg
> $ exit %X035A00A
> %C-E-EXIT1, exit value 1
> $
> It seems, the correct status should be %X1035A009.

Thanks for the info on the status code bits. I didn't catch the release note about /MAIN being ignored by the current x86 C++ compiler, but as you noted, I can't switch the Perl port over to use POSIX exit anyway without breaking a lot of VMS-specific behavior to no benefit.

What I did instead to call POSIX exit() was simply modifying the Configure test and .h file to call __posix_exit() directly. If the version of VMS is too old to support __posix_exit(), then the VMS-specific kill() code can be used, and if it's new enough, then POSIX exit() should be preferable on both C and C++.

I couldn't find any reference as to whether __posix_exit() handles negative values for process ID correctly, but for Perl it doesn't matter because it has its own VMS implementation of killpg() which it uses automatically in that case. Making this change didn't seem to change the outcome of any test cases.

I've found some quite interesting issues with porting Perl to Clang, related to "long" being 8 bytes, having to use 64-bit pointers to get va_list to work, and some unfortunate crashes in early startup. I've also found some general bugs in the Configure script that I'm polishing up the fixes for.

I'm testing my local C++/64-bit-clean changes with the C compiler and its default 32-bit pointers now, to make sure I didn't break anything. I'll push my work to my GitHub fork later today and start a new thread on Clang and LP64 issues.

Best regards,
Jake Hamby