«

Anand <> writes:
> mauri1106 wrote:
>> Hi, I have a little problem with a pointer.
>> In my project is included an ".h" file with this declaration:
>> "#define pMDMA_D0_START_ADDR ((void * volatile *)MDMA_D0_START_ADDR)"
>> If I assign a value (e.g. *pMDMA_S0_START_ADDR = 0x04000 the
>> compiler give me these 2 warning:
>> ".\init.c", line 105: cc0513: {D} warning: a value of type "int"
>> cannot
>> be assigned to an entity of type "void *"
>> *pMDMA_S0_START_ADDR = 0x04000;
>> ^
>> ".\init.c", line 105: cc0152: {D} warning: conversion of nonzero
>> integer to pointer
>> *pMDMA_S0_START_ADDR = 0x04000;
>> ^
>> Why appears these warnings?
>> thanks, Maurizio
>>
> Searching the archives of the group would give the complete discussion
> about this section.
>
> Here's a snippet from standard:
> "An integer may be converted to any pointer type. Except as previously
> specified, the result is implementation-defined, might not be
> correctly aligned, might not point to an entity of the referenced
> type, and might be a trap representation."
>
> And hence the warnings from the compiler

In addition, the only *implicit* integer-to-pointer conversion is for
a null pointer constant. You can convert an integer value such as
0x04000 to a pointer type, but only with an explicit cast -- and of
course the result may or may not be meaningful.

void *p0 = 0; /* ok, 0 is a null pointer constant */
void *p1 = 42; /* illegal */
void *p2 = (void*)42; /* legal but questionable */

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

thank you for all, with yours answers the problem is solved!
I think I need to understand why... but is solved.

Happy Xmas for all
Maurizio

Anand wrote:
> Flash Gordon wrote:
>> mauri1106 wrote:
> [...]
>>> "#define pMDMA_D0_START_ADDR ((void * volatile *)MDMA_D0_START_ADDR)"
> [...]
>>>
>>>
>>> ".\init.c", line 105: cc0513: {D} warning: a value of type "int" cannot
>>> be
>>> assigned to an entity of type "void *"
>>> *pMDMA_S0_START_ADDR = 0x04000;
>>
>>
>> That's simple. void* is a generic pointer type, so of course you can't
>> read or write through a void* pointer. You need to have a pointer to a
>> complete, known type, e.g. int or char.
> [...]
> That's void** (or at least that's what it's type casted to). So in that
> case doesn't it qualify to be a complete type? (of void*)

I missed that, sorry. In that, if you really do mean to access that
address, and the system you are using will allow you to do that, then
you need a cast because integer types and pointer types are completely
different things (0 is a special case as it is a null pointer constant).

> So for a "void *ptr" , doing "*ptr" is invalid.
> But for "void **ptr", doing "*ptr" is fully valid.
>
> Or did I miss something?

You are correct about that, I missed the second *.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Anand wrote:

[snip]

> And hence the warnings from the compiler

some thing like this removes the warning

*pMDMA_S0_START_ADDR = (void *)0x04000;

In article < .com>,
mauri1106 <> wrote:
>In my project is included an ".h" file with this declaration:
>
>"#define pMDMA_D0_START_ADDR ((void * volatile *)MDMA_D0_START_ADDR)"
>
>If I assign a value (e.g. *pMDMA_S0_START_ADDR = 0x04000 the

As others noted, D0 (dee-zero) vs S0 (ess-zero) makes a big
difference.

That aside, there are a couple of peculiar things going on here.

First, "volatile" suggests you are attempting to program hardware.
This is inherently non-portable. (You can add an abstraction layer,
to make the C code port to "those systems on which the hardare can
be found", and this is often a good idea, but the job itself remains
non-portable so one may as well discard attempts to use nothing
but Standard C. The question then becomes what to put in the
abstraction layer.)

Second, the name MDMA suggests this has something to do with direct
memory access hardware, e.g., I/O devices. (I assume it is not
methylene-dioxy-methamphetamine, aka Ecstasy. ) These tend to
talk to hardware-oriented RAM addresses, rather than C-oriented
software memory addresses. On many machines, the hardware addresses
are different from the software addresses, making C's "void *"
(generic data pointer) type a poor choice for a "hardware DMA
abstraction layer". You probably want some other (likely integral)
type that you can pass around as a "physical address".

This is one of the rare cases where a typedef is useful, e.g.,
using the POSIX namespace:

/* 64-bit physical address, using this compiler's 64-bit integers */
typedef unsigned long long dmaaddr_t;

Or:

/* 32-bit physical address, using this compilers 32-bit integers */
typedef unsigned int dmaaddr_t;

Of course, if "void *" really is suitable for physical DMA
addresses (which also means "you do not need to do arithmetic
on them", which is rare), you could:

typedef void *dmaaddr_t;

In any case, once you have chosen an appropriate "DMA address type",
you can then define a (highly-machine-specific) macro like
pMDMA_S0_START_ADDR using that type:

#define pMDMA_D0_START_ADDR (*(volatile dmaaddr_t *)0x1234567

(although I find that putting these things into data structures
is often wise.)

>... compiler give me these 2 warning:
>
>".\init.c", line 105: cc0513: {D} warning: a value of type "int" cannot
>be
> assigned to an entity of type "void *"
> *pMDMA_S0_START_ADDR = 0x04000;

This is because the thing on the right is an "int" (0x04000 or
16384), while the thing on the left is a "void *".

If you were using a type-alias (typedef) to hide the actual hardware
data type, you might write:

*pMDMA_S0_START_ADDR = (dmaaddr_t)0x4000;

although this obviously assumes that "0x4000" is the correct way
to express the address as an integer (for that particular machine).
If it is in fact the correct way, it seems likely that "dmaaddr_t"
should be integral in the first place.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.