Ansi C: Convertierung int to string

Entwickler schrieb:
> Mikrocontroller

Entwickler schrieb:
> unsigned int

Das wird so nicht funktionieren da dein int warscheinlich
(du hast den Controller nicht genannt) nur 16 Bit breit
sein wird .....

Entwickler schrieb:
> char* cip

Das wird nicht funktionieren da du nur einen Pointer auf
einen String reserviert hast. Der reservierte Speicherbereich
dazu fehlt aber .....

Dergute W. schrieb:
> auf geheimen Microcontrollern

Zumindest scheint der geheime µC ein 32 Bit Typ zu sein, sonst wäre der 
"unsigned int" wahrscheinlich zu klein für den Wert.

Insofern wächst die Wahrscheinlichkeit dass libs zu IP existieren und 
Funktionen wie inet_addr(), inet_aton() und inet_ntoa() schon 
existieren.

Vieleicht mal da schauen:
http://www.gnu.org/software/libc/manual/html_node/Host-Address-Functions.html

Dirk B. schrieb:
> Wenn dir die Schieberei nicht gefällt, mach eine union mit einem
> char-Array und dem unsigned int.

?
Das hätte ich gerne mal ausprogrammiert gesehen.

Der Andere schrieb:
> sonst wäre der
> "unsigned int" wahrscheinlich zu klein für den Wert.

Die warscheinlichere Version ist dass der TO nicht weiss
was er da wirklich tut. Denn er hält es ja auch nicht für
nötig auf den Typ des Controllers hinzuweisen.

Oder etwas übersichtlicher:

unsigned int iip = 0xc0a8010c;
unsigned int ip1;
unsigned int ip2;
unsigned int ip3;
unsigned int ip4;
char         cip [16];

ip4 = iip & 0xff;
iip = iip >> 4;
ip3 = iip & 0xff;
iip = iip >> 4;
ip2 = iip & 0xff;
iip = iip >> 4;
ip1 = iip & 0xff;
sprintf ( cip, "%d.%d.%d.%d", ip1, ip2, ip3, ip4 );

So?

1

#include <stdio.h>

2

#include <stdlib.h>

3

//#include <arpa/inet.h>

4

//#include <netinet/in.h>

5

#include <winsock.h>

6

7

int main(int argc, char *argv[])

8

{ 

9

  union {

10

   unsigned int ip;

11

   unsigned char c[4];

12

  } u;

13

14

  unsigned int ip = 0xc0a8010c;

15

  char cip[16];

16

17

  u.ip = htonl(ip);

18

19

  sprintf(cip, "%d.%d.%d.%d", u.c[0], u.c[1], u.c[2], u.c[3]);

20

  printf("%s\n", cip);

21

22

  system("PAUSE");  

23

  return 0;

24

}

Beim Linken "-lwsock32" nicht vergessen...

Oder eben doch geschoben:

1

#include <stdio.h>

2

#include <stdlib.h>

3

//#include <arpa/inet.h>

4

//#include <netinet/in.h>

5

#include <winsock.h>

6

7

8

int main(int argc, char *argv[])

9

{

10

  unsigned int ip = 0xc0a8010c;

11

  char cip[16];

12

13

  ip = htonl(ip);

14

15

  sprintf(cip, "%d.%d.%d.%d\n", ip & 0xff, (ip >> 8) & 0xff, (ip >> 16) & 0xff, (ip >> 24) & 0xff);

16

  printf("%s\n", cip);

17

18

  system("PAUSE");  

19

  return 0;

20

}

Entwickler schrieb:
> In cip soll dan der string "192.168.1.12" drin stehen

Heute noch IPv6 inkompatibel programmieren ?

Amateur schrieb:
> Oder etwas übersichtlicher:

Kaum.

Tim T. schrieb:
> So?

Eher nicht, die byte-order der int auf char[4] ist maschinenabhängig.

MaWin schrieb:
> Tim T. schrieb:
>> So?
>
> Eher nicht, die byte-order der int auf char[4] ist maschinenabhängig.

Dafür ist htonl doch drin...

Und bevor auch noch am int gemosert wird:

#include <stdint.h>
und
uint32_t ip = 0xc0a8010c;

nehmen

Tim T. schrieb:
> Und bevor auch noch am int gemosert wird:

So lernt der TO nix dazu .....

Frickelfritze schrieb:
> Tim T. schrieb:
>> Und bevor auch noch am int gemosert wird:
>
> So lernt der TO nix dazu .....

Als ob dieses Forum dazu da ist den Leuten zu helfen, pffft.
Hier geht es nur darum an allem rumzumosern, klug zu scheissen, 
Bildformate und Rechtschreibung zu kritisieren, den TO runterzuputzen 
und möglichst weit von einer einfachen Lösung fern zu halten.

Frickelfritze schrieb:
> So lernt der TO nix dazu .....
Manche Aussagen sind so dermaßen abwegig, dass noch nicht einmal das 
Gegenteil richtig ist.

Tim T. schrieb:
> So?
Die Verwendung einer union zur Daten-Konvertierung ist undefined 
behaviour in Ansi C, und je nach Plattform ist die IP-Adresse verdreht! 
(Littie/Big Endian).

Daher ist die Lösung mit Bitshifts besser, weil sie immer funktioniert, 
wie hier:

Mark B. schrieb:
> Zum Beispiel so:

Tim T. schrieb:
> Oder eben doch geschoben:
Das ist falsch so, denn deine Bitshifts funktionieren ohne htonl 
korrekt, mit htonl gehts aber auf manchen Plattformen schief! Richtig 
gewollt aber falsch gemacht :-)

Dr. Sommer schrieb:
> Tim T. schrieb:
>> So?
> Die Verwendung einer union zur Daten-Konvertierung ist undefined
> behaviour in Ansi C, und je nach Plattform ist die IP-Adresse verdreht!
> (Littie/Big Endian).

Nein, das union ist sehrwohl definiert, die daten im int jedoch nicht, 
das wurde durch htonl korrigiert.

>
> Daher ist die Lösung mit Bitshifts besser, weil sie immer funktioniert,
> wie hier:

Öhm, nein.


> Mark B. schrieb:
>> Zum Beispiel so:
>
> Tim T. schrieb:
>> Oder eben doch geschoben:
> Das ist falsch so, denn deine Bitshifts funktionieren ohne htonl
> korrekt, mit htonl gehts aber auf manchen Plattformen schief! Richtig
> gewollt aber falsch gemacht :-)

Und wieder nein.

Tim T. schrieb:
> Öhm, nein.

kannst du das begründen?

> Und wieder nein.
das auch?

Tim T. schrieb:
> Nein, das union ist sehrwohl definiert, die daten im int jedoch nicht,
> das wurde durch htonl korrigiert.
Ah stimmt, das htonl hab ich übersehen. Seltsamer Ansatz aber sollte 
funktionieren.

Tim T. schrieb:
> Öhm, nein.
Öhm, doch. z.B. "(0x12345678 >> 8) & 0xFF" liefert immer 0x56, 
unabhängig von der Byte-Reihenfolge der Plattform. Daher ist ein solcher 
Ansatz dem Umweg über eine union+htonl immer vorzuziehen...

Tim T. schrieb:
> Und wieder nein.
Doch.

Tim T. schrieb:
> ip = htonl(ip);
Verdreht auf Little-Endian Architekturen die Reihenfolge.

>   sprintf(cip, "%d.%d.%d.%d\n", ip & 0xff, (ip >> 8) & 0xff, (ip >> 16)
> & 0xff, (ip >> 24) & 0xff);
Gibt bei gegebenem Inhalt von "ip" immer das gleiche aus unabhängig 
von der Plattform. Da du also am Anfang je nach Plattform 1x verdrehst, 
kommt auf BE/LE Systemen jeweils was anderes heraus.

Hier noch ein Ansatz mit getnameinfo. Dieser funktioniert auf 
POSIX-kompatiblen Systemen. Der Vorteil ist hier, dass der auch trivial 
auf IPv6 umgebaut werden kann (mit sockaddr_in6 statt sockaddr_in). 
getnameinfo kann direkt mit der Adresse aus z.B. accept() oder 
getaddrinfo() genutzt werden, sodass das Programm komplett unabhängig 
von IPv4 vs. IPv6 wird.

1

#include <stdio.h>

2

#include <stddef.h>

3

4

#include <sys/types.h>

5

#include <netdb.h>

6

#include <arpa/inet.h>

7

#include <netinet/ip.h>

8

9

int main (void) {

10

  char hostname [100];

11

  int res;

12

  struct sockaddr_in addr;

13

14

  addr.sin_family = AF_INET;

15

  addr.sin_port = 0;

16

  addr.sin_addr.s_addr = htonl (0xc0a8010c);

17

18

  res = getnameinfo ((struct sockaddr*) &addr, sizeof (addr), hostname, sizeof (hostname), NULL, 0, NI_NUMERICHOST);

19

  if (res == 0) {

20

    printf ("Adresse als String: %s\n", hostname);

21

    return 0;

22

  } else {

23

    printf ("Fehler: %s\n", gai_strerror (res));

24

    return 1;

25

  }

26

}

Dr. Sommer schrieb:
> Tim T. schrieb:
>> So?
> Die Verwendung einer union zur Daten-Konvertierung ist undefined

Er ist in guter Gesellschaft:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms738571(v=vs.85).aspx

1

typedef struct in_addr {

2

  union {

3

    struct {

4

      u_char s_b1,s_b2,s_b3,s_b4;

5

    } S_un_b;

6

    struct {

7

      u_short s_w1,s_w2;

8

    } S_un_w;

9

    u_long S_addr;

10

  } S_un;

11

} IN_ADDR, *PIN_ADDR, FAR *LPIN_ADDR;

Nenn mal ein ABI bei dem das nicht so funktionieren kann (korrekte 
Verwendung von htonl und ntohl natürlich vorausgesetzt).

Bernd schrieb:
> Er ist in guter Gesellschaft:
Du verwendest Microsoft als Referenz bei Fragen zum C-Standard? Wo sich 
Microsoft doch so gut mit Standards zu Programmiersprachen und 
Betriebssystemen auskennt... ;-) Wie z.B. das "FAR" genau da, das sieht 
total nach C-Standard aus. In einer C Standard Library ist eine union 
aber schon besser aufgehoben, da diese onehin plattformspezifisch ist.

Bernd schrieb:
> Nenn mal ein ABI bei dem das nicht so funktionieren kann (korrekte
> Verwendung von htonl und ntohl natürlich vorausgesetzt).
Darum gehts nicht... Ich habe sogar geschrieben dass es funktionieren 
müsste. Dennoch ist es so, dass der C-Standard da einfach sagt 
"undefined". Im C-Standard steht auch nichts von ntohl. Eine 
Undefiniertheit in der Programmiersprache mit einer 
Betriebssystem-Funktion auszubügeln ist unschön. Bitshifts sind die 
bevorzugte, einfache, sichere, wohldefinierte Methode. Ich verstehe 
nicht, warum sich da alle gegen wehren?
Mark Brandis hat eine einfache, korrekte, standard-konforme, immer 
funktionierende Lösung gepostet. Diese ist den anderen Frickelein, die 
"funktionieren müssten", zu bevorzugen...

Dr. Sommer schrieb:
> Wie z.B. das "FAR" genau da, das sieht total nach C-Standard aus.

Was hat denn der C-Standard gegen Preprozessor Makros?

guest schrieb:
> Was hat denn der C-Standard gegen Preprozessor Makros?
Windowsspezifische Makros für far/near pointer Unterscheidung sind nicht 
gerade portabel. Ist zum Glück nur ein Relikt ohne Bedeutung.

Dr. Sommer schrieb:
> guest schrieb:
>> Was hat denn der C-Standard gegen Preprozessor Makros?
> Windowsspezifische Makros für far/near pointer Unterscheidung sind nicht
> gerade portabel. Ist zum Glück nur ein Relikt ohne Bedeutung.

far/near Pointer sind sowieso Platform-/Compilerspezifisch. Von daher 
wird das durch die Makros noch eher portabel als ohne.
Außerdem ist der Rest drum rum auch nicht portabel, nennt sich ja nicht 
Umsonst Platform SDK bzw. Windows SDK.

Das mit dem Relikt ist natürlich richtig.