Wouldn’t it be cleaner to make the pointer itself const as well?

No, not from the caller’s point-of view:

With void do_something(char const* const string); declaration, the 2nd const is noise.

void do_something(char const *string); is simpler, clearer and sufficient for the caller.

That 2nd const is, in effect, an implementation detail of do_something() used in its definition, something that the caller does not care about and so is noise.

Let’s look at a simpler case first.

Given

void do_something1( int i ) { ... }

void do_something2( const int j ) { ... }

The following applies:

• i is an object of type int.
• j is a constant object of type int.

So,

• do_something1 would be allowed to modify i, and the following is valid:

  void do_something1( int i ) {
     ++i;  // ok
     printf( "%dn", i );
  }
  

• do_something2 would be not allowed to modify string2, and the following is invalid:

  void do_something2( const int j ) {
     ++j;  // ok
     printf( "%dn", j );
  }
  

Keep in mind that parameters are local to their function, so changes to them have no effect in the caller. So making the parameter const only serves to shackle the writer of the function. The benefits of doing so are elusive to me.

The same applies in your code.

Given

void do_something3( char const *s ) { ... }

void do_something4( char const * const t ) { ... }

The following applies:

• s is a pointer to a constant object of type char.
• t is a constant pointer to a constant object of type char.

So,

• do_something3 would be allowed to modify s, and the following is valid:

  void do_something3( char const *s ) {
     while ( *s ) {
        putchar( *s);
        ++s;  // ok
     }
  }
  

• do_something2 would be not allowed to modify t, and the following is invalid:

  void do_something4( char const * const t ) {
     while ( *t ) {
        putchar( *t );
        ++t;  // XXX
     }
  }
  

Again, keep in mind that parameters are local to their function, so changes to them have no effect in the caller. So making the parameter const only serves to shackle the writer of the function. The benefits of doing so are elusive to me.

The reason why a parameter with a type like const int* const param is confusing is because this is a local copy of the original pointer. The caller shouldn’t need to know or care what your function does with that local copy internally – it won’t affect the calling code anyway.

Those who typically insist on *const qualified parameters are often intermediately skilled C programmers who have just learnt of the feature. And now they eagerly seek to over-engineer their programs by using it where it isn’t needed. A good rule of thumb is to not use various more or less obscure language features just for the heck of it.

In fact there are very few uses of *const qualified pointers – the main valid use of the feature is when you want to allocate pointer tables in true NVM memory in embedded systems. For example a function pointer look-up/state machine etc:

typedef void func_t (void);

func_t* const my_func [n] = { ... }; // this will get allocated in NVM

We really don’t want to change function pointer addresses in run-time and with *const we’ll be allocating them in flash memory instead of RAM – the latter is usually more valuable.

Another argument is that it’s also somewhat common to modify the pointer parameter inside the function. Consider something like a common implementation of strcpy:

char* my_strcpy (char* dst, const char* src)
{
  char* original = dst;

  while(*dst++ = *src++) ... // do some copy implementation and use the `dst` variable in it

  return original;
}

API code provided by microcontroller manufacturers (which is supposed to be well written)

I must have seen such code a hundred times during my 20+ years as microcontroller dev, but I have yet to see well-written code obtained from a silicon manufacturer…

Remember that the parameters of a function are copied into a functions’ scope. The prototype of the function acts like a promise to the function user. In general the user does not care about function internals. That being said, the programmer might want to leverage the compiler to enforce certain behaviors within the function. So the prototype declaration does NOT need to match the translation unit definition with regard to const of the parameter itself.
This allows the programmer to make certain hints to the compiler and optimizer on how it can handle the parameter internally, but not clutter
the prototype with meaningless info.

The header file

#ifndef PARAM_SCOPE_H
#define PARAM_SCOPE_H

void const * do_something(char const *my_buf);

#endif // PARAM_SCOPE_H

The translation unit

#include "param_scope.h"
#include <string.h>

void const * do_something(char const * const my_buf)
{
    char another_buf[10];
    memcpy(another_buf, my_buf, sizeof another_buf);
    return my_buf;
}

But if someone comes along later and adds code ahead of the memcpy that accidently modiifies the parameter variable my_buf, the compiler will complain.