Re: [Gretl-devel] slight inconsistency with strstr truth value

On Fri, 9 Mar 2018, Sven Schreiber wrote: There's no "string" type in C as such; a string is implemented as an array of "char" terminated by a NUL byte (8-bits 0, which can be writted explicitly as '\0'). But in addition a (char *) pointer have have value NULL (pointer-zero, which would be 32 or 64 bits). So in C you have two distinct boolean tests for an object s of type pointer-to-char: if (s) [ OR explicitly, if (s != NULL) ] returns 1 if s is not a NULL pointer. There are no true NULLs in hansl. Then if (*s) [ OR if (s[0]) OR if (*s != '\0') ] returns 1 if the first element of s is not a NUL byte. (This second test will reliably crash your program if s is in fact a NULL pointer, in which case it doesn't have a "first element" at all.) So there isn't a strict analogy between what C does and what hansl (currently, and not fully consistently) does. I think I got a bit carried away with the semi-analogy: "if strstr(s, p)" is a very natural idiom in C but really a bit of a stretch in hansl. So I guess in the long run I'd be inclined to disallow using strings as booleans in hansl, in which case I'd also be open to your suggestion of instring() as an (up-front) boolean twist on strstr(). One other perspective on this: at present we (sort of) treat strings as booleans on the strength of their emptiness or not. But this is inconsistent in a larger sense, since we don't treat (e.g.) bundles or arrays in that way (and I certainly would not want to!). Allin