This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Include Hackery is dead :-(


A month or so ago, I  played around with a toy to generate
a shell script that did the same thing as the original.
Over the weekend, I changed the template to generate "C"
data structures instead.  It was trivial to get the program
to scan the text of each header file and decide if a particular
fix applied or not.  That hackery was done in about 3 hours.
Five hours after that, I have determined that Sun OS's
SVR4.0 streams code is broken and I am not very interested
in beating my brains against it until I get it to work.

For those interested in gory details:

The method for applying the "sed" fixes was to chain together
sed processes through pipes and let each sed script apply
its changes and pass the resulting text to the next process.
The writer and reader of this chain was this new program that
would check the output for differences before writing the new
replacement header file.

First, I tried a single process writing to one end of cascaded
processes and reading from the other.  To avoid pipe stalls
and deadlock, you must ensure that "canput(9F)" returns "yes"
before you call "putnext(9F)" (i.e. call "poll(2)" before "putmsg(2)"
in user-land).  So, I did all that, and when poll() finally started
indicating that data were ready on the read end, I called
"getmsg(2)" and hung!?!?!  That should absolutely not ever happen.
*ESPECIALLY* since I tried replacing "getmsg()" with "read()" and
retrieved data.  [[using "read()" is dangerous, however, because
the pipe may stall waiting for input and you deadlock on the read end]]

So, I gave up on the single process solution and called "fork()"
to create a child process to read the data off of the pipe.
Right aroung bytes 5120, 10240, ... etc. data would be dropped
and/or repeated.  The magic number "PIPE_BUF" is 5120 on the Sun.
Coincidence, I am sure.

I used this chaining technique on SVR4.2 and it worked fine.
But, I think it is also the case that streams was massively
rewritten for that release.  *sigh*.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]