tmLQCD Passing constant pointers

Nothing very important, but my compiler whines about this. In recent code, I've been seeing the following syntax crop up repeatedly where const pointers are supposed to be passed:

const char const *git_hash

This is syntactically equivalent to

char const const *git_hash or const const char *git_hash

What is presumably intended is:

char const * const git_hash

Const is allowed on both sides of the type declaration for some reason, but that leads to ambiguities for pointers. In those cases, only a post-fix const qualifier will work. I propose we try to use the post-fix version everywhere to avoid confusion.

Jan 08 '13 09:01 deuzeman

What was intended was:

const char * const

which is a constant pointer to a constant object. This should also be equivalent to:

char const * const

By contrast,

double * const

which is what we usually use is a constant pointer to a possibly non-constant object. (therefore causing the compiler to reload said object at each dereference of the pointer, unless the compiler recognizes the constant-ness of the object through inspection)

see here for a very insightful listing: http://www.codeguru.com/cpp/cpp/cpp_mfc/general/article.php/c6967/Constant-Pointers-and-Pointers-to-Constants.htm

Jan 08 '13 13:01 kostrzewa

I introduced this, for instance, in expo:

void exposu3_check(su3* const vr, const su3adj* const p, int im)

where the momenta are passed as a constant pointer to a constant object.

Jan 08 '13 13:01 kostrzewa

I fully agree with the modification! The only problem was that the compiler complained about double constant declarations, because the code as written did not actually declare a constant pointer to constant data. Writing either const char * const or char const * const is completely equivalent, but we need to be careful not to confuse this with const char const *...

Jan 08 '13 13:01 deuzeman

I'm just wondering where the warning originated because write_first_messages has the correct pointer, no?

Jan 08 '13 14:01 kostrzewa

Oh, I see, sorry that's my bad!

Jan 08 '13 17:01 kostrzewa

In fairness, this may actually just be in one function. I fixed this before somewhere, but it may well have been in the same function on a different branch. And anyway, it's just a warning. It's just that the Intel compiler is very vocal about it and kind of starts spamming the warning whenever the header is included. :)

Jan 08 '13 18:01 deuzeman