Re: [PATCH v2] setup: don't die if realpath(3) fails on getcwd(3)

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: May 27, 2022, 07:48 UTC
Message-ID: <220527.865ylr4d4g.gmgdl@evledraar.gmail.com>
In-Reply-To: <CABPp-BGZTDKorz+CFScfTfx47c+TuJaAD_Zyyo1Jj_tymYkVXQ@mail.gmail.com>

On Tue, May 24 2022, Elijah Newren wrote:

Show 6 quoted lines

> [...] So, I think the signature of free() is just
> wrong: it should have taken a const void* all along.  Unfortunately,
> the wrong type signature sadly makes people feel like they have to
> choose between (a) dropping the added safety of const that the
> compiler can enforce for you during the lifetime of the variable, or
> (b) leaking memory you no longer need.

Hrm, don't you mean that it would be better as:

	void free(void *const ptr);

Not:

	void free(const void *ptr);

But standard C doesn't make much (any?) use of the former form for its library functions by convention.

c.f.:

	cdecl> explain const void *var
	declare var as pointer to const void
	cdecl> explain void *const var
	declare var as const pointer to void

I.e. the whole point of malloc() is to give us a pointer to memory that isn't "const". If we stored that in a variable that was "void *const" we'd save ourselves from some amount of foot-guns, but you're rarely doing pointer arithmetic accidentally, so probably not really.

But yeah, we really should have this documented somewhere, i.e. the cases where we "lie" and expose a "const char *" which is really (as far as the machine is concerned) mutable.

The confusion being that we're seeking to overlay our own "no, this isn't mutable" on the basis of our desired API boundaries, not just to use it to inform us & the compiler about the "real" nature of the underlying data.