Re: Patch to constify/prototype/clean collect2.[ch] & tlink.c, part 1/2

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Jason Merrill <jason@cygnus.com>
 > 
 > >>>>> Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:
 > 
 >  > Please sanity check that doing this is okay, especially where I pass the
 >  > result as a function arg.  (I seem to recall someone telling me once its
 >  > bad to use alloca in a function call parameter???  I can easily fix that
 >  > one case to not do so.)
 > 
 > It's very bad non-ACCUMULATE_OUTGOING_ARGS targets (i.e. x86), as alloca
 > inserts a bunch of stack space in the middle of the arguments to the call,
 > wreaking havoc.
 > Jason

	Thanks for the info confirming my suspicion.  There is only one
place where I did STRDUPA in a function call in the collect2.c patch:

 > if ((ldptr = ldopen (STRDUPA(prog_name), ldptr)) != NULL)

Now the first argument of ldopen is not supposed to be modified.  On
Irix6 its declared const char *, but on OSF4 and AIX4, its char *.
Bleah.

Since prog_name is const, this is why I duped it.

I could either not dup prog_name, and cast it to char * since I'm
convinced ldopen won't touch it, but that'll warn with -Wcast-qual.
E.g.:

 > if ((ldptr = ldopen ((char *)prog_name, ldptr)) != NULL)

(We could avoid the cast if we teach fixincludes to constify ldopen.
Is there some standard which mandates ldopen's parameters?)


The other option is to assign STRDUPA(prog_name) to a non-const char*
right before the function call and pass that in to ldopen.  E.g.:

 > char *foo = STRDUPA(prog_name);
 > if ((ldptr = ldopen (foo, ldptr)) != NULL)

(This is is guaranteed to work without any special fixincludes and
also won't have a problem with -Wcast-qual.)

With one of these changes, is part 1 of the patch acceptable?

		Thanks,
		--Kaveh
--
Kaveh R. Ghazi			Engagement Manager / Project Services
ghazi@caip.rutgers.edu		Qwest Internet Solutions