Grant Edwards <grant.b.edwa...@gmail.com>:
> Using const with strings in C with amateurish libraries is a headache
> because _some_people_ will write their declarations so as to require
> pointers to mutable strings even when they have no intention of
> mutating them. Those people should be hunted down and slapped with a
> herring until they understand the error of their ways.
Hear, hear.
> The standard library is much better about that.
You lost me there.
Seriously, though. C strings are not the most problematic issue. How
about other structures? What about:
long ftell(FILE *stream);
int fgetpos(FILE *stream, fpos_t *pos);
Should that be "const FILE *stream"?
In general, C record definitions (opaque structs) that represent
encapsulated classes don't take a "const" in any context. They *could*
but that isn't the tradition. For example, here's a random function from
the Linux kernel:
========================================================================
static bool tcp_fastopen_cookie_gen(struct request_sock *req,
struct sk_buff *syn,
struct tcp_fastopen_cookie *foc)
{
if (req->rsk_ops->family == AF_INET) {
const struct iphdr *iph = ip_hdr(syn);
__be32 path[4] = { iph->saddr, iph->daddr, 0, 0 };
return __tcp_fastopen_cookie_gen(path, foc);
}
#if IS_ENABLED(CONFIG_IPV6)
if (req->rsk_ops->family == AF_INET6) {
const struct ipv6hdr *ip6h = ipv6_hdr(syn);
struct tcp_fastopen_cookie tmp;
if (__tcp_fastopen_cookie_gen(&ip6h->saddr, &tmp)) {
struct in6_addr *buf = (struct in6_addr *) tmp.val;
int i;
for (i = 0; i < 4; i++)
buf->s6_addr32[i] ^= ip6h->daddr.s6_addr32[i];
return __tcp_fastopen_cookie_gen(buf, foc);
}
}
#endif
return false;
}
========================================================================
Note how both "req" and "syn" could well be declared as "const" pointers
but are not.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
