[patch] remove a few unnecessary #includes

[Rob Landley]

On Saturday 10 September 2005 16:07, Bernhard Fischer wrote:

> >>   if (opt & CPIO_OPT_TEST) {
> >> -  /* if both extract and test option are given, ignore extract option
> >> */ +  /* if both extract and test options are given, ignore extract
> >> option */
> >
> >This adds a plural s where none is grammatically needed. This is
> >called an ellipsis ("if both extract option and test option are
> >given") and usually considered to be good style.
>
> Ok. wasn't aware of that, sorry.

"If both options are given, ignore extract option."

The s makes sense to me.

> I'm not happy to rely on dead-code elimination in general.

The Linux kernel does this.  (That's where I got this trick from.)

You seem to be worried about the existence of a compiler that supports c99 
data types, yet can't do dead code elimination.  (Actually, we use various 
gcc-isms like __attribute__, abbreviating "x ? x : y" as "x ? : y" (because 
it's smaller, especially if x is an expression), and so on...)

TCC (the "tiny C compiler") supports dead code elimination.  The "Small Device 
C Compiler" (SDCC) supports dead code elimination.  Heck, back under DOS, 
_Turbo Pascal_ supported dead code elimination:

http://www.pcengines.ch/tp3.htm

I'm quite happy to rely on it. :)

> I'd have put all those into an EXIT_CONFIG_BUFFER macro or for my part
> in an xfree() function. None of my business, though.

I'm not against such a macro, but our memory allocation in general needs a 
complete overhaul anyway.  (We leak memory and filehandles all over the place 
on exit right now, which is fine as long as we _are_ exiting and not doing 
longjmp or some such.)

The "buffer allocation policy" subsystem needs a pass over the source code to 
see where it can be applied, and somebody to take point on it.

Anything that outlives the block it's allocated in can't be on the stack, no 
matter what macro you use.  So we still need some mallocs in there.  But the 
only reason _not_ to allocate on stack for the rest of it is if you're 
compiling for a system with an incredibly constrained stack, which pretty 
much means "not Linux" (since I believe even mmu-less linux dynamically 
allocates the stack; Erik can correct me if I've got this wrong...)

There should also be a help entry on why you might want to allocate anything 
in the .bss section.  I look forward to reading it, I have no idea why you'd 
want to do that...

Anyway, I've applied your patch. :)

Rob