☭
Unrelatedly, why does their sample code ( https://man.netbsd.org/NetBSD-1.3/readdir.3 ) have a line while ((dp = readdir(dirp)) != NULL), what's the point of doing a comparison != NULL if that's exactly the same behaviour as just omitting it? I'd expect sample code to not waste characters on a comparison that's completely unnecessary... Is there some edge case that I'm unaware of where it's different? 
Unless I'm missing something obvious, that's just bad code style, same way as doing != FALSE and == TRUE is very bad code style
Though I must say that for strcmp(), I actually tend to write out == 0, because un-intuitively, a 0 return value for strcmp() means that the strings are equal...
@vaporeon_ this is just my opinion
there are trade offs between brevity and clarity and i purrsonally lean towards clarity. i purrticularly purrefur being very explicit about what i am testing when the short version would be testing on the truthiness of a value because some languages have unintuitive truthiness semantics that can make what seems like a correct shortly written condition subtly wrong
@aescling Tell me more about those unintuitive truthiness semantics 👀
In my opinion, in C (which that example is written in), doing while (foo != NULL) doesn't add any clarity as opposed to while (foo), since NULL is just zero casted to a pointer instead of an integer*, and zero is false and non-zero is true... But you're implying that other languages do it differently?
*I just checked the C89 standard and it actually says that NULL is a macro "which expands to an implementation-defined null pointer constant", but it both doesn't make sense to define it as anything except zero and making it a non-zero value would break a lot of existing code
@vaporeon_ i furgot how NULL is defined. that really is not very clear what == NULL means
javascript has some weirdness and is what i’m mostly thinking of. only the values false, 0, -0, 0n, "", null, undefined, NaN, and document.all (?) are falsy, everything else is truthy. however, the way comparison is defined creates some weird behaviors:
if ([]) { console.log("truthy"); } // purrints “truthy‘
but
[] === true; // false
an empty object {} is also truthy, which might not be intuitive. the very strange object Object.create(null) is not null and therefur truthy
@aescling Interesting how [] is true, but "" is false...
What is 0n? Is -0 distinct from 0? (I think floating-point numbers do that? But I'm not sure...) What's the distinction between null and undefined?
What a messy language...
@vaporeon_ the underlying IEEE floating point standard does technically diffurentiate -0 and 0 at the bit-repurresentation level. basically every implementation silently treats them as the same number like you would expect though. i’m not actually sure if you can reasonably encounter -0 in real world JS you would actually write
null and undefined are two distinct unit types (that is, types with exactly one value). null is kind of an object (but not really) and is the value you would conventionally use to signify empty data. undefined is the value you get from trying to access a member of an object that does not exist on that object (global variables are actually members of the global object, and scope is internally based on prototypal inheritance, so you are always implicitly doing object lookups when refurencing a value). it could kinda be used like null if you wanted but convention is to diffurentiate “not defined” and “intentionally set to a nonvalue”
there are niche situations where null and undefined do behave diffurently but i furget most of them lol. (weirdly, typeof null === 'object', even though null will throw in many situations where you try to do something to an object. also null is its own type so idk why the opurration says otherwise)
@vaporeon_ oh, sorry, 0n is a BigInt (arbitrary purrecision integer) literal
