On 2017-10-12, Marko Rauhamaa <ma...@pacujo.net> wrote:
> 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.
I meant that in the include files for the C standard library,
functions that aren't going to modify a string paramameter always
declare the parameter as "const char *".
> 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"?
IMO, yes.
> 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.
In my own code I do try to do that, but (as in the Linux kernel code
you posted) you still run into problems using third-party libraries
written by the, um, unenlightened.
> 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)
> {
[...]
> Note how both "req" and "syn" could well be declared as "const" pointers
> but are not.
Yep. IMO, that's just sloppy programming.
--
Grant Edwards grant.b.edwards Yow! Can you MAIL a BEAN
at CAKE?
gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
