Comment by za_creature
2 days ago
As opposed to the false positives returned by comparing '*' to itself.
Why * specifically? Why not some random guid generated before committing, if it's so important to not let buggy software crash?
2 days ago
As opposed to the false positives returned by comparing '*' to itself.
Why * specifically? Why not some random guid generated before committing, if it's so important to not let buggy software crash?
I'm agreeing with you, to be clear.
But buggy software might not crash; it might compare NULL == NULL and misbehave, instead.
So there's really no good option here, which is why C is a rancid choice of language for publicly-usable APIs. But we're stuck with it. So it goes.
I've been programming in C since 1978 and never until now heard of a function returning "*" on error.
This specific manifestation of "C is terrible for shared code APIs" is rare.
But issues caused by folks forgetting to check errno, miscomparing NULL to NULL when calling multiple APIs, dereferencing external-API-returned NULL due to missed error checking, mishandling inherited errno after successful action, or--the most common--mishandling negative integer return sentinels meant to indicate errors? Those are incredibly common.
3 replies →
It's not a C thing, it's a Linux thing. The asterisk is relevant to how crypt() is used for /etc/shadow.
11 replies →
C programs wouldn't accidentally compare NULL to NULL. They'd either check for null explicitly, or they'd pass the null to strcmp and crash.