is sizeof(IPV4_LENGTH) and IPV4_LENGTH the same?

[thamanjd]

This is probably more of a general ansi c question but for something like:
uMemcpy(network.ucOurIP, network_back.ucOurIP, sizeof(IPV4_LENGTH));
which appears in application.c...

where IPV4_LENGTH is a define in tcpip.h :

#define IPV4_LENGTH             4

Is the size passed into uMemcpy in fact 4?

Is the following just as valid?
uMemcpy(network.ucOurIP, network_back.ucOurIP, IPV4_LENGTH);

and in this case is the size passed into uMemcpy also 4?

I understand sizeof being used for strings or arrays but for a define this confused me.
JD

[mark]

John

The code using sizeof(IPV4_LENGTH) is incorrect - it should be IPV4_LENGTH.

This is interpreted as sizeof(4) and is equal to 4. I assume that the compiler interprets it as something like sizeof(int).

If one tries sizeof(6) it also inserts 4.

Therefore it works simply because the result happens to be, fortunately, the same. I have corrected this and verified that it doesn't occur anywhere else in the project.

There is one worrying issue - an int is not always 4 since it depends on the processor type and possibly compiler settings. The NE64 uses 2 byte ints and may even be incorrect. I suggest correcting this to be sure.

Regards

Mark

[thamanjd]

ok. that was my gut feeling.
in the NE64 an int is 16bit so only two bytes.
I've now stepped through the code with the debugger and it does in fact pass a value of 2 into uMemcpy.


The sizeof(IPV4_LENGTH) only appears in those few lines that restore a couple of the flash values into the working values (default gateway, mask and ip. And only if dhcp is active) from the webpage (Admin:restore or Admin:Reset) and maybe also from telnet?.

So at the moment, in NE64 which i guess is the only 16 bit target for utasker? only the top two octets of those i.p. numbers are being copied.

JD

[mark]

John

Many thanks for checking that - the NE64 is the only processor supported by the uTasker where int defaults to 16 bits. Therefore this is an important correction there - as you have pointed out it is in a piece of code which is quite rarely used so possibly has not caused a problem, or at least was not noticed.

Regards

Mark