RE: Include Hackery

RE: Include Hackery

[Bruce Korb]

Ian Lance Taylor wrote:

> The only problem I saw in a quick glance is that using functions in sh
> scripts is unfortunately nonportable.

I am not a portable shell expert.  In fact, I mostly use ksh.
Anyway, I'll regen it and embed it inside the main loop
for anyone that needs it that way.

> In general, this seems like a very promising approach.  It would be
> nice if people on different systems could compare this to the
> traditional fixincludes script.
> 
> You can run
>     fixincludes foo /usr/include

Thanks.  This is what I was hoping people would do.

> Any differences would presumably require investigation.

I can tell you of two that I know about:
1.  the "#undef NULL" inserted before "#define NULL" is left-justified
2.  The commentary to the right of "#else" and "#endif" used to
    be stripped.  I put it inside "/* */".

-- 
Bruce Korb                      | Data Design Systems, Inc.
Korbb at DataDesign dot com     | 45 Cabot Dr., Suite 110
Voice:  408-260-0280            | Santa Clara,  CA   95051
Fax:    408-260-0281            | USA

Re: Include Hackery

[Jim Wilson]

	2.  The commentary to the right of "#else" and "#endif" used to
	    be stripped.  I put it inside "/* */".

Trying to modify what fixincludes does is always a risky business.

What if this commentary includes a comment?  If you have
	#endif foo /* stuff */
you then get nested comments and we still get a warning with -pedantic.

Looking through the ChangeLogs, I see that we did indeed run into a problem
with this, though it is not the first case I thought of.  Consider this
example
	/* Comment out this stuff
        #ifdef foo
	...
	#endif foo
	end of comment.  */
If you fix the foo by changing it to /* foo */, then you now have a nested
comment.  This is worse than what we started with, because this is now a
syntax error regardless of what options are used.

Thu Jul  1 18:15:17 1993  Paul Eggert  (eggert@twinsun.com)

	* fixinc.svr4: Remove everything after #endif, instead of trying
        to turn it into comments, which loses inside comments.
        * fixincludes: Likewise.  Remove #endif workarounds for Ultrix 4.[12]
        and SunOS 4.1, which are no longer needed because of this bug fix.

Jim

Re: Include Hackery is dead :-(

[Bruce Korb]

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*.

Re: Include Hackery is dead :-(

[Jeffrey A Law]

  In message < 34390C06.7553@datadesign.com >you write:
  > A month or so ago, I  played around with a toy to generate
  > a shell script that did the same thing as the original.
Yup.  Unfortunately I never got a chance to look closely at it.

  > 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.
Depending on streams was probably not a good idea anyway.  Though
the idea of avoiding the write if nothing changed is a good one.

jeff