:41136637 I want to see if SE chat allows me to ping-reply across rooms. No it doesn't.

@Zanna Wanna see the thing about how piping seems to suppress the shell-printed segfault message?

@EliahKagan lol

@EliahKagan yeah!

Are you on a computer or your phone? Can you run commands in a shell?

yes, I have some shells here :)

/* crash.c - simple program that crashes by raising a segmentation fault */

#include <signal.h>

int main(void)
{
    raise(SIGSEGV);
}

You can compile it with:

gcc -ansi -pedantic -Wall -Wextra -o crash crash.c

The compiler may not realize the closing brace is unreachable, so you may get a warning like this, but you should not get other warnings:

crash.c: In function ‘main’:
crash.c:8:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

sorry I just had to go attend to a couple of small things

back

So when you run that it crashes.

If it fails to crash that's a serious bug.

:)

lol

@EliahKagan I did get that

zanna@toaster:~/playground$ ./crash
Segmentation fault (core dumped)

success

Now try piping its output to something. cat. Whatever.

It will still crash, but...

zanna@toaster:~/playground$ ./crash | cat
zanna@toaster:~/playground$

It does still crash, but the shell does not print the message.

Of course this works, and the message is printed:

bash -c ./crash

As one would expect from the previous piping result, this does not print the message:

bash -c './crash | cat'

But what surprised me was what happens from this:

bash -c ./crash | cat

I don't get any output

Indeed.

This surprised me because I thought it was the shell running the command that was informed that it had exited abnormally with SIGSEGV and that reported it.

But apparently it... sometimes isn't.

What other shells do you have installed?

so far

Bash and Dash show the same text for a segfaulted command. But some others don't. Zsh should be quite sufficient for this.

ok :)

In Bash:

zsh -c ./crash

At least for me, that shows the same output as running ./crash in Bash.

same here

And piping it suppresses that output, as usual.

yes

But if you just run zsh to open up an interactive Zsh, and then run ./crash, the message is different.

ek@Io:~/source$ zsh
Io% ./crash
zsh: segmentation fault (core dumped)  ./crash

I also got that output

So it's as though the shell that runs the command is crashing along with it!

Interestingly, in Zsh, piping doesn't have the same effect as in Bash:

Io% ./crash | cat
zsh: segmentation fault (core dumped)  ./crash |
zsh: done                              cat

Io% bash -c ./crash | cat
zsh: segmentation fault (core dumped)  bash -c ./crash |
zsh: done                              cat

But this still shows nothing:

bash -c './crash | cat'

looks like it's Bash's fault haha

Well it can't be explained just in terms of Bash behavior.

Running zsh -c ./crash does not cause zsh to print the segfault message. The shell that calls that subprocess prints it.

It gets more interesting:

bash -c 'trap "echo bye" EXIT; ./crash' | cat

Scheduling a command for exit makes the shell print the segfault message, then execute the command.

That bash command works from both Bash and Zsh and has the same effect.

It works even if the command is a noop:

bash -c 'trap : EXIT; ./crash' | cat

I don't know what trap does

but that's very strange!

trap registers signal handlers, but it also supports special events like RETURN and EXIT.

So it turns out that adding another command also works:

bash -c './crash; :' | cat

And putting it before works too, suggesting that it may not have been registering the exit handler that had an effect after all:

bash -c ':; ./crash' | cat

So now running zsh from Bash...

ek@Io:~/source$ zsh -c ./crash
Segmentation fault (core dumped)
ek@Io:~/source$ zsh -c ':; ./crash'
Segmentation fault (core dumped)
ek@Io:~/source$ zsh -c './crash; :'
ek@Io:~/source$

Both with an without the noop added to the beginning in zsh, the interactive Bash shell prints the segfault message.

But when a noop is added to the end, no message at all is printed!

o.O

So now in Zsh, running Dash...

Io% dash -c ./crash
Segmentation fault (core dumped)

Dash prints the message.

Do you use Zsh as your main shell? Like, can you easily not be running it?

Actually it's okay either way.

zsh -c 'echo $$; sleep 100'

I use Bash. I always create a second sudo user and I set Zsh as that user's default shell. But I don't use it very often

That prints the PID of the shell, then runs sleep.

While it's still running, run ps in another terminal with the shell PID printed.

zanna@toaster:~$ ps 7780
  PID TTY      STAT   TIME COMMAND
 7780 pts/3    S+     0:00 sleep 100

So when Zsh knows it doesn't have to do anything else, it doesn't bother forking before execing its last command.

So when you run zsh -c ./crash, there is no zsh process to report the segfault because it has been replaced with the crash process.

It is as though the exec builtin had been used, even though it wasn't.

With Bash, however:

bash -c 'echo $$; sleep 100'

If you run ps with that PID.... well, I get:

ek@Io:~/pl$ ps 25316
  PID TTY      STAT   TIME COMMAND
25316 pts/4    S+     0:00 bash -c echo $$; sleep 100

zanna@toaster:~$ ps 7824
  PID TTY      STAT   TIME COMMAND
 7824 pts/3    S+     0:00 bash -c echo $$; sleep 100

looks like your system has been awake a lot longer than mine (or it's been a lot busier)

It does seem so. :)

Either that or yours has done so much stuff it's cycled around.

haha I hope not, since aside from this investigation I've only opened firefox, checked for updates and started Telegram so far :)

Sorry there's more, I'm just fighting my shell.

more isn't a bad thing...

Yeah iit's the delay I was saying sorry for.

no worries! always plenty to be doing

So, if the optimization of execing when it's the last thing that has to run is applied in Zsh, and that explains how sometimes the it's as though a Zsh shell that ran a command is what's crashing (because "it" is, because zsh has become the command that crashes), then the similar explanation for Bash should be that when Bash runs just a single command, it performs that optimization.

That is, Bash is less aggressive; if there was a previous command, Bash assumes that it shouldn't introduce an exec that was not specified.

I don't know if that's for the purpose of being less astonishing, or if it's so bash doesn't have to figure out if preceding commands changed the shell environment in such a way that it would be bad for it to exec, for example by setting a trap.

But more important, I don't actually know that bash does this at all!

I can't have it print its PID and then run second command and have that second command be the one and only command it ran.

plausible explanation...

Sorry, are you saying you have one or that what I've suggested is one?

sorry, I mean the one you suggested is one

If parameter expansion doesn't affect Bash's behavior, then we can test it by having Bash give its PID to the command, which will then display the value of its command line argument and sleep.

That's the part where I was fighting my shell. :)

IFS= read -r cmd <<'EOF'
perl -we 'use English; print "$ARGV[0] $PID\n"; sleep 100' "$$"
EOF

To check the command:

printf '%s\n' "$cmd"

To use it:

bash -c "$cmd"

I get:

25806 25806

And, while actually unnecessary:

ek@Io:~/pl$ ps 25806
  PID TTY      STAT   TIME COMMAND
25806 pts/4    S+     0:00 perl -we use English; print "$ARGV[0] $PID\n"; sleep

However:

ek@Io:~$ dash -c "$cmd"
25859 25860

And in the other terminal:

ek@Io:~/pl$ ps 25859 25860 | cat
  PID TTY      STAT   TIME COMMAND
25859 pts/4    S+     0:00 dash -c perl -we 'use English; print "$ARGV[0] $PID\n"; sleep 100' "$$"
25860 pts/4    S+     0:00 perl -we use English; print "$ARGV[0] $PID\n"; sleep 100 25859

ooh

(I piped to cat so it wouldn't cut off the output.)

I got the same result

So this fully explains the behavior with non-subshell subprocesses that are noninteractive shells run with the -c. Dash doesn't perform the optimization at all, so it's always around to print its segfault message. Bash performs the optimization when it has just one command, and it doesn't print the message in that situation; its own caller must do so (assuming its own caller isn't performing the optimization, which may always be avoided by using an interactive shell for it).

Zsh performs the optimizations as often as it can: it replaces itself with the last command it runs if it doesn't have anything else to do, even if there were preceding commands. Hence this behavior (noted above), where the interactive Bash caller is printing the segfault message:

ek@Io:~/source$ zsh -c 'echo foo; echo bar; ./crash'
foo
bar
Segmentation fault (core dumped)

So now my question is... does it explain the behavior with pipes?

Do you want to avoid installing additional shells?

To figure out if it makes sense that piping would suppress the messages, it is ideal also to test with a shell that performs this fork-eliding optimization under the same circumstances as Bash, but which has the same pipeline semantics as Zsh. I believe that this is true of ksh93.

In the first Bash shell:

ek@Io:~/source$ ksh93 -c 'echo $$; sleep 100'
26030

no I don't mind installing shells

In the second Bash shell:

ek@Io:~/pl$ ps 26030
  PID TTY      STAT   TIME COMMAND
26030 pts/4    S+     0:00 ksh93 -c echo $$; sleep 100

So ksh93 doesn't go further than bash.

But:

ek@Io:~/source$ ksh93 -c "$cmd"
26207 26207

And:

ek@Io:~/pl$ ps 26207 | cat
  PID TTY      STAT   TIME COMMAND
26207 pts/4    S+     0:00 perl -we use English; print "$ARGV[0] $PID\n"; sleep 100 26207

So ksh93 goes at least as far as bash. Thus ksh93 goes exactly as far as bash -- in the ways this testing method is capable of revealing.

Well now I'm confused, though. In Bash:

ek@Io:~/source$ ./crash | cat
ek@Io:~/source$ cat <<<'' | ./crash
Segmentation fault (core dumped)

Why does that happen in Bash?

I was thinking that the behavior of pipes in suppressing the message may have been the effect of each command in a pipeline of two or more commands being run in a separate subshell. Ksh and Zsh run the last one in the shell that processed the pipeline.

But in Bash, when ./crash is piped to, the message is not suppressed, strongly suggesting that hypothesis is wrong.

I think I am out of my depth with this. It's not something I really know at all. Is that URI reference adequate? Does it need to internal quotes so quote marks will actually surround curl so they will be included in the argument and surround urn: MethodName? Is that advice correct? @Videonauth

^^^ If you're interested in this, I can actually move the above message to the Unix & Linux chat room. (cc @Zanna)

mhmm never used curl much tho

I don't know about that

┌─[03:52:59]─[michael@NEXUS-ONE]
└──> ~ $ curl --header "Content-Type: text/xml;charset=UTF-8" --header "SOAPAction:urn: methodName" --data @request.xml example.com/abcdWarning: Couldn't read data from file "request.xml", this makes an empty POST.
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
	<head>

^ @EliahKagan

had to look up the guys line in history to see how he wrote that

but i dont get could not connect to host like he does, so i think its maybe a newtork setting the culprit?

@Videonauth Well the Java implementation for it worked, though.

the curl line worked too as you can see, no clue what went wrong on his system

i simply took his line unaltered and dont get a host unreachable

i got a proper 404 page in return

Yeah. Well maybe he'll show the Java code. Maybe it was running on a different system, and that system was able to reach the destination?

so there might be multiple possible things that could have gone wrong, firewall interrupting, network setting, messed up system because of dev usage (happens often) and many more, all i can tell since I'm not very good at java overall is that it works on my system which is pretty much unaltered

Well it would be hard to tell without the Java code anyway.

@Zanna I'm concerned that the hypothesis about how Dash doesn't perform the optimization of treating a single command to run as though it is preceded by exec might not actually be sufficient to explain all the situations where Dash actually shows the segfault message.

This whole line of inquiry is motivated by the results of test I ran to try and figure out the answer to this commented question.

During the course of investigating when compound commands can have segfault messages redirected out of the, I noticed that in some cases where I thought I'd successfully piped it to /dev/null, the segfault message was instead being suppressed altogether due to being from a command appearing on (what I now know is specifically) the left side of a pipe.

So here's what's weird. In Dash, you can redirect that message from simple commands!

This is strange because it is not part of the output of the command that crashes. It's not that command that writes the message to stderr, but instead the shell.

I have a named pipe called pipe in the source directory. This is not a shell pipeline and redirecting to it doesn't suppress anything. When I run this in dash, it is sent through the named pipe:

./crash 2>pipe

This also works in ksh93, which I had somehow not noticed before just now.

However, it does not work in bash or zsh.

hmm

@EliahKagan so, is the shell behaving as if it crashed? Or have I lost you?

@Zanna Dash is not behaving as though it has itself crashed.

But when I say, "It's not that command that writes the message to stderr, but instead the shell," I'm describing the expected behavior. Which I do observe. Except possibly in Dash.

oh...

I do not expect that redirecting stderr from a command causes the segfault message that a shell prints when it sees that the command has crashed to be redirected.

oh I see :)

so what's going on?

In spite of the possible clarity from earlier... I feel like I have no idea at all what is going on.

Returning to Bash... applying a redirection also causes the shell to print the message:

ek@Io:~/source$ bash -c './crash </dev/null' | cat
bash: line 1:  1361 Segmentation fault      (core dumped) ./crash < /dev/null

ek@Io:~/source$ bash -c './crash >/dev/null' | cat
bash: line 1:  1377 Segmentation fault      (core dumped) ./crash > /dev/null

Those are being printed by the shell subprocess (the line number refers to the first "line" of the "script" passed after -c.

What about it?

You know you're not redirecting file descriptor 2 to file descriptor 1 there, right?

i redirecting warnings(2) and errors(1) too

Did you mean to write 2>&1?

just > to /dev/null only puts the normal output to /dev/null

yes sorry just see it :) my fingers again have been quicker and turned characters

The syntax to do what you are describe would be 2>&1, which doesn't silence the segfault message, since the segfault message is not actually written by the ./crash command.

What's going on with the command you gave is that the trailing & inside the operand for -c causes the whole command to be run asynchronously. It's because it's in the background that no segfault message is printed. File descriptor 2 is redirected to a file in the current directory whose name is 1, which is empty afterwards, because ./crash doesn't actually write to standard error.

So anyway, for some reason applying a redirection causes bash not to perform the optimization where it replaces itself with the command instead of forking. So, this is the result shown before...

First terminal:

ek@Io:~/source$ printf '%s\n' "$cmd"
perl -we 'use English; print "$ARGV[0] $PID\n"; sleep 100' "$$"

ek@Io:~/source$ bash -c "$cmd"
1435 1435

Second terminal:

ek@Io:~$ ps 1435
  PID TTY      STAT   TIME COMMAND
 1435 pts/4    S+     0:00 perl -we use English; print "$ARGV[0] $PID\n"; sleep

(Sorry, it's cut off, I forgot to pipe to cat, but it's readable-ish.)

But if I then add code for a redirection inside the operand passed to -c then I get two separate processes -- the shell stick around and waits for the command to terminate rather than replacing itself with the command it is running. First terminal:

ek@Io:~/source$ bash -c "$cmd </dev/null"
1443 1444

Second terminal:

ek@Io:~$ ps 1443 1444
  PID TTY      STAT   TIME COMMAND
 1443 pts/4    S+     0:00 bash -c perl -we 'use English; print "$ARGV[0] $PID\n
 1444 pts/4    S+     0:00 perl -we use English; print "$ARGV[0] $PID\n"; sleep

mhmm now you lost me i guess

Well it's related to all the above testing. :)

Starts here.

wanna know how to supress that compiler warning? :)

* crash.c - simple program that crashes by raising a segmentation fault */

#include <signal.h>

int main(void)
{
    raise(SIGSEGV);
    return 0;
}

even if return isn't reached

or you do void main() then you can skip the return

the compiler bickers about being -pedantic and a function which should have a return value having none

@Videonauth That's not the reason it complains. It will not complain if it knows the closing brace is not reached, even with -pedantic. It complains for crash.c because it cannot figure out that raise(SIGSEGV) never returns, because some calls to raise do return.

This program also has no return statement:

/* xhello.c - trivial hello world program calliing exit() and not return */

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    puts("Hello, world!");
    exit(0);
}

well i just put a return =; in my script and it compiled without any output

But when it is compiled the same way, no warning is produced:

gcc -ansi -pedantic -Wall -Wextra -o xhello xhello.c

that is because exit returns an int value too

┌─[18:26:12]─[michael@NEXUS-ONE]
└──> testing $ gcc -ansi -pedantic -Wall -Wextra -o crash crash.c
┌─[18:26:26]─[michael@NEXUS-ONE]
└──> testing $ cat crash.c
/* crash.c - simple program that crashes by raising a segmentation fault */

#include <signal.h>

int main(void)
{
    raise(SIGSEGV);
    return 0;
}

@Videonauth No, that's not the reason. C is not Perl. C does not implicitly return the value of the last expression. And that doesn't even make sense -- raise has int as its return type, too.

@Videonauth Yes, I understand that you can silence the warning by putting return 0; at the end. But your analysis of why the warning is happening is wrong.

The difference between raise and exit is that raise sometimes returns to its caller. exit never returns to its caller, and the compiler knows that.

The warning does not occur because functions of non-void return type need to have return statements to behave predictably. Functions of non-void return type don't need return statements to behave predictably, so long as they never actually return.

well im digging actually through signal.h and so far not see a point that returns a value

en.cppreference.com/w/c/program/raise

yes and you dont store the return value of raise

:) if you want that value returned you should use return raise(SIGSEV);

That reasoning applies equally to:

I don't want the value. raise(SIGSEGV) crashes the program reliably. The purpose of the program is to crash. I understand the warning, I understand why GCC issues it, I understand which options I passed to GCC caused it to be issued, I understand how to suppress the warning if I wanted to, and I don't want to. You seem to think there is a deficiency in my understanding of C relating to this program. There is not.

Also, never use void main().

I not meant to offend you tho

Sorry, I realize I came on really strong there. I am not offended at all! Mildly annoyed, I admit, but that has already past, and you are not at fault.

Well... void main() should offend any C programmer. But besides that... :)

i wouldnt do that and i did my fair share of c++ as well , im actually looking at libc gnu manual and the same for raise why raise doesnt count as valid return valie even if the program exits this way

in --many-- most cases you can trust the compiler when he bickers

well whatever cant edit it anymore lol

Three dashes.

---strikethrough---

strikethrough

But that doesn't work for most places in SE. It works in chat.

hello @karel

I very much agree that compiler warnings should be taken seriously. However, that does not mean that anything that suppresses the warning is reasonable. If somehow a program whose purpose was to crash did manage to fail to crash by raising SIGSEGV on itself, it would not be reasonable for the program to then signal successful termination.

true

well return raise(SIGSEV); produces also no warning

I'm not saying there's anything particularly wrong with having a return 0; afterwards, just that it has no benefit -- it is a less expressive alternative to just not telling the compiler to warn about that.

@EliahKagan ok found it why it behaves like that, exit in fact exits the caller and puts the return-value specified, while raise sends its return-value back to the caller (i.e. the script containing it)

while raise as well exits the caller it does not put a return value

hope that makes sense lol

man7.org/linux/man-pages/man3/exit.3.html and man7.org/linux/man-pages/man3/raise.3.html

Do you just mean that exit never returns? That's what I've been saying this whole time...

That the difference between exit and raise as far as the compiler's ability to assume code after a call is unreachable is that no call to exit ever returns, whereas some calls to raise, with some argument values, do return.

yep and raise returns its value to caller which leaves then the main function without a return value

even if it closes the programm tho

No, in both cases the main function does not return a value. The difference is in what the compiler can easily assume. Calling raise with a signal that terminates the process and for which there is no handler is just as reliable at ensuring that control does not return to the function from which it was called. It would just be considerably more complicated for the compiler to verify that that this is so.

exit calls SIGEND for gracefull ending the program, and raise uses sigkill pskill or tkkill which leaves the caller function without return value

raise does not return its value to the caller even if it closes the program!

well, but on the rest i can confirm bash -c ./crash | cat doesnt return anything

@Videonauth What do you mean by "leaves the caller function without return value"?

@Videonauth You mean it doesn't output anything?

i mean int main() which is the caller, gets a returnvalue but this is not used to return from int main()

What do you mean by "gets a return value"?

Do you mean that the raise function returns a value?

#language_barrier

yes raise returns a value, but this value is not used as returnvalue for main

and this is what the compiler is about

if you do this here:

/* crash.c - simple program that crashes by raising a segmentation fault */

#include <signal.h>

int main(void)
{
    return raise(SIGSEGV);
}

the returnvalue of raise gets used to end the caller (main) gracefully

But that's not true. raise does not return to the caller in that program.

In that program, the raise function is called, but it never returns.

That's irrelevant. raise does not return in this situation because the signal it raises terminates the program. This happens before it can return.

So, there are two issues here, and they are separate. One is whether a function has void or non-void return type. The other is whether or not a function actually returns. All four combinations are possible.

It is possible to call raise and have it actually return a value. That's just not what is happening in this situation.

yes but at compile time it goes from top to bottom of the code in a linear way and this si why the compiler complains

it sees that raise is called does something has a return value which then isnt used to return/exit from the main function

even if that return is in reality never reached

the compiler reaches this point

Are you saying that the return type of the raise function is why the compiler complains? That is not why.

no he compains that main doesnt return anything for a non-void function

But that's not the whole story, because it does not always complain about a main function that doesn't have a return statement.

its like you write a ltter and put "to be continued on page2" at the bottom and never do a second page

If I replace raise with exit or abort, it doesn't complain.

yes i know in normal cases you can simply ommit return

at least in c++

I don't know what you mean by that. It is precisely because this case is unusual that it is okay to omit the return.

Oh. Yeah.

In C99 and newer and in every standard dialect of C++, return 0; is implied if execution reaches the closing brace of the main function.

@Videonauth Can you explain that analogy? What part of the code are you saying is like "to be continued on page2"? Are you saying the int return type in int main(void) is like "to be continued on page2"?

and that behavior of the pipe well i have no clue why it happens

I have some clue why it happens... maybe. :)

well for the compiler the program is your letter and it looks for more to compile at the end below raise

I am really not confident at all in my hypothesis about why the pipe suppresses the segfault message.

and it thinks that returning to end the function is missing

even if we as humans know ok this will never be reached

@Videonauth It would also look for more to compile at the end below exit or abort. The difference is that it is able to verify that the code after that is unreachable, but it cannot verify that the code after the call to raise is unreachable.

@Videonauth Yes. I agree with that entirely.

The key point though is that this relates to what the compiler knows about abort and exit that it does not know about raise, and that information is separate from the return types of those functions.

I mean, if you write a function that can never return and you have full choice of return type, you should probably make it void.

So it seemed like we disagreed before but now I am unsure. All I have been trying to say is that, in this program raise does not actually return. The compiler complains because it cannot verify that it does not return, and thus must assume that it might return. If that is also what you are saying, then we actually agree.

I should mention that there are compilers that fail to notice that code after a call to exit or abort is unreachable. Fortunately GCC, at least with the standard library implementation we're using it with, is able to determine that.

@EliahKagan exact raise doesn't return, or at least the program can not make use of it, i just confirmed by doing this

/* crash.c - simple program that crashes by raising a segmentation fault */

#include <stdio.h>
#include <signal.h>

int main(void)
{
    int i;
    i=raise(SIGSEGV);
    printf("%d", i);
    return i;
}

never outputs 0

Right, that program crashes with a segmentation fault. It does not reach the printf call.

yep but the compiler looks for the lines below it too and translates that in machinecode

the compiler reads the full book even if the leading page says close it now

It does, yes, though it may do that even for unreachable code. It's unlikely it emits unreachable code by default with higher optimizations turned on, but I would expect it to do so without them, at least if -g is passed and probably otherwise.

@Videonauth But that's true even with exit and even if it doesn't emit instructions. The compiler has to process the entire translation unit. For example, in unreachable code that the compiler knows is unreachable, the compiler still verifies the code for correctness.

@Videonauth Regarding what is actually going on that enables the compiler to know that exit never returns: GCC supports attributes with the nonstandard __attribute__ (( ... )) syntax. The standard library implementation that gcc is using on our systems, including the headers in /usr/include, use the __noreturn__ attribute on functions that can never return regardless of what global state exists (including signal handlers) and regardless of the values of their arguments, if any.

yep i think wer both talking more or the less about the same the whole time :)

That may be.

ah see and raise in signal.h has no __noreturn__

because in some cases it can return

Well then I am especially sorry to have expressed myself earlier in an irate manner! I did not mean to act offended at all. My apologies.

@Videonauth Yes.

no worries were all humans and having to think in english is particular hard for me

remember i have to translate my thoughts

:)

And in /usr/include/stdlib.h, the prototype for exit does have the __noreturn__ attribute.

/* Call all functions registered with `atexit' and `on_exit',
   in the reverse of the order in which they were registered,
   perform stdio cleanup, and terminate program execution with STATUS.  */
extern void exit (int __status) __THROW __attribute__ ((__noreturn__));

/* Send signal SIG to process number PID.  If PID is zero,
   send SIG to all processes in the current process's process group.
   If PID is < -1, send SIG to all processes in process group - PID.  */
#ifdef __USE_POSIX
extern int kill (__pid_t __pid, int __sig) __THROW;
#endif /* Use POSIX.  */

and none of the other defines hav it too, there are a couple, and this makes the compiler bcker about seeing no return

→ 3 messages moved to Raiders of the Lost Downboat‌​

and you could send for example raise(SIGPAUSE) which in fact would give the caller the returnvalue and pauses

equivalent of ctrl+z

im still puzzeled about that pipe tho

Or raise an invalid signal and it should immediately fail, I believe.

@Videonauth Yeah that's puzzling.

← 13 messages moved from Raiders of the Lost Downboat‌​