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