Annoying const problem

[Old Wolf]

I have a function that always takes 16 bytes of data and doesn't modify
it:

void func( byte const (*data)[16] );

However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

static const byte bar1[16] = { 0 };

int foo()
{
byte bar2[16] = { 0 };

func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Is there any work-around to this, other than defining a const and a
nonconst version of func, or passing a pointer to the first element
of data and thereby losing the compile-time length check?

[CBFalconer]

Old Wolf wrote:

>
I have a function that always takes 16 bytes of data and doesn't
modify it:

void func( byte const (*data)[16] );

However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

static const byte bar1[16] = { 0 };

int foo()
{
byte bar2[16] = { 0 };

func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Is there any work-around to this, other than defining a const and a
nonconst version of func, or passing a pointer to the first element
of data and thereby losing the compile-time length check?

Probably it will be enough to compile with a C compiler. Looks
like you are using C++.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

[Richard Tobin]

In article <11************ **********@n67g 2000cwd.googleg roups.com>,
Old Wolf <ol*****@inspir e.net.nzwrote:

>void func( byte const (*data)[16] );

[Presumably byte is typedefed.]

>However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

You'll have to put in an explicit cast:

func( (byte const (*)[16]) &bar2 );

Of course, this loses the type checking, but only for the cases where
you cast it.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Old Wolf]

CBFalconer wrote:

Old Wolf wrote:

void func( byte const (*data)[16] );
static const byte bar1[16] = { 0 };

int foo()
{
byte bar2[16] = { 0 };

func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Probably it will be enough to compile with a C compiler. Looks
like you are using C++.

Actually I'm not. Thanks for guessing though. What C compiler are
you using that compiles this code without issuing a diagnostic?

typedef unsigned char byte;
void func( byte const (*data)[16] ) {}
int main()
{
byte bar[16] = { 0 };
func( &bar );
}

[Thad Smith]

Old Wolf wrote:

I have a function that always takes 16 bytes of data and doesn't modify
it:

void func( byte const (*data)[16] );

However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

static const byte bar1[16] = { 0 };

int foo()
{
byte bar2[16] = { 0 };

func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Is there any work-around to this, other than defining a const and a
nonconst version of func, or passing a pointer to the first element
of data and thereby losing the compile-time length check?

I think not. The non-const version can, of course, be a wrapper for the
const version.

--
Thad

[Harald van Dijk]

Old Wolf wrote:

CBFalconer wrote:

Old Wolf wrote:

void func( byte const (*data)[16] );
static const byte bar1[16] = { 0 };
>
int foo()
{
byte bar2[16] = { 0 };
>
func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Probably it will be enough to compile with a C compiler. Looks
like you are using C++.

Actually I'm not. Thanks for guessing though. What C compiler are
you using that compiles this code without issuing a diagnostic?

typedef unsigned char byte;
void func( byte const (*data)[16] ) {}
int main()
{
byte bar[16] = { 0 };
func( &bar );
}

The tendra compiler accepts it without a diagnostic. With extra
warnings enabled, it still only warns about an unused variable "data".
Of course, considering gcc, icc and comeau (online) all report an
error, I would not be surprised if it is a bug.

[Richard Heathfield]

Old Wolf said:

I have a function that always takes 16 bytes of data and doesn't modify
it:

void func( byte const (*data)[16] );

However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

static const byte bar1[16] = { 0 };

int foo()
{
byte bar2[16] = { 0 };

func( &bar1 ); /* OK */
func( &bar2 ); /* Error */
}

Please produce the smallest *compilable* program (in the sense that it would
compile if not for your func(&bar2) call) that reproduces the problem.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Old Wolf]

Richard Heathfield wrote:

Old Wolf said:

I have a function that always takes 16 bytes of data and doesn't modify
it:
However, if I try to call it with non-const data, the compiler is
unable to perform the conversion:

Please produce the smallest *compilable* program (in the sense that it would
compile if not for your func(&bar2) call) that reproduces the problem.

See my response to CBF else-thread

[Richard Heathfield]

Old Wolf said:

<snip>

typedef unsigned char byte;
void func( byte const (*data)[16] ) {}
int main()
{
byte bar[16] = { 0 };
func( &bar );
}

I hate questions like this, and I'm not going to try to explain it, but
FWIW:

typedef unsigned char byte;
void func( byte (* const data)[16] ) {} /* observe the difference here */
int main()
{
byte bar[16] = { 0 };
func( &bar );
return 0;
}

compiles cleanly (modulo one utterly irrelevant warning) under gcc, using
moderately strict flags (-W -Wall -ansi -pedantic).

So it seems to me that, once more, we are staring at C's recondite handling
of pointers to const data (as opposed to const pointers to data), the logic
of which I understood for about 20 minutes back in 2001, and promptly
forgot again.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <11************ *********@n67g2 000cwd.googlegr oups.com>,
Old Wolf <ol*****@inspir e.net.nzwrote:

>See my response to CBF else-thread

Since this thread has not yet included a (natural) language flame, I
would point out that "else-thread" should not mean what you want it to
mean. By analogy with "elsewhere" , which means "somewhere else", it
should mean "somethread else" - that is, in a different thread.

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.