Passing arg from incompatible pointer type

[Chris Readle]

Hi all,

Somewhat new to C and I'm getting the following error from my latest code.

Here's the warning I'm getting:
chris_readle_pr oject3_assignme nt3.c: In function `main':
chris_readle_pr oject3_assignme nt3.c:23: warning: passing arg 1 of
`displaySales' from incompatible pointer type

And here is the code in question:
void inputSales(floa t s[][PRODUCTS]);
void displaySales(co nst float s[][PRODUCTS]);

float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};

inputSales(sale s);

displaySales(sa les); <---------This one gets the error

So, why am I getting the error and what does it mean? And why do I get
it on the second function call and not the first, which seems exactly
the same, other than being to a different function and not declaring the
parameter as a const?

crr

[xarax]

"Chris Readle" <c.******@cox.n et> wrote in message
news:qMnBc.3235 $DQ4.1776@fed1r ead05...

Hi all,

Somewhat new to C and I'm getting the following error from my latest code.

Here's the warning I'm getting:
chris_readle_pr oject3_assignme nt3.c: In function `main':
chris_readle_pr oject3_assignme nt3.c:23: warning: passing arg 1 of
`displaySales' from incompatible pointer type

And here is the code in question:
void inputSales(floa t s[][PRODUCTS]);
void displaySales(co nst float s[][PRODUCTS]);

float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};

inputSales(sale s);

displaySales(sa les); <---------This one gets the error

So, why am I getting the error and what does it mean? And why do I get
it on the second function call and not the first, which seems exactly
the same, other than being to a different function and not declaring the
parameter as a const?

That's the answer. The parameter is declared const
and the passed value is not a const.

[Chris Readle]

xarax wrote:

"Chris Readle" <c.******@cox.n et> wrote in message
news:qMnBc.3235 $DQ4.1776@fed1r ead05...

Hi all,

Somewhat new to C and I'm getting the following error from my latest code.

Here's the warning I'm getting:
chris_readle_ project3_assign ment3.c: In function `main':
chris_readle_ project3_assign ment3.c:23: warning: passing arg 1 of
`displaySales ' from incompatible pointer type

And here is the code in question:
void inputSales(floa t s[][PRODUCTS]);
void displaySales(co nst float s[][PRODUCTS]);

float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};

inputSales(sa les);

displaySales( sales); <---------This one gets the error

So, why am I getting the error and what does it mean? And why do I get
it on the second function call and not the first, which seems exactly
the same, other than being to a different function and not declaring the
parameter as a const?

That's the answer. The parameter is declared const
and the passed value is not a const.

Aha, that's what I suspected.

So this is not any kind of hidden thing that's going to come back and
bite me later? I had noticed that everything seems to run just fine,
but I wanted to make sure that this wasn't something that *could* mess
me up later and also that it's not some big style faux pas of which I
was unaware.

crr

[Old Wolf]

Chris Readle <c.******@cox.n et> wrote:

Hi all,

Somewhat new to C and I'm getting the following error from my latest code.

Here's the warning I'm getting:
chris_readle_pr oject3_assignme nt3.c: In function `main':
chris_readle_pr oject3_assignme nt3.c:23: warning: passing arg 1 of
`displaySales' from incompatible pointer type

And here is the code in question:
void inputSales(floa t s[][PRODUCTS]);
void displaySales(co nst float s[][PRODUCTS]);

float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};

inputSales(sale s);

displaySales(sa les); <---------This one gets the error

So, why am I getting the error and what does it mean? And why do I get
it on the second function call and not the first, which seems exactly
the same, other than being to a different function and not declaring the
parameter as a const?

You can't "do away with const" over 2 levels of indirection. If they
were 1-D arrays it would have been OK. This is touched on in FAQ 11.10.
There's a good reason for this rule (although it escapes me at the moment).

[S.Tobias]

Old Wolf <ol*****@inspir e.net.nz> wrote:

Chris Readle <c.******@cox.n et> wrote:

void inputSales(floa t s[][PRODUCTS]);
void displaySales(co nst float s[][PRODUCTS]);

float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};

inputSales(sale s);

displaySales(sa les); <---------This one gets the error

You can't "do away with const" over 2 levels of indirection. If they
were 1-D arrays it would have been OK. This is touched on in FAQ 11.10.
There's a good reason for this rule (although it escapes me at the moment).

I think that's an interesting problem.

float *pf;
const float **ppcf = &pf; //unsafe, we are lying to ppcf about pf
const float fdata;
*ppcf = &fdata; //legal, pf is pointed to fdata,
//ppcf "thinks" it is safe
*pf = 13; //disaster!

In general, we were lying as to kind of an object pf points to.
But in the original problem we deal with tables and there is
only *one* level of indirection: `sales' decays to:
float (*)[PRODUCTS]
and is passed to `s', which decays to:
const float (*)[PRODUCTS]
(All items in the table are const, so we might say that the
whole "table object" is const.)
It is like passing `float*' to `const float*', with exception
that in this case `float' is actually `float[PRODUCTS]' (or put
a structure there with PRODUCTS members of type float).

This even looks more like a C++ question.
Can anyone comment on this?

--
Stan Tobias

[Dan Pop]

In <2j************ *@uni-berlin.de> "S.Tobias" <sN*******@amu. edu.pl> writes:

Old Wolf <ol*****@inspir e.net.nz> wrote:

Chris Readle <c.******@cox.n et> wrote:

> void inputSales(floa t s[][PRODUCTS]);
> void displaySales(co nst float s[][PRODUCTS]);
>
> float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};
>
> inputSales(sale s);
>
> displaySales(sa les); <---------This one gets the error

You can't "do away with const" over 2 levels of indirection. If they
were 1-D arrays it would have been OK. This is touched on in FAQ 11.10.
There's a good reason for this rule (although it escapes me at the moment).

I think that's an interesting problem.

float *pf;
const float **ppcf = &pf; //unsafe, we are lying to ppcf about pf
const float fdata;
*ppcf = &fdata; //legal, pf is pointed to fdata,
//ppcf "thinks" it is safe
*pf = 13; //disaster!

In general, we were lying as to kind of an object pf points to.

But in the original problem we deal with tables and there is
only *one* level of indirection: `sales' decays to:
float (*)[PRODUCTS]
and is passed to `s', which decays to:
const float (*)[PRODUCTS]
(All items in the table are const, so we might say that the
whole "table object" is const.)
It is like passing `float*' to `const float*', with exception
that in this case `float' is actually `float[PRODUCTS]' (or put
a structure there with PRODUCTS members of type float).

This even looks more like a C++ question.
Can anyone comment on this?

Staying away from "const" helps preserve your sanity (and your hair).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Chris Readle]

Dan Pop wrote:
-snip-

Staying away from "const" helps preserve your sanity (and your hair).

Dan

Is there another way to simulate least privilege here? This is a
display function that should never modify the data in question, but
*does* need to read it? Or should I just leave it modifiable and make
in clear in comments (not that this code will ever be seen by anyone but
me and my instructor, but I'm speaking more generally here) that to
modify the table in displaySales will bring a slow and painful death?

crr

[S.Tobias]

Dan Pop <Da*****@cern.c h> wrote:

In <2j************ *@uni-berlin.de> "S.Tobias" <sN*******@amu. edu.pl> writes:

Old Wolf <ol*****@inspir e.net.nz> wrote:

Chris Readle <c.******@cox.n et> wrote:
> void inputSales(floa t s[][PRODUCTS]);
> void displaySales(co nst float s[][PRODUCTS]);
>
> float sales[SALESPEOPLE][PRODUCTS] = {{0}, {0}, {0}, {0}};
>
> inputSales(sale s);
>
> displaySales(sa les); <---------This one gets the error [snip]But in the original problem we deal with tables and there is
only *one* level of indirection: `sales' decays to:
float (*)[PRODUCTS]
and is passed to `s', which decays to:
const float (*)[PRODUCTS]
(All items in the table are const, so we might say that the
whole "table object" is const.)
It is like passing `float*' to `const float*', with exception
that in this case `float' is actually `float[PRODUCTS]' (or put
a structure there with PRODUCTS members of type float).

This even looks more like a C++ question.
Can anyone comment on this?

Staying away from "const" helps preserve your sanity (and your hair).

Thanks for advice, a few years too late, though. As for my hair - soon
there might be no issue :)
I have run OP's code through on-line como: error (warning) in C99
and C90 mode in strict (relaxed) mode, and no diagnostics in C++ mode.
Similarly with gcc/g++.

In C99 Std 6.5.16.1 (Simple assignment): "[...] type pointed to by the
left has all the qualifiers of the type pointed to by the right;",
and argument passing relies on assignment for that matter (6.5.2.2).

In C++ the right expression is converted to the type of left one,
which includes Qualification conversion (4.4), which is slightly
more complicated and more logical than in C IMO.

To sum up: C (unnecessarily) requires all pointed to cv-quals the
same and there's no way without a cast - even if we drop const in
fn parameter, we might want to pass `const float[][]' and run into
same problem - unless we "stay away from const" completely.
(There you are, I've almost come to the same conclusion...)

--
Stan Tobias

[S.Tobias]

Chris Readle <c.******@cox.n et> wrote:

Is there another way to simulate least privilege here? This is a
display function that should never modify the data in question, but
*does* need to read it? Or should I just leave it modifiable and make
in clear in comments (not that this code will ever be seen by anyone but
me and my instructor, but I'm speaking more generally here) that to
modify the table in displaySales will bring a slow and painful death?

My advice would be to keep it as it is, and cast the argument, and
document why the cast was made:
void displaySales(co nst float s[][PRODUCTS]);
void test()
{
displaySales( (const float (*)[PRODUCTS]) sales); /*cast in const*/
}
My personal way of _documenting_ this is a la C++ (though its meaning and
usage is *completely different*):
#define const_cast(type ) (type)
displaySales( const_cast(cons t float (*)[PRODUCTS]) sales);
But some people don't like it.

--
Stan Tobias

[Chris Readle]

S.Tobias wrote:

-snip a bunch of my crap-

My advice would be to keep it as it is, and cast the argument, and
document why the cast was made:
void displaySales(co nst float s[][PRODUCTS]);
void test()
{
displaySales( (const float (*)[PRODUCTS]) sales); /*cast in const*/
}

-snip-

First, thanks for all your help.

Ok, let me see if I understand this, the call:
displaySales((c onst float (*)[PRODUCTS]) sales); is basically saying:

"Call the function displaySales with the array sales cast as a pointer
to a const of type float." Is that correct?

I may be dense (ok, so no "may" about it ;) ), but what is the
[PRODUCTS] doing inside the cast?

crr