Setting a const char * in an **argv

[jorba101]

On my platform, I see that if I do following:

void myFunc( const char *myArg )
{
    char **argv;
 
    argv = &myArg;
 
    createTask( ....., argv, .... );
 
}

Compiler complains that I cannot assing argv to point to &myArg - only if the parameter is defined as 'const'. Without the 'const', it works fine.

I wonder then why the address of "myArg" poses trouble to cast it to char ** if it's a const. Does anybody have a clue?

[Banfa]

const char * is a pointer to constant char (or and array of constant char)

char ** is a pointer to pointer to char

The assignment/cast you have done looses the constness of the data you are pointing to and is therefore illegal for a implicit cast.

Without the const you are not loosing the constness of the data and therefore there is no problem.

The other option is to add a const to you declaration of argv.


You could explicitly cast from const char * to char **, the compiler will do this but it is very bad practice as it removes any type safety that the compiler imposes.

In the worst case someone calling the function might pass data that is actually const, that is unchangeable in hardware, and because argv is not const the code using argv could try to change the data pointed to this would likely result in a hardware exception or fail operation of the program.

[jorba101]

You could explicitly cast from const char * to char **,

I'm not trying this, but trying a cast from ptr to const char * to char**. I guess it is what you meant.

I understand from your post that "const char *" means "char pointer to const data" (instead of const pointer to char data, which is what I thought this morning). How could I declare a const char pointer to const char data? And a const pointer to const pointer to const char data? (yes, hard to read). Since I'm pointing "myArg" to a string given by a compile-time macro, I guess that would suit better my case (am I right?).

On the other hand, I can't change the parameters "createTask " is accepting, since it is from an API provided in binary shape (and deals with 99% of the other part of my environment, which is already provided too). Actually, I wonder why they did not made it "const" to "const", or more in general why "argv" as main parameter isn't either: It looks like a dirty hack changing main parameters inside main itself.

Thanks.-

[edwardrsmith]

If you are trying to point to a compile time macro it would be better to use true macro's by using the #define pre-compiler tag. Look up #define in google and that will show you how to use the tag. When it comes time to compile you will have to find out how your compiler allows you to assign macros at compile time.

Edward

[jorba101]

Oops,

maybe I should have said a #define instead of the more confusing term "compile-time macro". A #define is what I meant by "compile-time macro", and is what I'm actually using.

[Banfa]

On the other hand, I can't change the parameters "createTask " is accepting, since it is from an API provided in binary shape (and deals with 99% of the other part of my environment, which is already provided too). Actually, I wonder why they did not made it "const" to "const", or more in general why "argv" as main parameter isn't either: It looks like a dirty hack changing main parameters inside main itself.

The reason the argv of main is not const is that it is derviced from the command line of the program. That means the system has to parse the command line and create the array passed as argv from it in memory.

Therefore the system is writing to memory and passing a pointer to that memory to main. By definition then this memory is not const.

I agree changing argv parameters seems like a dirty hack.


Another explanation is that I believe the const keyword did not exist in early versions of C but that future version have maintained backwards compatibility and therefore argv in main has remained without the const keyword.

[donbock]

On my platform, I see that if I do following:

void myFunc( const char *myArg )
{
    char **argv;
    argv = &myArg;
    createTask( ....., argv, .... );
}

Compiler complains that I cannot assing argv to point to &myArg - only if the parameter is defined as 'const'. Without the 'const', it works fine.

I wonder then why the address of "myArg" poses trouble to cast it to char ** if it's a const. Does anybody have a clue?

myArg is a pointer to read-only chars. This means that myFunc promises not to change the chars pointed to by myArg.

The prototype for createTask apparently declares argv to be a pointer to a pointer to read/writeable chars. This means that the task being created has permission to overwrite the arguments -- which would violate the promise made by the function prototype for myFunc.

You could cast away the const-ness of myArg, but your program might halt and dump core if the created task goes ahead and tries to overwrite the arguments ... or it might work just fine. It depends on your compiler and precisely how myFunc is called.

I can think of two portable and bullet-proof ways to resolve this.

1. Change the prototype for myFunc to declare myArg as "char *". That is, take away the const-ness of myArg at the source rather than casting it away later. This may create new compiler warnings where myFunc is called. You can resolve those warnings by making analogous changes there.

2. Change myFunc to allocate a block of memory of equal size to that pointed to by myArg. (This could be either a dynamic or static allocation depending on exactly how your program sets the size of that block.) Then copy the block pointed to by myArg into your local block. Finally pass a non-const pointer to that local block to createTask. The created task is then free to overwrite the local copy of the arguments. This is only possible if myFunc knows or can compute the size of the block pointed to by myArg.

In the worst case someone calling the function might pass data that is actually const, that is unchangeable in hardware, and because argv is not const the code using argv could try to change the data pointed to this would likely result in a hardware exception or fail operation of the program.

Write-protected hardware is certainly a good reason to use const, but it isn't the only one; although you're right in that it is the most likely way for casting away const-ness to result in a problem for this program.

One minor comment: the name "argv" is not reserved, but its typical usage is as one of the arguments to main(). That isn't exactly the way you're using it here. You might reduce confusion by renaming this variable to something like taskArgv.

Cheers,
Don

[donbock]

I understand from your post that "const char *" means "char pointer to const data" (instead of const pointer to char data, which is what I thought this morning). How could I declare a const char pointer to const char data? And a const pointer to const pointer to const char data? (yes, hard to read).

The short answer is that it depends on whether the word const appears before or after the asterisk (*). This answer is so short that it doesn't really help you.

A slightly longer answer is that you should read pointer declarations involving const and volatile from right to left:

int * const ptr = &someInt;
volatile int * const * whatIsThis;

ptr is a const pointer to an int. You can change *ptr; but you can't change ptr.

whatIsThis is a pointer to a const pointer to a volatile int. You can change whatIsThis; you can change **whatIsThis; but can't change *whatIsThis.

For a really good answer you should use google to find one of the many well-written essays on this topic that are on internet.

Cheers,
Don

[donbock]

2. Change myFunc to allocate a block of memory of equal size to that pointed to by myArg. (This could be either a dynamic or static allocation depending on exactly how your program sets the size of that block.) Then copy the block pointed to by myArg into your local block. Finally pass a non-const pointer to that local block to createTask. The created task is then free to overwrite the local copy of the arguments. This is only possible if myFunc knows or can compute the size of the block pointed to by myArg.

Sorry, that is possibly a very bad idea. Does the task being created persist after myFunc returns? If so, then the quoted suggestion could easily lead to the argv argument to the created task pointing to freed memory. The result would be disastrous. The quoted suggestion could still be used if you were careful to do it in such a way that the local memory block persisted beyond the end of myFunc. But then you might have to worry about a memory leak.
Cheers,
Don

[jorba101]

Well,

First thanks a lot for your suggestions and explanations.

The reason for using const char * was that I was pointing it to a compile-time string (with #define). Compiler did not allow me to do the assignation if I did it to a char *.

So. I looked twice the function the API provides to create a task, which accepts an argv and an argc (this one being int). Instead of passing a string, I passed a number through argc, which suited better my application. At first I did not like this solution since it is a bit of hacking the meaning we know argc and argv should have. Anyaway, I contacted support for the API and told me that there is no process done by my OS with argc and argv, so their values should not keep any relationship.

Your second solution was fine to my case, since after creating the task I wait for it to finnish (it sends a packet, awaits ACK, and joins the thread of myFunc).