IPv6 Address

[sarathius]

How to get the IPv6 address in run time and print the same... I have did the following program, but it is printing some garbage values. It is not taking the value which i am giving...

#include<stdio.h>
 struct in6_addr
 {
  unsigned char s6_addr[16];
 };
                                                                                                                             
int main()
{
 int i;
 struct in6_addr ipv;
 ipv.s6_addr[16]="128.12.343.65.76.89.0.0.0.0.0.12.56.75.44.187.199";
 
 for(i=16;i>=1;i--)
                                                                                                                             
   printf("&#37;u.",ipv.s6_addr[i]);
                                                                                                                             
}

[vart]

This "128.12.343.65.76.89.0.0.0.0.0.12.56.75.44.187.199 " is a string (which is longer then 16 bytes)

this is an array of 16 numbers:

{128,12,343,65,76,89,0,0,0,0,0,12,56,75,44,187,199}

if you want to initialize your struct with such numbers you probably should do something like

struct in6_addr ipv ={{128,12,343,65,76,89,0,0,0,0,0,12,56,75,44,187,199}};

and note that array indexes are from 0 to 15

[dwks]

and note that array indexes are from 0 to 15

. . . in other words, your for loop, which loops from 16 to 1 inclusive, is not correct. [edit] It should go from 0 to 15 inclusive, because you want to look at element 0 first, and so on. [/edit]

Also, %u is for ints -- but %c actually handles unsigned chars. http://man.he.net/man3/printf

c      The  int argument is converted to an unsigned char,
              and the resulting character is written.

[vart]

Also, %u is for ints -- but %c actually handles unsigned chars. http://man.he.net/man3/printf

But when you print Ip you do not want to see something like '\n'.'\n'.nul.nul
You want to see 10.10.0.0 so %c is out of scope here

[dwks]

D'oh! But shouldn't the argument be casted then? I'm not sure what would happen if you passed a one-byte number while printf was expecting a (say) four-byte one . . . .

The value preserving approach calls for promoting those types to signed int, if that type can properly represent all the values of the original type, and otherwise for promoting those types to unsigned int. Thus, if the execution environment represents short as something smaller than int, unsigned short becomes int; otherwise it becomes unsigned int.

The unsigned preserving rules greatly increase the number of situations where unsigned int confronts signed int to yield a questionably signed result, whereas the value preserving rules minimize such confrontations. Thus, the value preserving rules were considered to be safer for the novice, or unwary, programmer. After much discussion, the Committee decided in favor of value preserving rules, despite the fact that the UNIX C compilers had evolved in the direction of unsigned preserving.

I'm assuming that applies to argument promotion as well.

In short, this means that an unsigned char will be promoted to a signed int. Since %u expects an unsigned int, I think that a cast to (unsigned) would be necessary. Or you could just use %i or %d. (They're the same thing.)

[vart]

I do not think promoting unsigned char value to signed int and then printing it as %u will cause any problems on any platform. I think problems could be with signed chars, not unsigned. But I my be wrong on this...

[dwks]

Actually, yes, you're probably right, because every value of an unsigned char can be represented with an int. So much for that idea.

[Elysia]

It may be undefined behavior, but on x86, it works fine since any value pushed on the stack is 4 bytes. So your char becomes an int and can be read just fine from printf. The format specifier just tells it how to interpret the data.
Plus the registers are 4 bytes, unless passed in a 1 or 2-byte register, which is unlikely, so even if passed via registers, it will probably work anyway. Plus I'd believe printf uses a __cdecl type of calling convention, passing all data on the stack and the caller cleaning up.

[vart]

It may be undefined behavior,

No it is not. It is defined behavior stated in the standard

If the expression that denotes the called function has a type that does not include a prototype, the integral promotions are performed on each argument and arguments that have type float are promoted to double.

It has nothing to do with passing parameters on stack or in register