Board index » cppbuilder » 'const' confusion on my part or compiler bug?

'const' confusion on my part or compiler bug?


2006-04-23 10:19:17 PM
cppbuilder69
Hello out there,
recently an open source project which I try to keep buildable with
Borland's compilers (Tcl in case you ask) started to produce lots of
compile errors on functions which haven't changed for a long time.
Well, to be exact, while the functions' bodies did not change, the
style of _defining_ the functions' parameters did change from
int foo (bar)
int bar
{
/* do something */
}
to
int foo (int bar)
{
/* do something */
}
Now I get compiler errors involving const parameters, like the sample
below shows.
---
/* this compiles */
int someFct1 (objc, objv)
int objc;
char * const objv[];
{
objv += 2; /* no problem here */
return 0;
}
/* but this doesn't */
int someFct2 (int objc, char * const objv[])
{
objv += 2; /* E2024: cannot modify const object */
return 0;
}
/* this however compiles */
int someFct3 (int objc, char * const * objv)
{
objv += 2;
return 0;
}
/* and of course I can always use a cast*/
int someFct4 (int objc, char * const objv[])
{
(char * const *)objv += 2;
return 0;
}
---
'someFct1' is the old style definition, while 'someFct2' is the new
one (the error _number_ is correct, the error _message_ is a
re-translation from German)
I have 2 questions:
1) Am I right in assuming that someFct2 should compile and therefore
exhibits a compiler bug?
2) Are the changes I made in someFct3 and someFct4 correct or would
they introduce new problems?
Any comments on this matter would be greatly appreciated. Oh, the
compiler in question is Builder 5 rsp. the free command line compiler.
Best regards
Helmut Giese
 
 

Re:'const' confusion on my part or compiler bug?

"Helmut Giese" < XXXX@XXXXX.COM >wrote in message
Quote
I have 2 questions:
1) Am I right in assuming that someFct2 should compile and therefore
exhibits a compiler bug?
2) Are the changes I made in someFct3 and someFct4 correct or would
they introduce new problems?
Any comments on this matter would be greatly appreciated. Oh, the
compiler in question is Builder 5 rsp. the free command line compiler.
Let's see the const keyword in C++ again: You can declare your array those
ways:
char *obj[]; // a pointer to array of chars
char * const obj[]; // a const pointer to array of chars
char const *obj[]; // a pointer to array of const chars
char const * const obj[]; // a const pointer to array of const chars
Did you notice the difference?
When you wrote 'char * const obj[]' and tried to increment the pointer obj
you got
that error because the pointer is const (not the chars in the array!). So,
maybe, what you are
looking for is:
int someFct5(int objc, char const *objv[]);
Hope it helped....
Fred
 

Re:'const' confusion on my part or compiler bug?

Hi,
"Frederico pissarra" < XXXX@XXXXX.COM >wrote in message
Quote


char *obj[]; // a pointer to array of chars
According to what I reemember the above notation mean
" array consisting of elements of type char * "
if you want to have a pointer to array you should write
char (*obj)[]; // a pointer to array of chars
Also there are some quirks when arrays are used as a
function's formal parameters for example in declaration
void foo(char arr[10]);
the type of formal parameter is char *
meaning that array parameter "decays" to a pionter to its first element.
Regards,
Zenon
 

{smallsort}

Re:'const' confusion on my part or compiler bug?

"ZJ" < XXXX@XXXXX.COM >wrote in message
Quote
Hi,

"Frederico pissarra" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>
>
>char *obj[]; // a pointer to array of chars
This is a pointer to a pointer... the same as char **obj;
Quote

According to what I reemember the above notation mean
" array consisting of elements of type char * "

if you want to have a pointer to array you should write
char (*obj)[]; // a pointer to array of chars

This is an array of pointers to char....
[]s
Fred
 

Re:'const' confusion on my part or compiler bug?

"ZJ" < XXXX@XXXXX.COM >wrote in message
Quote
Hi,

"Frederico pissarra" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>
>
>char *obj[]; // a pointer to array of chars

According to what I reemember the above notation mean
" array consisting of elements of type char * "

if you want to have a pointer to array you should write
char (*obj)[]; // a pointer to array of chars

Also there are some quirks when arrays are used as a
function's formal parameters for example in declaration

void foo(char arr[10]);

the type of formal parameter is char *
meaning that array parameter "decays" to a pionter to its first element.

Ahhh.... the same way
int (*f)();
is a pointer to a function instead of
int *f()
wich is a function that returns a pointer... Notice that () and [] has
higher precedence than *...
So:
char *a[10]; is a pointer to an array of 10 chars
char (*a)[10]; is an array of 10 pointers to char.
[]s
Fred
 

Re:'const' confusion on my part or compiler bug?

On Sun, 23 Apr 2006 17:20:02 -0300, "Frederico pissarra"
< XXXX@XXXXX.COM >wrote:
Quote

"Helmut Giese" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>I have 2 questions:
>1) Am I right in assuming that someFct2 should compile and therefore
>exhibits a compiler bug?

>2) Are the changes I made in someFct3 and someFct4 correct or would
>they introduce new problems?

>Any comments on this matter would be greatly appreciated. Oh, the
>compiler in question is Builder 5 rsp. the free command line compiler.

Let's see the const keyword in C++ again: You can declare your array those
ways:

char *obj[]; // a pointer to array of chars
char * const obj[]; // a const pointer to array of chars
char const *obj[]; // a pointer to array of const chars
char const * const obj[]; // a const pointer to array of const chars
Hi Fred,
thanks for your thoughts.
This is not _my_ code - I am just trying to compile it with Borland's
compiler. And it worked for several years while this project used the
(very) old style function definition (btw, this is plain C code, no
C++)
int someFct (objc, objv)
int objc;
char * const objv[];
{
objv += 2; /* no problem here */
return 0;
}
Well, as I see it, the intention is to let objv be an array of const
pointers to char, and I certainly don't intend to change anybody
else's intentions regarding his code.
My problem is that the above (C) function now written as
int someFct (int objc, char * const objv[])
{
objv += 2; /* E2024: cannot modify const object */
return 0;
}
doesn't compile anymore. I need a patch which doesn't change the
function's semantics _and_ compiles with Borland.
My current favourite is to write it as
int someFct (int objc, char * const *objv)
{
objv += 2;
return 0;
}
but I wanted a second opinion.
Also, a question to the users of BDS2006: Do the functions from my
first posting compile there, and if not: Is this a compiler bug?
(which I would then report)
Best regards
Helmut Giese
 

Re:'const' confusion on my part or compiler bug?

XXXX@XXXXX.COM (Helmut Giese) wrote:
Quote
int someFct (objc, objv)
int objc;
char * const objv[];
{
objv += 2; /* no problem here */
return 0;
}
(Horribly old C declaration syntax)
Quote
Well, as I see it, the intention is to let objv be an array of const
pointers to char, and I certainly don't intend to change anybody
else's intentions regarding his code.
My problem is that the above (C) function now written as

int someFct (int objc, char * const objv[])
{
objv += 2; /* E2024: cannot modify const object */
return 0;
}

doesn't compile anymore. I need a patch which doesn't change the
function's semantics _and_ compiles with Borland.
According to Comeau (and we all trust Comeau more than any other
compiler, don't we?), that should actually compile. It should treat is
as being your alternate option:
Quote
My current favourite is to write it as
int someFct (int objc, char * const *objv)
{
objv += 2;
return 0;
}
but I wanted a second opinion.
I'd go for that version, since it's what the compiler *should* have
translated the previous version as.
It looks as though the compiler is treating the type of objv as if it
were an actual array:
int someFct (int objc)
{
char * const objv[1] = {0};
objv += 2; // This SHOULD fail to compile
return 0;
}
Alan Bellingham
--
ACCU Conference 2007 - venue to be determined.
 

Re:'const' confusion on my part or compiler bug?

"Helmut Giese" < XXXX@XXXXX.COM >wrote in message
Quote
/* but this doesn't */
int someFct2 (int objc, char * const objv[])
{
objv += 2; /* E2024: cannot modify const object */
return 0;
}

/* this however compiles */
int someFct3 (int objc, char * const * objv)
{
objv += 2;
return 0;
}

/* and of course I can always use a cast*/
int someFct4 (int objc, char * const objv[])
{
(char * const *)objv += 2;
return 0;
}
---
'someFct1' is the old style definition, while 'someFct2' is the new
one (the error _number_ is correct, the error _message_ is a
re-translation from German)

I have 2 questions:
1) Am I right in assuming that someFct2 should compile and therefore
exhibits a compiler bug?
yes, it is compiler bug
Quote
2) Are the changes I made in someFct3 and someFct4 correct or would
they introduce new problems?
someFct3 is correct
someFct4 is not ( result of your cast is rvalue and you can not apply += to
it )
Cheers,
Serge
 

Re:'const' confusion on my part or compiler bug?

Hi,
"Frederico pissarra" < XXXX@XXXXX.COM >wrote in message
Quote
So:

char *a[10]; is a pointer to an array of 10 chars
char (*a)[10]; is an array of 10 pointers to char.

I think it is the opposite i.e.
char *a[10]; is an array of 10 pointers to char.
char (*a)[10]; is a pointer to an array of 10 chars
Regards,
Zenon
 

Re:'const' confusion on my part or compiler bug?

XXXX@XXXXX.COM (Helmut Giese) writes:
Quote
Now I get compiler errors involving const parameters, like the sample
below shows.
---
/* this compiles */
int someFct1 (objc, objv)
int objc;
char * const objv[];
{
objv += 2; /* no problem here */
return 0;
}

/* but this doesn't */
int someFct2 (int objc, char * const objv[])
According to the ISO C++ Standard, this is equivalent to
int someFct2 (int objc, char * const * objv)
...
Quote
{
objv += 2; /* E2024: cannot modify const object */
... so this is a compiler bug, because this should compile ...
Quote
return 0;
}

/* this however compiles */
int someFct3 (int objc, char * const * objv)
{
objv += 2;
... as does this.
Quote
return 0;
}

/* and of course I can always use a cast*/
int someFct4 (int objc, char * const objv[])
{
(char * const *)objv += 2;
I would always try hard to find a C++ cast operator for a workaround
like this (if I really needed a cast), and add a comment giving an
explanation. Or how should anybody underrstand why a cast from a type
to itself is performed?
Quote
return 0;
}
---
'someFct1' is the old style definition, while 'someFct2' is the new
one (the error _number_ is correct, the error _message_ is a
re-translation from German)

I have 2 questions:
1) Am I right in assuming that someFct2 should compile and therefore
exhibits a compiler bug?
Yes.
Quote
2) Are the changes I made in someFct3 and someFct4 correct or would
they introduce new problems?
If someFct3 works, it is correct.
If this is reproducible in C++ Builder 6 and/or BDS 2006 (which I
can't check from here), it would be nice if somebody filed a bug.
 

Re:'const' confusion on my part or compiler bug?

"Frederico pissarra" < XXXX@XXXXX.COM >writes:
Quote
>if you want to have a pointer to array you should write
>char (*obj)[]; // a pointer to array of chars
>

This is an array of pointers to char....
No. The parentheses cause * to precede [].
 

Re:'const' confusion on my part or compiler bug?

Hi Alan,
Quote
>int someFct (objc, objv)
>int objc;
>char * const objv[];
>{
>objv += 2; /* no problem here */
>return 0;
>}

(Horribly old C declaration syntax)
I agree, but at long last they changed it.
Quote

>My current favourite is to write it as
>int someFct (int objc, char * const *objv)
>{
>objv += 2;
>return 0;
>}
>but I wanted a second opinion.

I'd go for that version, since it's what the compiler *should* have
translated the previous version as.
Thanks for your opinion. Yes, I will patch the sources this way,
because it has the added benefit that one patch per (offending)
function will suffice, while patching all the non-compiling uses would
require some more patches.
Thanks again and best regards
Helmut Giese
 

Re:'const' confusion on my part or compiler bug?

On Mon, 24 Apr 2006 18:23:01 +0200, XXXX@XXXXX.COM (Thomas Maeder
[TeamB]) wrote:
Hi Thomas,
Quote
>/* but this doesn't */
>int someFct2 (int objc, char * const objv[])

According to the ISO C++ Standard, this is equivalent to

int someFct2 (int objc, char * const * objv)
thanks for the confirmation.
Quote
>{
>objv += 2; /* E2024: cannot modify const object */

... so this is a compiler bug, because this should compile ...
Ok
Quote
I would always try hard to find a C++ cast operator for a workaround
like this (if I really needed a cast), and add a comment giving an
explanation. Or how should anybody underrstand why a cast from a type
to itself is performed?
Well, these are only patches to get exisitng sources to compile with
Borland - and probably I am the only one using them anyway :)
But then I will patch the functions parameter list like I did in
someFct3 - this way one patch per offending function will suffice.
[snip]
Quote
If this is reproducible in C++ Builder 6 and/or BDS 2006 (which I
can't check from here), it would be nice if somebody filed a bug.
I will re-post a slightly modified version of my OP to give it greater
visibility and hope that someone with a newer version than Builder 5
will check it.
Thanks for your opinion and best regards
Helmut Giese
 

Re:'const' confusion on my part or compiler bug?

"zj" < XXXX@XXXXX.COM >wrote in message
Quote
Hi,

"Frederico pissarra" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>So:
>
>char *a[10]; is a pointer to an array of 10 chars
>char (*a)[10]; is an array of 10 pointers to char.
>

I think it is the opposite i.e.

char *a[10]; is an array of 10 pointers to char.
char (*a)[10]; is a pointer to an array of 10 chars


Regards,
Zenon
ARGH! That's right... my mistake! sorry!
Of course: char *a[] is the same thing as char **a;
The original thread was about confusion around 'const' keyword.
char const *a; /* The char is constant */
is different from
char * const a; /* The pointer is constant */
[]s
Fred
 

Re:'const' confusion on my part or compiler bug?

"Frederico pissarra" < XXXX@XXXXX.COM >writes:
Quote
Of course: char *a[] is the same thing as char **a;
Only in the declaration of a function parameter.
char *a[] = {
"a",
"b"
};
defines a to be an array, not a pointer.