Problem with a pointer

[mauri1106]

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

 

[Ravi Uday]

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

How is pMDMA_S0_START_ADDR defined ?

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;

^
Thats probably because your #define is pMDMA_D0_START_ADDR
^^
and error you got points to *pMDMA_S0_START_ADDR
^^

Post the real code please !
One more suggestion is you could look at the pre-processor output
to see how your macro has expanded in the code.

- Ravi

 

[mauri1106]

I'm sorry, is correct with "S0" in assegnation!

 

[Flash Gordon]

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)"

I assume that you also have something like the following in our header:
#define MDMA_DO_START_ADDR 0x12345678

In future, please provide a *complete* minimal example that shows the
problem (compilable, unless the problem is that it won't compiler).

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;

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.

".\init.c", line 105: cc0152: {D} warning: conversion of nonzero
integer to
pointer

That's simple as well. The only integer to pointer fully defined by the
C standard is that 0 converts to a null pointer. For the rest, it is
implementation defined with one possible definition being that there is
no integer type large enough to represent pointers.

*pMDMA_S0_START_ADDR = 0x04000;
^

Why appears these warnings?

Because you are writing terrible code. I'm guessing that you are trying
to access hardware directly, but depending on the OS you are using (if
you are using one) this may not be possible, but even if it is the
compiler needs to know the type of what it is trying to access.

 

[mauri1106]

the correct assegantion is:

"#define pMDMA_S0_START_ADDR ((void * volatile *)MDMA_S0_START_ADDR)"

The code is very simple and in prctice is only this declaration, the
others parts work correctly.

Thanks

 

[Anand]

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

 

[mauri1106]

Dear anand, can you better explain your answer? I don't understand what
do you want to say.
thanks

 

[Chuck F.]

Dear anand, can you better explain your answer? I don't
understand what do you want to say. thanks

I suggest you do some reading about how to post etc. on usenet.
Here is some info, and there are more links in my sig. below.

"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

--
Some informative links:
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

 

[Anand]

<quote-correction>
mauri1106: Please ensure to quote the previous reply. This gives a
context to the mail. I've corrected this time.

> Anand Wrote:
>
>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."

>

I assume you didn't search the archives of this group.

What you have is a void**ptr. So the moment you redirect it you have is
a void* (a pointer) and you are assigning an integer value to it.
And hence the warnings.

"ptr <- integer" is an implementation defined behavior and it's not
guaranteed to work.

Anyway, only valid and portable integer value that can be assigned to
any pointer is 0. (Which is NULL pointer).
If you are trying to assign any other integer to the pointer it purely
depends on your compiler and platform as to how to treat it.

The hard coded integer value you are assigning is purely dependent on
your environment in which the code is going to run.
For all you know you memory location 0x04000 could be invalid (you might
not have access to it).
Or there's no way to represent a memory location using just integers in
your system.

There are times when this may be valid (and in those cases you are very
much aware of it.) But then it's still the duty of your compiler to warn
you.

Now you decide, do you always have access to 0x4000 memory location (if
that's how you refer a location in your system) is valid and you have
full rights and doesn't cause any problem in that particular system.

 

[Anand]

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*)

So for a "void *ptr" , doing "*ptr" is invalid.
But for "void **ptr", doing "*ptr" is fully valid.

Or did I miss something?

 

[Keith Thompson]

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 */

 

[mauri1106]

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

 

[Flash Gordon]

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 *.

 

[haroon]

Anand wrote:

[snip]

And hence the warnings from the compiler

some thing like this removes the warning

*pMDMA_S0_START_ADDR = (void *)0x04000;

 

[Chris Torek]

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 *)0x12345678)

(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.