Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

parent-child with pipe

where is the problem in my code below?
/*
pipes2.c
*/
#include<stdio.h>
#include<unistd.h>
#include<stdlib.h>
#include<string.h>

int main(){
    int pfd[2];
    char buff[80];
    int chid;
    char* parent_message="hello my child!!\n";
    
    
    int result=pipe(pfd);
    if (result==-1){return -1;}
    
    chid=fork();
    if (chid==-1){return -1;}
    if (chid==0){
         char msg[80];
         //memset(msg,0,strlen(msg));
         read(pfd[0], msg, sizeof(msg));
         printf("   read: %s", msg );  
         exit (0);       
    }
    else{//parent
        write(pfd[1], parent_message, strlen(parent_message));
        printf("written: %s", parent_message);
        wait(NULL);
        }

    
    return 0;
}

Open in new window

I 'm taking some "garbage" at printf
0
dimi67
Asked:
dimi67
  • 2
1 Solution
 
Martin_J_ParkerCommented:
I just compiled that code on Redhat Enterprise 4 and it writes out:
written: hello my child!!
   read: hello my child!!

What system/compiler are you using?
0
 
phoffricCommented:
29:   write(pfd[1], parent_message, strlen(parent_message));

Notice that you are not including the terminating string null byte.

22:         char msg[80];  
23:         //memset(msg,0,strlen(msg));

Probably you meant sizeof since msg[80] is on the stack and has garbage in it.
Or, leave 23 commented out and use char msg[80] = ""; which initializes the entire msg to 0's.

But filling the array with 0's is unnecessary (and time-consuming) if the parent includes the terminating null byte. Without this null byte your printf writes the message but doesn't stop until it reaches a null byte (and if far enough out, you could get a segmentation fault).



0
 
dimi67Author Commented:
yes, it's ok, now..
I'm using cygwin, but  why there is no problem to "native" linux?
0
 
phoffricCommented:
For a POD type auto variable on the stack, in absence of explicit initialization, they are said to have garbage in them. This means that whatever was in memory before is still there. It can vary from one compiler to another. In your case there weren't enough 0's lying around to act as a lucky null terminator.

(BTW - on an older SCO Unix system, the stack was often zero'd out, and this default behavior caused havoc when a new SCO compiler arrived due to poor programming practices of failing to properly initialize variables on the stack.)

If you do a man g++ on your cygwin compiler, you will find an enhanced warning switch:

=================
-Wuninitialized
    Warn if an automatic variable is used without first being initialized or if a variable may be clobbered by
    a "setjmp" call.

    These warnings are possible only in optimizing compilation, because they require data flow information that
    is computed only when optimizing.  If you do not specify -O, you will not get these warnings. Instead, GCC
    will issue a warning about -Wuninitialized requiring -O.

    If you want to warn about code which uses the uninitialized value of the variable in its own initializer,
    use the -Winit-self option.

    These warnings occur for individual uninitialized or clobbered elements of structure, union or array
    variables as well as for variables which are uninitialized or clobbered as a whole.  They do not occur for
    variables or elements declared "volatile".  Because these warnings depend on optimization, the exact
    variables or elements for which there are warnings will depend on the precise optimization options and
    version of GCC used.

    Note that there may be no warning about a variable that is used only to compute a value that itself is
    never used, because such computations may be deleted by data flow analysis before the warnings are printed.

    These warnings are made optional because GCC is not smart enough to see all the reasons why the code might
    be correct despite appearing to have an error.  Here is one example of how this can happen:

            {
              int x;
              switch (y)
                {
                case 1: x = 1;
                  break;
                case 2: x = 4;
                  break;
                case 3: x = 5;
                }
              foo (x);
            }

    If the value of "y" is always 1, 2 or 3, then "x" is always initialized, but GCC doesn't know this. ...

This warning is enabled by -Wall or -Wextra in optimizing compilations (-O1 and above).

=================

Bottom line is for you to always compile with the -Wall option to get as many warnings as possible and then correct them. This will not only help you get a working program faster, but should also improve portability.
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now