tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: make: new modifyer :Y



> |    A = "Yes"
> |    B = "yes"
> |     ...
> |    A == B
> | 
> | suddenly the comparison is done as strings and becomes false, and the
> | program logic fails, probably (by Murphy's Law) in a subtle and
> | aggravating way.

> I see (or at least I get an idea of what you mean).
> I think that in this particular example the ambiguity comes from the fact that
> the semantic of == is not well defined. Would you have two different operators
> for strcmp() and yescmp(), there would probably be no problem, right?

> Anyway, you've convinced me that this should be avoided in make context.

> My original idea was not to go that far and just replace the interpretation of
> a string in a boolean context (like in ".if ${X}") by the extended
> interpretation of "Yes" "1" etc.

> So == should always mean strcmp() and not try to interpret the strings, and
> ".if ${X} && ${Y}" should be "yes"-aware (because && uses boolean operands).
> No matter how much you wire stuff down, the result of a &&-like operator is
> always a boolean and can never be a string.

> I think that's what Aleksey meant as well, but I'm not sure I haven't missed
> the point as well :)

Yes. I meant absolutely the same. For some reason a miscommunication
with other developers is my best friend.

-- 
Best regards, Aleksey Cheusov.


Home | Main Index | Thread Index | Old Index