Lies in education [was Re: The "loop and a half"]
bartc
bc at freeuk.com
Thu Oct 12 11:57:23 EDT 2017
On 12/10/2017 16:18, Marko Rauhamaa wrote:
> Grant Edwards <grant.b.edwards at 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;
> }
> ========================================================================
If you took a working C program and removed all the consts, it would
still work.
I don't think the language would miss them if they were to disappear.
It is anyway too crude a technique for the things people like to apply
it to.
>
> Note how both "req" and "syn" could well be declared as "const"
> pointers but are not.
const pointer, or pointer to const struct? Or both?
With a const struct, you are stopped from directly modifying elements,
but if an element is a pointer, nothing stops you writing to what the
pointer points to, unless that has a const target too. And then you've
going to have problems doing normal updates. This constness just
insinuates itself everywhere.
--
bartc
--
bartc
More information about the Python-list
mailing list