Why does libc exit use returnCode % 1024 and not returnCode & 0xFF ?

[vapid canopy]

"The exit() function causes normal process termination and the
least significant byte of status (i.e., status & 0xFF) is
returned to the parent (see wait(2))."

Why are the docs lying to me?

[near bronze]

When your question is answered use !solved to mark the question as resolved.

Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question use !howto ask.

[sharp plume]

where exactly do you see status % 1024 @vapid canopy ?`

https://github.com/bminor/glibc/blob/e7c14e542d8d858b824b5df4f4e3dc93695e6171/stdlib/exit.c#L146
calls
https://github.com/bminor/glibc/blob/e7c14e542d8d858b824b5df4f4e3dc93695e6171/stdlib/exit.c#L43
which calls
https://github.com/bminor/glibc/blob/e7c14e542d8d858b824b5df4f4e3dc93695e6171/posix/_exit.c#L25
which status &= 0xff's
before aborting

whats more interesting is how the status is communicated to the calling process
because that thing doesnt return at all, so i assume they rely on status being in %rax

[sturdy brook]

Interesting

You know what's even more interesting (imo)? _exit() calls abort() which can itself call _exit()

[sharp plume]

lmao

time to look what musl does

oh

the exit syscall specified by rax expects the status in rdi so how does it communiate that

  /* If we can't signal ourselves and the abort instruction failed, exit.  */
  if (stage == 5)
    {
      ++stage;
      _exit (127);
    }

"if it does not exit, make sure it exits by overflowing the stack"

[sturdy brook]

indeed

[sturdy brook]

Yeah I'm a little confused here

https://github.com/bminor/glibc/blob/e7c14e542d8d858b824b5df4f4e3dc93695e6171/sysdeps/unix/sysv/linux/_exit.c#L26

Here we go

I think this is the actual _exit on sysv

[sharp plume]

oh

wtf was i looking at then

[sturdy brook]

Presumably that's the fallback implementation for unknown systems

[sharp plume]

i see

[vapid canopy]

runtime testing

[sharp plume]

in the debugger ?

[vapid canopy]

in $? from the shell, the literal process exit code

literally just run it and see

[sturdy brook]

@vapid canopy this is an implementation-defined thing. What system are you on.

[sharp plume]

cant reproduce

[sturdy brook]

^

[vapid canopy]

I tried that on CentOS Linux, some recent distro release, g++ 4.8.5 I think

[vapid canopy]

ummmmm

kay let me pop open the ubuntu VM

[sturdy brook]

That’s ancient lol

[vapid canopy]

the compiler yes, the linux distro no

[sharp plume]

i mean you can also try on ;compile

[vapid canopy]

n o

[sturdy brook]

Ok…?

But the compiler and libc are the most important part here

[vapid canopy]

yes

[sharp plume]

;compile bash

echo -e "#include <stdlib.h>\nint main(int argc, char **argv) { return atoi(argv[1]); }" > main.c
gcc main.c
./a.out 127 ; echo $? ; uname -r

[wet basalt]

Program Output

prog.sh: line 4:    28 Segmentation fault      (core dumped) ./a.out
139
5.4.0-113-generic

nekrogenesis | bash script | bash | wandbox.org

[sturdy brook]

The segfault message is misleading

It’s not actually

[sharp plume]

what is segfaulting lol

[sturdy brook]

It’s not

It’s an artifact of the sandbox

[sharp plume]

oh

[sturdy brook]

Iirc

[vapid canopy]

ok so I can't reproduce it here either,
let me ask my question in a different way

the return type is int, why can't libc just, put the same return code as the actaul int value, and NOT truncate it to the last byte? Or in different libc implementations, do other arithmetic with the int value?

[sharp plume]

can you give the output of ldd --version

on the system where it happens

@vapid canopy

[sturdy brook]

It seems pretty baked into the posix standard that exit codes are 0-255. I'm sure the reason is just historical.

[vapid canopy]

kay one moment

[sharp plume]

on the system where you can return with more than 255

i just need the glibc version

2.31 was released in 2020

[vapid canopy]

nope, manual testing shows the highest value is 255, anything higher loops back to 0

[sharp plume]

yeah but thats on ubuntu

i thought u encountered the problem in centos ?

[vapid canopy]

kay let me go and access this real centos machine, it's corporate property we use at work

[sharp plume]

i mean essentially you can look up the version and download the source and look if they & 0xff on status exit

if they dont you know why its 1024

[vapid canopy]

say that again, the version of the what?

libc?

ldd?

[sharp plume]

glibc

[vapid canopy]

which piece of software's source code exactly

aha

[sharp plume]

the second line after the input

2.31 is the glibc version

download the source of that release and look what exit does

[vapid canopy]

in _exit.c ?

[sharp plume]

.../stdlib/exit.c
is the path on the current release

and then follow any function calls

if you dont know where to follow it look at what is included in that file

[vapid canopy]

ohhhhhhhhhhhhhhhh

so yes, on the machine where I ran this, it is again modulo 256

!solved