Lies in education [was Re: The "loop and a half"]

[Grant Edwards]

On 2017-10-12, Marko Rauhamaa <marko at pacujo.net> 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.

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