Re: [avr-libc-dev] Question on Optimizations with Linking

[Bernard Fouché]

Colin O'Flynn wrote:

> Would it be a reasonable idea to change the optimization strategy for linking 
> around a bit? Right now for example we already have a few options for printf, 
> and now are looking at different options for itoa.
>
> Although i think the poll concluded with just using a different name, I like 
> the idea of having the same name but different link options.
>
>  
Hi Colin.

My point of view is the opposite: I prefer to clearly see what is 
standard and what is not, down in the code itself. I don't like magic 
features managed by external things like make or the linker. Yes we 
already have printf() with different behaviors selected at link time and 
I don't like it much. I already encountered the situation where one 
programmer lost time by trying to use standard printf() features in a 
project he did not wrote himself, not being aware of the link option 
selecting the 'wrong' printf in his case. I would prefer to have access 
to printf_min() printf_float(), etc. and write code this way:

#define PRINTF printf_float

...

{
 PRINTF("Your result is %f\n",Result);
}

Sure it is heavy. But neat invisible things may quickly become a 
maintenance nightmare in the long run when they are specialized for one 
particular environment.

When you'll have to port your code to another target, you'll groan when 
seeing that stuff like 'itoa_fast()' or 'printf_min()' are undefined. 
But at least you'll know where it is worth spending time.

If everything compiles neatly but the resulting object fails because of 
clever invisible features in some obscure linking script, it will be a 
pain to locate where you have to spend your time to finalize the port.

Now if such a linking strategy becomes standard in different 
environments, I would also agree to use it ;-)

Bernard