Multilib swamp

[Peter Dufault]

On Mar 1, 2005, at 8:30 PM, Till Straumann wrote:

>> So, I see where you're coming from, but can you help address the 
>> above concern at the same time?
>
> Hmm - it's still a little different from syntax checking [interpreted 
> vs. compiled]. You still
> could end up compiling for the wrong variant - an error which you 
> would detect only
> at run-time.

Right, but that's why so much of quality control depends on process and 
control of process.


> OTOH, the run-time checking also allows application code to behave 
> differently
> [without having to propagate #ifdef], e.g.,
>
> if ( set_dbat(8,xxx) ) {
>   /* use another method, complain or disable feature on this platform 
> */
> }
>
> vs.
>
> #ifdef __xxx__
> set_dbat(8,xxx);
> #else
> use_other_method();
> #endif
>
> I would argue that whereas conditional compilation reduces the 
> 'vaguearies of run-time code
> path determination' it shifts this problem simply to compile-time 
> [many possibly erroneous
> #ifdef combinations are never really tested or even seen by the 
> compiler - hence the fact
> that the compiler/linker doesn't detect an error on a given platform 
> doesn't prove that
> your code is correct either

You've got a great example on your side here, though you didn't point 
it out explicitly, "set_dbat(8" doesn't look any different than 
"set_dbat(3" to the compiler, and depending on how I add DBAT8 that 
won't be picked up at all.  But your discussion of #ifdef combinations 
isn't valid in my opinion because if I'm concerned about testing a 
given combination of pre-processor definitions then I can easily reduce 
my testing to be against that specific case in a way that is much 
easier than testing against run-time code that supports all cases.

>
> Short answer: I guess I have no good answer...

Me neither.

>
> Cheers
> T.
>
>
Peter Dufault
HD Associates, Inc.