Strange behaviour of "setbuf" on HP

Strange behaviour of "setbuf" on HP

Post by Heinz Herbe » Tue, 26 Apr 1994 16:54:55

(Sorry  for the  crossposting,  I  didn't  know  what  newsgroup  was most
appropriate  for this  question.  Followup  has been set to "poster",  and
please reply per email.  Also sorry if this appears more than one time, my
newsreader rejected my posting the first time.  Thank you very much.)

I have encountered some rather strange behaviour of setbuf(3) on a HP 705,
HP-UX 8.07,  standard HP  C-compiler.  I'm writing a plain vanilla  filter
application, in which a process creates two pipes, then forks off a child,
and the child execs another program after connecting its stdin, stdout and
stderr  to  the  pipes   created  just   before.  Parent  and  child  then
communicate via the pipes.

Now the exec'd program is an interactive  application,  which writes a few
bytes to stdout,  then waits for user  input,  then again  writes a little
bit, and reads  again, etc.  And, since stdout is buffered,  the few bytes
usually  remain in the pipe, and the parent process  doesn't get any input
from the pipe.  This behaviour is inacceptable  for my application, and so
I  put  a  "setbuf(stdout,NULL)"  into  the  child  process,  right  after
reconnecting  stdout to the pipe and  immediately  before the exec().  For
some unknown  reason, this does *not* work.  (I have also tried to execute
setbuf() directly on the pipe, with the same (negative) result.)

What does work, however, is placing a  "setbuf(stdout,NULL)"  at the start
of the exec'd program.  In this case, everything works as expected, output
is  available  to the  parent  as  soon  as it is  written  by the  child.
Unfortunately,   the   C-source  for  the  exec'd   program  is  generated
automatically  from a Turbo Pascal  program with a Pascal-To-C  converter,
and is written and  maintained  by another  person (my boss :-), which  is
also  the  reason  for  the  program  not to  contain  a  single  call  to
fflush(stdout).  So I can't rely on a specific behaviour of the program, I
have to use it as is.  (Even if I could safely change the program, I would
consider this a quite unsatisfying kludge.)

Can anyone tell me why setbuf()  works "after" the exec(), but not before?
Does exec() change the file's buffers? Bug? Feature? RTFM?  (which FM? :-)

Thanks a lot in advance for any help and hints (email please),


- Technical University of Vienna, Austria // Institute for Computer Graphics -
- Life would be so much easier if we could just look at the source code.     -


1. SUMMARY: Strange behaviour of "setbuf()"

I had asked why setbuf(stdout,NULL); is ineffective when executed in a child
process just before exec'ing another program, but works fine when executed at
the start of the exec'd program.

I have received quite many responses, all of them boiling down to

         "the data structures that are allocated and used by setbuf()
          are blown away and allocated anew by exec()"

the reason for this being the fact that streams (like stdout) are user data
structures, which are not retained across exec(). Open files however, which
are kernel data structures, are kept open across fork() and exec().

Thanks to all who replied.



- Technical University of Vienna, Austria // Institute for Computer Graphics -
- Life would be so much easier if we could just look at the source code.     -

2. vt issues after mandrake 7.2 upgrade

3. strange behavior from "gdb" and "ObjectCenter"

4. Wanted: X cfg for unknown chipset

5. : Weird ">" redirect behavior vs. ">>" redirect behavior

6. 3ware SATA RAID controller 9550SX?

7. GETSERVBYNAME()????????????????????"""""""""""""

8. Routing problems on Debian

9. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

10. help: "Video7 1024i HT208A" or "HP D2382A" on HP Vectra

11. Strange "w", "who" and "uptime" output

12. Type "(", ")" and "{", "}" in X...

13. terminal behavior after "man", "less", etc.