常量正确性和不可变的分配对象
C 语言显然假定任何已分配对象都存在所有者，即某处必须有人存储指向该对象的非 const 指针，并且此人负责释放。
现在，考虑一个库分配和初始化不可从用户空间代码修改的对象，因此函数调用始终返回 const 限定的指针。
显然，库是对象的所有者，应该保留一个非 const 指针，这有点愚蠢，因为用户已经提供了一个完全有效的但 const 的副本每个库调用的指针。
要释放这样的对象，库必须放弃 const 限定符；据我所知，以下
void dealloc_foo(const struct foo *foo)
{
free((void *)foo);
}
是有效的 C；仅当 foo 参数另外经过 restrict 限定时，它才会无效。
然而，抛弃 const 似乎有些黑客行为。
除了从库函数的所有返回值中删除 const 之外，还有其他方法吗？这会丢失有关对象可变性的任何信息？
During a recent discussion (see comments to this answer), R.. recommended to never create aliases for pointer-to-const types as you won't be able to deallocate the referenced objects easily in a conforming C program (remember: free() takes a non-const pointer argument and C99 6.3.2.3 only allows conversions from non-qualified to qualified).
The C language obviously assumes the existance of an owner for any allocated object, ie someone somewhere has to store a non-const pointer to the object, and this someone is responsible for deallocation.
Now, consider a library allocating and initializing objects which are non-modifyable from user-space code, so function calls always return const-qualified pointers.
Clearly, the library is the owner of the object and should retain a non-const pointer, which is somewhat silly as the user already supplies a perfectly valid, but const copy of the pointer on each library call.
To deallocate such an object, the library has to discard the const qualifier; as far as I can tell, the following
void dealloc_foo(const struct foo *foo)
{
free((void *)foo);
}
is valid C; it would only be invalid if the foo parameter were additionally restrict-qualified.
However, casting away const seems somewhat hack-ish.
Is there another way aside from dropping the const from all return values of library functions, which would lose any information about object mutability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我在 6.3.2.3 中没有读到同样的内容。该段落是关于隐式发生且不需要强制转换的转换。因此，可能不允许从指针到 const 对象的隐式转换，但这并没有说明显式强制转换。
6.5.4 中处理了强制转换，我没有看到任何会限制您对本身不符合
const资格的任何指向const的指针进行强制转换的情况与(void*)。相反，它说所以我在那里读到，如果你明确地做某事，它们是被允许的。
所以我认为以下内容是完全有效的
What 6.5.4 forbits would be the following
char *const p = malloc(1);
free((void*)p); /* expression of cast is const qualified */
作为旁注，对于您的第二条想法，一个库返回一个指向
const限定对象的指针，然后将其置于来电者，对我来说没有多大意义。库内部对象，那么它应该
限定它指向
const的指针以具有一些弱调用者没有的保护
更改它，或者
分配的对象落在
调用者的责任。然后它
不应该太关心是否
调用者更改它，因此它可能会返回
指向非限定对象的指针。如果来电者
然后想要确保
内容并非偶然
被覆盖或者他可能会做的事情
将其分配给 const 指针，例如
他的用途。
I don't read the same thing in 6.3.2.3. That paragraph is about conversions that happen implicitly and that don't need a casts. So an implicit conversion from a pointer-to-
constobject may be not permitted, but this says nothing about explicit casts.Casts are handled in 6.5.4, and I don't see anything that would constrain you from a cast of any pointer-to-
constthat is by itself notconstqualified with(void*). In the contrary it saysSo I read there that if you do things explicitly, they are permitted.
So I think the following is completely valid
What 6.5.4 forbits would be the following
char *const p = malloc(1);
free((void*)p); /* expression of cast is const qualified */
As a side note, for your second line of thoughts, a library that returns a pointer-to-
constqualified object that then is to be placed in the responsibility of the caller, makes not much sense to me. Eitherinternal object, then it should
qualify it pointer-to-
constto have some weakprotection that the caller doesn't
change it, or
allocated object that falls in the
responsibility of the caller. Then it
shouldn't care much of whether the
caller changes it, so it may return
a pointer-to-unqualified object. If the caller
then wants to ensure that the
contents is not accidentally
overwritten or something he might
assign it to a
constpointer, forhis use.
如果您返回 const 限定的指针，则语义是不允许函数的调用者以任何方式修改该对象。这包括释放它，或将其传递给库中的任何函数来释放它。是的，我知道您可以放弃
const限定符，但是这样您就违反了const所暗示的契约。If you return a
const-qualified pointer, the semantics are that the caller of your function is not permitted to modify the object in any way. That includes freeing it, or passing it to any function in your library that would in turn free it. Yes I'm aware that you could cast away theconstqualifier, but then you're breaking the contract thatconstimplies.如果对象确实是不可变的，为什么要给用户提供指向它的指针并冒损坏对象的风险？将对象地址保留在表中，将不透明句柄（整数表索引？）返回给用户并在库例程中接受该句柄。
If the object is truly immutable, why give the user the pointer to it and risk an opportunity of corrupt object? Keep the object address in the table, return an opaque handle (an integer table index?) to the user and accept that handle in your library routines.