Constant strings

[Tim Rentsch]

As far as I can gather from my experiment below, a string constant
in source code has a 'char*' type, not 'const char*'. Why is that?

Here, I can't get a compiler to complain about passing a string
constant as a char* parameter where it is clearly going to be
modified.

If you happen to be using gcc, the "-Wwrite-strings" option
causes string literals to be treated as if they were const.
This causes gcc to be non-conforming if you use it along with
"-pedantic-errors", [because then the messages associated with
violations are errors rather than warnings, and so forth].

I found this consequence of -pedantic-errors -Wwrite-strings a
little suprising, although personally it doesn't bother me. At
some level, however, I would call it a bug in gcc, because how
the option is specified (ie, using -W) would seem to imply a
distinct condition, but gcc lumps it in with other pointer
conversion problems. For example, I believe most people would
expect, based on the gcc documentation, that the combination of
compiler options

-Werror -Wwrite-strings -Wno-error=write-strings

would give only warnings in such cases, by analogy with, eg,

-Werror -Wunused-variable -Wno-error=unused-variable

but on trying them with gcc I found the second set worked but the
first set didn't. And the reason why seems obvious, namely, that
by the time the violation has been detected gcc has forgotten
that it arose as a result of -Wwrite-strings.

 

[Ian Collins]

Yes it does. I'm just saying there are plenty of situations where functions
modify string arguments etc, but you don't want your data changed. 'const'
is only of use in certain places.

The above is a very vexing parse! Care to elabourate?

Which in this case, isn't very useful: you can pass writeable or read-only
strings to it, just like you can to a function not using 'const'; what have
we gained?

Clarity without he need for a comment. In the C++ world (or with strong
warnings with some C compilers), no diagnostic message. Lack of const
in parameter declarations is a silent accident waiting to happen in C
and a pain in the arse in C++.

Maybe they will help trap any attempts to write via the pointer p, but then
the code will likely not work anyway. But there are plenty of other ways to
shoot yourself in the foot (running past the end of the string for example).
All I know is the code is much easier on the eye without those consts.

The are plenty of ways to get killed in a car crash, but are they valid
reasons not to wear a seat belt?

I mean, most people surely don't bother with marking arbitrary files in
their file systems as read-only, why the need to do it with type-specs in a
language?

Conscientious admins often do. We also mark whole filesystems as read
only as a security measure. See the analogy?

 

[Rosario193]

In what language? That's not what "const" means in C.

it would be all easier if not exist read only memory

 

[Keith Thompson]

Yes it does. I'm just saying there are plenty of situations where functions
modify string arguments etc, but you don't want your data changed. 'const'
is only of use in certain places.

I still honestly don't know what you're talking about.

If you don't want your data changed, don't pass it to a function that's
going to change it.

If you define your data as "const", and you're calling a function that
doesn't use "const" on its parameter declaration, then the compiler will
diagnose an attempt to call the function.

Which in this case, isn't very useful: you can pass writeable or read-only
strings to it, just like you can to a function not using 'const'; what have
we gained?

The "const" on strlen's parameter doesn't enforce any restriction on the
argument you pass it; rather, it allows you to pass either const or
non-const data. Removing the "const" (implying that strlen might modify
the string) would cause the compiler to diagnose any attempt to call the
function with a pointer to non-const data (with the previously discussed
loophole for string literals). For example, this requires a diagnostic:

void transmogrify(char *param) {
}

int main(void) {
const char arg[] = "hello";
transmogrify(arg);
}

Sure, you could avoid all those annoying diagnostics by removing "const"
from the language -- but then the compiler couldn't warn you about
incorrect code that modifies read-only data.

[...]

Take this fragment of code posted by Stefan Ram in 'question about scanf':

char const * const string = "abc17";
char const * p = string;

Maybe he was being deliberately obfuscatory here, or maybe not. But those
consts do nothing for the clarity of the code (actually they make things
worse: I didn't know you could write char const as well as const char; I
thought I had that sussed).

The flexibility in where "const" can be placed is admittedly
unfortunate. But each of the three occurrences of "const" in that code
is a compiler-enforced assertion that something won't be modified.

Maybe they will help trap any attempts to write via the pointer p, but then
the code will likely not work anyway. But there are plenty of other ways to
shoot yourself in the foot (running past the end of the string for example).
All I know is the code is much easier on the eye without those consts.

If my code isn't going to work, I'd much rather find out about it when I
try to compile it.

Personally, I think C and most other languages got this whole thing
backwards. If I were designing a new language from scratch, with no
concern for backward compatibility, I'd make everything read-only by
default, with an explicit qualifier (perhaps "var") to mark objects as
writable. Of course that can't be done for C.

 

[Kaz Kylheku]

it would be all easier if not exist read only memory

"All" would be easier?

Really, now; don't you think that is a bit of an exaggeration ...

Would it be easier for a computer to boot without some read-only memory? Or at
least erasable, re-writable read-only memory?

"All" would not be easier, would it.

In general, stuff that doesn't change is easier to deal with than stuff which
changes.

A large number of bugs comes from unintended modification to read-write
storage; and pretty much all the hard-to-find ones fall into this category.

 

[Rosario193]

[...]
"const" would exist for declare memory space too and not one type
so "const int *p;"
means that p can point only mem that is const

In what language? That's not what "const" means in C.

it would be all easier if not exist read only memory

"All" would be easier?

Really, now; don't you think that is a bit of an exaggeration ...

Would it be easier for a computer to boot without some read-only memory? Or at
least erasable, re-writable read-only memory?

i say programs are easy to write if all mem they have to deal is (read
and write) or (not read and not write)

"All" would not be easier, would it.

In general, stuff that doesn't change is easier to deal with than stuff which
changes.

yes but one has to reserch the perfection and the easy of write
complex algo

A large number of bugs comes from unintended modification to read-write
storage; and pretty much all the hard-to-find ones fall into this category.

i not find that, but i have little experience

 

[BartC]

The above is a very vexing parse! Care to elabourate?

I still honestly don't know what you're talking about.

Take any function F having a T* parameter (any sort of pointer).

Take any call passing it a T* argument.

I'm saying that if F does modify the caller's data, and the caller doesn't
want it to be modified, then using const is not going to help any. You can't
use it for the parameter, because then a compiler error is raised within F.

You might try casting the argument to (const T*), but then you just get a
compiler error here; what good will that do? You need to call F, so a
solution has to be found. And you wouldn't have deliberately put in this
cast unless you'd already researched the side-effects of F, in which case
you don't need the compiler to tell you what you already know!

Or maybe you routinely just use (const T*) casts everywhere you ever pass a
pointer to anything, but then I wouldn't want to have to read your code!

Actually I can't see point of using 'const T*' as any function parameter
type, since it will accept both const and non-const arguments (but see
below).

Using T* for a parameter and 'const T*' for the argument, I can sort of see
the point of, for the small number cases where the caller's data genuinely
is read-only (but one of the most common examples of such data, a string
constant, is let through.)

If you don't want your data changed, don't pass it to a function that's
going to change it.

The function may need to write to the data to do its job. (The alternative
might be for it to allocate memory, copy the data, then de-allocate, all
extra overhead and extra memory.) Provided the side-effects are documented,
this might be acceptable to some callers. Otherwise the caller can choose to
provide a copy.

The "const" on strlen's parameter doesn't enforce any restriction on the
argument you pass it; rather, it allows you to pass either const or
non-const data. Removing the "const" (implying that strlen might modify
the string) would cause the compiler to diagnose any attempt to call the
function with a pointer to non-const data (with the previously discussed
loophole for string literals).

Then you also get rid of the compiler checks at the same time. (Don't forget
in this sub-thread we were discussing removing 'const' from the language.)

 

[BartC]

BartC wrote:


Conscientious admins often do. We also mark whole filesystems as read
only as a security measure. See the analogy?

Does marking a top-level path as read-only protect also the paths and files
lower down, whatever their individual attributes? (As write-protect might
work with removable media.)

If so, then that's not how const works in C. If you have a file F within a
directory hierarchy like this:

/A/B/C/F

And A is read-only, while F is read-write, then in C, you could still modify
F. You just couldn't change A itself.

That's a complicated way of doing it; a single top-level attribute would
have been better.

 

[James Kuyper]

On 04/21/2014 05:51 AM, BartC wrote:
....

Take any function F having a T* parameter (any sort of pointer).

Take any call passing it a T* argument.

I'm saying that if F does modify the caller's data, and the caller doesn't
want it to be modified, then using const is not going to help any. You can't
use it for the parameter, because then a compiler error is raised within F.

Error messages are precisely the kind of help that is provided as a
result of using 'const'. If you prefer not to be informed about the fact
that a given line of code attempts to modify something that should not
be modified, don't use it.

You might try casting the argument to (const T*), but then you just get a
compiler error here; what good will that do? You need to call F, so a
solution has to be found.

Yes, either find an alternative to F that doesn't modify the data, or
copy the data to a location where it doesn't matter if the data is
modified, and pass the modified location to F. Correct use of 'const'
results in a warning that you need to choose one of these alternatives.
Never using 'const' means you get no such warning.

Or maybe you routinely just use (const T*) casts everywhere you ever pass a
pointer to anything, but then I wouldn't want to have to read your code!

It's hard to come up with a situation where (const T*) is needed, since
a T* value can be used just about anywhere that a const T* is called
for. It's the opposite direction where a cast is needed: if you have a
const T*, and you need to pass it to a function which will not be
modifying it, but the function declares the corresponding parameter as a
T*. Such casts are dangerous, because you're placing your trust in the
author of that function to not attempt to modify the object pointed at.
If he doesn't understand C well enough to understand why the parameter
should have been declared 'const T*', there's a serious risk that such
trust is not deserved.

Actually I can't see point of using 'const T*' as any function parameter
type, since it will accept both const and non-const arguments (but see
below).

It should only be used for a given function parameter when the function
will NOT be modifying anything by dereferencing the pointer. If that's
the case, it's equally safe to pass either a const T* or a T* through
that parameter - why shouldn't it be allowed? it's the other way around
that is the dangerous case that should not be allowed, and is therefore
a constraint violation.

Using T* for a parameter and 'const T*' for the argument, I can sort of see
the point of,

Such code is in fact pointless: if the parameter is T*, that means the
thing it points at might get modified. If the corresponding argument is
const T*, that means that the thing it points at should not be modified.
Passing such an argument through such a parameter is necessarily a logic
error: it puts something that should not be modified at risk of being
modified. That's why such code is a constraint violation. Mandating that
a diagnostic be produced in this case is one of the key purposes for
using 'const'. Thinking that such code has a point betrays a complete
misunderstanding of what 'const' is for. I'm having a lot of trouble
figuring out what the nature of your misunderstanding is.

The function may need to write to the data to do its job.

Which is why data that should NOT be written to should not be passed to
to the function. Guaranteeing that attempting to do so will generate a
diagnostic is the advantage that is obtained by declaring the argument
'const'.

(The alternative
might be for it to allocate memory, copy the data, then de-allocate, all
extra overhead and extra memory.) Provided the side-effects are documented,
this might be acceptable to some callers. Otherwise the caller can choose to
provide a copy.

Declaring the corresponding parameter without 'const', and declaring the
data with 'const', and getting a diagnostic message when the discrepancy
is detected, is far more reliable than counting upon users to remember
the documented requirements.

 

[Keith Thompson]

Take any function F having a T* parameter (any sort of pointer).

Take any call passing it a T* argument.

I'm saying that if F does modify the caller's data, and the caller doesn't
want it to be modified, then using const is not going to help any. You can't
use it for the parameter, because then a compiler error is raised within F.

If F modifies the caller's data, and the caller doesn't want it to be
modified, then the caller shouldn't call F. If the caller correctly
declares its data as "const", then the compiler will warn about any
attempt to pass it to F.

You might try casting the argument to (const T*), but then you just get a
compiler error here; what good will that do? You need to call F, so a
solution has to be found. And you wouldn't have deliberately put in this
cast unless you'd already researched the side-effects of F, in which case
you don't need the compiler to tell you what you already know!

What do you mean "you need to call F"? F is going to modify the data,
which you've already says you don't want it to do.

Perhaps you could provide an example of what you're talking about; your
description isn't helping (at least it's not helping me).

Or maybe you routinely just use (const T*) casts everywhere you ever pass a
pointer to anything, but then I wouldn't want to have to read your code!

Actually I can't see point of using 'const T*' as any function parameter
type, since it will accept both const and non-const arguments (but see
below).

Yes, a function with a "const T*" parameter will accept both "T*" and
"const T*" arguments. A function with a "T* parameter will accept "T*"
argument, but *not* "const T*" arguments -- because by defining the
argument as "const T*", you're saying you don't want the data modified,
but the function, by not using "const", does not promise not to modify
it.

If you take a correct program and remove all occurrences of "const"
(including those in the standard library), you'll still have a correct
program.

The purpose of "const" is entirely to detect logical errors at
compilation time. You have to use it consistently and correctly to
enable it to do so.

Using T* for a parameter and 'const T*' for the argument, I can sort of see
the point of, for the small number cases where the caller's data genuinely
is read-only (but one of the most common examples of such data, a string
constant, is let through.)


The function may need to write to the data to do its job.

Then you can't call it with data that you don't want modified.

[...]

Then you also get rid of the compiler checks at the same time.

Right, which is exactly why removing the "const" on strlen's parameter
would be a bad idea.

(Don't forget
in this sub-thread we were discussing removing 'const' from the language.)

I'm talking about the problems that would be caused if "const" were
removed from the language; briefly, it would become more difficult to
write correct code. I've never advocated removing "const" from the
language. Are you advocating that?

 

[Keith Thompson]

For example, system executables are typically under /bin and/or
/usr/bin, and are generally read-only for all but the root user.
I *hope* you wouldn't suggest allowing ordinary users to modify
files under /bin.

Does marking a top-level path as read-only protect also the paths and files
lower down, whatever their individual attributes? (As write-protect might
work with removable media.)

Assuming we're talking about a Unix-like file system, no, it doesn't.

If so, then that's not how const works in C. If you have a file F within a
directory hierarchy like this:

/A/B/C/F

And A is read-only, while F is read-write, then in C, you could still modify
F. You just couldn't change A itself.
Exactly.

That's a complicated way of doing it; a single top-level attribute would
have been better.

Unix-like systems allow you (at an administrative level) to mark
an entire file system as read-only. They also allow you (at a
user level) to mark individual files and directories as read-only.
You can read a file only if both the file system settings and the
permissions on the file permit it.

If you want to mark an entire hierarchy of files and directories
as read-only, you have to change the permissions for everything in
that hierarchy -- which is easy enough to do ("chmod -R -w ...").

A single top-level attribute would be much less flexible.

I'm not sure this is a useful analogy for C "const" semantics.

 

[Malcolm McLean]

So what's your solution? Would you drop "const" from the language?
Suppose you have a function that modifies a string, and you accidentally
pass it a string literal; do you not *want* the compiler to warn you?
(C compilers typically won't warn in that case, but I don't think that's
an argument for loosening the const rules.)

Of course if you specify that string literals shall be read-only, and you try to write to one, you
should have a warning. But an essential problem of language design is that people who design
languages tend to take easy-to-identify programmer mistakes like that, and use them to drive the
language design. In reality, if a function modifies a string, the caller is going to want to use the result.
So as long as he knows that string literals are not writeable, he's unlikely to pass one, except maybe
in experimental diagnostic programming. Even if he doesn't know that string literals are not
writeable, only rarely will he want to modify one in place. So it's just a slight issue, which will
trip up a programmer occasionally, but not very often, remembering that there will be hundreds
of other logic and other errors he makes in the same program whilst it's under development.

I don't have an easy answer, but essentially const makes the wrong distinction, which is between
opaque and transparent pointers, not between writeable and non-writeable ones. Normally it's
none of caller's business whether a subroutine is setting flags in a structure passed to it or not.

 

[Malcolm McLean]

And how often are you going to want to modify data in place in a string
containing CSV data? You can only do that if the replacement data is
exactly the same length as the original data; you can't change
"...,9,..." to "...,10,..." without shifting the rest of the string and
perhaps allocating extra memory. I'd say it's perfectly acceptable in
this case to provide *only* a function that doesn't let you modify
anything. (And if you really need to modify the string, you can either
write that second function or *carefully* use casts to override the
"const".)

This is it. Rarely. So the const version will be fine, until someone wants to put all the alphabetics
into upper case or something. Then the const becomes a thundering nuisance. Saying that it
can be cast away is a desperate solution.

 

[Ian Collins]

Of course if you specify that string literals shall be read-only, and
you try to write to one, you should have a warning. But an essential
problem of language design is that people who design languages tend
to take easy-to-identify programmer mistakes like that, and use them
to drive the language design. In reality, if a function modifies a
string, the caller is going to want to use the result. So as long as
he knows that string literals are not writeable, he's unlikely to
pass one, except maybe in experimental diagnostic programming. Even
if he doesn't know that string literals are not writeable, only
rarely will he want to modify one in place. So it's just a slight
issue, which will trip up a programmer occasionally, but not very
often, remembering that there will be hundreds of other logic and
other errors he makes in the same program whilst it's under
development.

Maybe at one level, but it's not that simple if your are in a function
that passes on a parameter. Then there's no way of telling whether the
input data is writable or not.

I don't have an easy answer, but essentially const makes the wrong
distinction, which is between opaque and transparent pointers, not
between writeable and non-writeable ones. Normally it's none of
caller's business whether a subroutine is setting flags in a
structure passed to it or not.

Do what? Are you happy to check the state of said structure after every
call to see if it has been changed?

 

[Ian Collins]

This is it. Rarely. So the const version will be fine, until someone
wants to put all the alphabetics into upper case or something. Then
the const becomes a thundering nuisance. Saying that it can be cast
away is a desperate solution.

It also the wrong solution. You transform the data, then parse it.

 

[BartC]

If F modifies the caller's data, and the caller doesn't want it to be
modified, then the caller shouldn't call F.

How is it going to get the job done otherwise? If changing the passed data
is a problem for the caller, then it arranges for it not to be a problem
(such as passing a copy of the data).

What do you mean "you need to call F"? F is going to modify the data,
which you've already says you don't want it to do.

Perhaps you could provide an example of what you're talking about; your
description isn't helping (at least it's not helping me).

This must occur everywhere where function parameters do not have 'const' in
their types. Does every single call to such functions always apply a (const
char*) or equivalent cast to each argument just in case it might write to
it? (Which would be lying anyway as it wouldn't be read-only, but a weak
attempt to apply write-protection)

But usually you would have some clue as to what each function did and how it
worked.

Otherwise, for 'const' to be any use at all, you would have to blindly apply
it just about everywhere.

As for an example, this is derived from an actual project: you have a
tokeniser function F which takes a string representing a source file, and
generates a list of tokens. String/name tokens might make use of pointers
(ie. slices) into the caller's string.

But it may be necessary for the caller's string to be modified (convert to
lower case, convert string const escapes, add 0-terminators etc) for this to
work.

That's fine if the caller agrees, otherwise (because it needs to preserve
the original for error reports, or it doesn't own the data) then it might
just pass a copy.

Another example (contrived this one), you have a function F that needs to
invert, reverse, or do some operation to some data (string or image for
example) in order to display the result or whatever. But the operation is
reversible. After the call, the caller's data is unchanged, but it needs to
be writeable.

Or maybe F needs to do some irreversible operation, and it is simplest to do
it in-place (like my first example). Maybe that's OK for the caller, maybe
not. But /how is const going to help in specifying such a function/? It
won't. That's why I say it's not of vital importance to the language.

It might be of help in the odd place, but that's offset by the extra clutter
that can make it harder to see real bugs.

 

[Martin Shobe]

How is it going to get the job done otherwise? If changing the passed data
is a problem for the caller, then it arranges for it not to be a problem
(such as passing a copy of the data).

There are many ways to get the job done otherwise. Call something that
does what F does but doesn't modify the string. Make a copy of the
string and pass that to F. Find a way to get the larger task done that
doesn't need to call F. Etc. Another possibility is that the attempt to
call F was a mistake on the programmer's part.

Personally, I think C made the right choice in assuming that the attempt
to call F was a mistake on the programmer's part. By doing so, and
warning the programmer during the compilation, the programmer has the
ability to fix the problem. If you where to have the compiler
automatically create a copy and pass it to F, then the program would
silently be wrong if that wasn't the correct way to get the job done.

This must occur everywhere where function parameters do not have 'const' in
their types. Does every single call to such functions always apply a (const
char*) or equivalent cast to each argument just in case it might write to
it? (Which would be lying anyway as it wouldn't be read-only, but a weak
attempt to apply write-protection)

Of course you don't case at every single call. Usually when something
needs to be unchanged, you either create the object as a const or you
extract the portion of the code into a function that has a pointer to
const as a parameter. No casts are needed.

But usually you would have some clue as to what each function did and
how it
worked.

Otherwise, for 'const' to be any use at all, you would have to blindly
apply
it just about everywhere.

As for an example, this is derived from an actual project: you have a
tokeniser function F which takes a string representing a source file, and
generates a list of tokens. String/name tokens might make use of pointers
(ie. slices) into the caller's string.

But it may be necessary for the caller's string to be modified (convert to
lower case, convert string const escapes, add 0-terminators etc) for
this to
work.

That's fine if the caller agrees, otherwise (because it needs to preserve
the original for error reports, or it doesn't own the data) then it might
just pass a copy.

So pass a copy. I don't see what the problem is here.

Another example (contrived this one), you have a function F that needs to
invert, reverse, or do some operation to some data (string or image for
example) in order to display the result or whatever. But the operation is
reversible. After the call, the caller's data is unchanged, but it needs
to be writeable.

Or maybe F needs to do some irreversible operation, and it is simplest
to do
it in-place (like my first example). Maybe that's OK for the caller, maybe
not. But /how is const going to help in specifying such a function/? It
won't. That's why I say it's not of vital importance to the language.

It helps by warning you if you mistakenly pass it something that
shouldn't be changed.

It might be of help in the odd place, but that's offset by the extra
clutter
that can make it harder to see real bugs.

Such as?

Martin Shobe

 

[James Kuyper]

How is it going to get the job done otherwise? If changing the passed data
is a problem for the caller, then it arranges for it not to be a problem
(such as passing a copy of the data).

And proper use of const (which means, in this case, that the function
which will modify the pointed at data declares the pointer as 'T*', and
the data which should not be modified is declared 'const') guarantees a
diagnostic message warning you about the necessity of performing such a
work-around.

....

This must occur everywhere where function parameters do not have 'const' in
their types. Does every single call to such functions always apply a (const
char*) or equivalent cast to each argument just in case it might write to
it? (Which would be lying anyway as it wouldn't be read-only, but a weak
attempt to apply write-protection)

No. No such cast is needed, it would have no useful effect. Why do you
even suggest such a thing?

But usually you would have some clue as to what each function did and how it
worked.

'const' helps protect against the case where you've forgotten the clue
you once had, or simple typing errors which result in passing the right
argument to the wrong function, or the wrong argument to the right
function, or passing the arguments in the wrong order. If you claim that
you never make such mistakes, then never using 'const' might make sense
for you. However, having seen your messages on this newgroup, I would be
very skeptical of any such claim.

Otherwise, for 'const' to be any use at all, you would have to blindly apply
it just about everywhere.

Applying it blindly would be useless. It would render it impossible to
get anything done. The sole justification for declaring something const
is to ensure that any code which might modify the thing so-declared is a
constraint violation which will generate a warning message indicating
that such code should not be written. Applying 'const' to anything other
than something which should not be written to is pointless, and would
usually prevent the code from even compiling. Why are you suggesting
that such ridiculous coding practices would be necessary?

As for an example, this is derived from an actual project: you have a
tokeniser function F which takes a string representing a source file, and
generates a list of tokens. String/name tokens might make use of pointers
(ie. slices) into the caller's string.

But it may be necessary for the caller's string to be modified (convert to
lower case, convert string const escapes, add 0-terminators etc) for this to
work.

Such a function should use 'T*', NOT 'const T*', thereby ensuring a
diagnostic message if someone makes the mistake of passing it a const
T*, indicating memory which should not be written to.

 

[BartC]

Normally it's
none of caller's business whether a subroutine is setting flags in a
structure passed to it or not.

Assuming you mean a structure passed by reference, then I think it is!

 

[BartC]

It helps by warning you if you mistakenly pass it something that shouldn't
be changed.

Take this code:

/* somewhere in an external library */
void show_inverted(Image_t bm) {
.....
}

/* In your code */
Image_t img;

..... hundreds of lines later...

show_inverted(img);

But you understand that either (1) show_inverted() requires the image to be
writeable, but is unchanged at the end; or (2) show_inverted() will corrupt
the image. How best to make use of 'const' here?

Maybe, you change all these calls (if you have many dozens of them scattered
everywhere) so that they look like this:

show_inverted((const Image_t)img);

But a few problems with this:

(1) It's very ugly.

(2) With more elaborate calls the casts will dominate the names of the
arguments, increasing the possibility of error.

(3) If you have N calls to show_inverted() in your code for each name 'img',
then instead of one 'Image_t', you now have N+1 to maintain. And with
complex code you have to go and look for the actual type. You might also
make some typos on those N extra casts, resulting in one that will still
compile, but is now wrong.

(4) You may not have enough information about 'Image_t' to establish whether
just sticking a 'const' in front will actually do the trick. For example, if
Image_t is just a struct, which is passed by value anyway, then a const
qualifier on the argument is a waste of time.