 <h3>Source code analysis</h3> <p>There are consistency problems:</p> <pre><code>static pid_t P1, P2, P3; // PIDs for each process int P; // parent PID </code></pre> <p>Why is <code>P</code> and <code>int</code> instead of a <code>pid_t</code>? Why is it global instead of <code>static</code>? Why is it <code>P</code> instead of <code>P0</code>? Should the whole lot be an array?</p> <pre><code>static pid_t P[4]; </code></pre> <p>(There would be benefits to using an array!)</p> <p>There is repetition that should be in a function invoked multiple times:</p> <pre><code>// Sending PIDs to process 1 close(providePIDY1[0]); write(providePIDY1[1], &amp;P, sizeof(int)); write(providePIDY1[1], &amp;P1, sizeof(int)); write(providePIDY1[1], &amp;P2, sizeof(int)); write(providePIDY1[1], &amp;P3, sizeof(int)); close(providePIDY1[1]); // Sending PIDs to process 2 close(providePIDY2[0]); write(providePIDY2[1], &amp;P, sizeof(int)); write(providePIDY2[1], &amp;P1, sizeof(int)); write(providePIDY2[1], &amp;P2, sizeof(int)); write(providePIDY2[1], &amp;P3, sizeof(int)); close(providePIDY2[1]); </code></pre> <p>Note that there's also repetition because the <code>P</code> values aren't an array. There's also a possible portability liability; <code>pid_t</code> does not have to be the same size as <code>int</code>.</p> <p>There are problems with checking inputs:</p> <pre><code>choice = getchar(); if(choice == 's') </code></pre> <p>Since <code>choice</code> is a <code>char</code>, you can get erroneous handling of EOF — if you bothered to test for it. You also leave a newline (at least) in the input, and don't skip leading spaces in the input. You'd likely do better with reading a line of data (<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/fgets.html" rel="nofollow"><code>fgets()</code></a> or POSIX <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/readline.html" rel="nofollow"><code>readline()</code></a>) and then using <code>if (sscanf(buffer, " %c", &amp;choice) != 1) { …handle error… }</code> to get the character.</p> <p>Your next input block is curious:</p> <pre><code>printf("Which process is receiving the signal - 1, 2, or 3?: "); choice2 = getchar(); choice2 = getchar(); printf("\n"); if((choice2 &lt; 1) &amp;&amp; (choice2 &gt; 3)) </code></pre> <p>The first input reads the newline (assuming there were no trailing spaces, etc), and the second gets a <code>'1'</code>, <code>'2'</code>, or <code>'3'</code>. However, you test whether the input value is both less than 1 and greater than 3, and there's no known value in the universe for which both conditions are true (<code>NaN</code> values are unknown values). You really wanted something like:</p> <pre><code>if (choice2 &lt; '1' || choice2 &gt; '3') </code></pre> <p>After you've determined which signal to send (more or less), you have another block of repeated code because you used <code>P1</code> etc instead of an array <code>P</code>.</p> <p>There are chunks of repeated code in your child processes, such as the code that reads the process numbers. These should be in a function, too. The signal handling setup should probably be in a function too, though I've not spent a lot of time checking for the differences and similarities between the different process functions.</p> <h3>Major problem</h3> <p>You say the code is supposed to be processing arithmetic expressions. You have the main program loop reading choices about signal handling, but you seem to have <code>process1()</code> also trying to read expressions. This is bad news; it is indeterminate which of the processes will get to read any given input.</p> <h3>Back to the small stuff</h3> <p>You have:</p> <pre><code>dataSize = strlen(buff) + 1; // plus NULL if(dataSize &gt; 0) write(pfd12[1], &amp;dataSize, sizeof(int)); write(pfd12[1], &amp;buff, sizeof(char)*dataSize); </code></pre> <p>The test is a little pointless; the minimum value that <code>strlen()</code> can return is <code>0</code>, so the minimum value in <code>dataSize</code> is <code>1</code>, so the condition will always be true. (Theoretically, I suppose, you could enter so much data that the <code>size_t</code> returned by <code>strlen()</code> overflows the <code>int dataSize</code>, but you've not allocated enough space for that to be an actual problem — your code will have had other problems before that.)</p> <p>In <code>process2()</code>, this code is curious:</p> <pre><code> token = strtok(buff, delim); while( token != NULL ) { number = strtol(token, &amp;end, 0); if(!isInteger(number)) break; } </code></pre> <p>There are no circumstances under which the <code>int number;</code> is going to be a non-integer when you scan the string with <code>strtol()</code>. You have a risk of overflow (<code>sizeof(int) != sizeof(long)</code> on 64-bit Unix systems, for example). You have a risk of not being able to interpret the remnants of floating point value (because the <code>.</code> is not a valid part of an integer). You'll need to rework that code.</p> <p>There's a lot of repetition in the signal handling code; it should be refactored so that you need fewer functions. It'll be easier to understand in the long run. Copy'n'paste'n'edit is a very bad way of programming when the result is near clones of the code in a single program.</p> <p>I'm not clear what the differences are between the two versions you show; I've not scrutinized them. You should look at how to create an MCVE (<a href="http://stackoverflow.com/help/mcve">How to create a Minimal, Complete, and Verifiable Example?</a>) or SSCCE (<a href="http://sscce.org/" rel="nofollow">Short, Self-Contained, Correct Example</a>) — two names and links for the same basic idea. I'm not sure that either lot of code qualifies as an MCVE; both versions is overkill. Just supply the compilable code.</p> <hr> <h3>After compilation</h3> <p>I've compiled the second chunk of code (saved in a file called <code>procsync.c</code>) on my Mac running Mac OS X 10.10.3 with GCC 5.1.0, and using the command line:</p> <pre><code>$ gcc -O3 -g -std=c11 -Wall -Wextra -Wmissing-prototypes -Wstrict-prototypes \ &gt; -Wold-style-definition -Werror procsync.c -o procsync $ </code></pre> <p>To my considerable surprise, the code compiled under those very stringent options with no complaints — that is something I very seldom see in code on SO.</p> <p><strong>Congratulations!</strong></p> <p>(But there are still the other issues to worry about.)</p>