In C einen String aus Zahlen und Text zusammenbasteln

[Micheel (Gast)]

eigentlich hätte ich erwartet, dass sowas in C geht:

uint8_t x[] = { 0xC3,"Blafasel" };

Sieht auf den ersten Blick richtig aus, funktioniert aber leider nicht.

Ich wollte in dem Fall einen String erzeugen, der ein 
"unaussprechliches" Zeichen enthält.
Den praktischen uneleganten "Workaround" hab ich natürlich, bin aber 
trotzdem mal neugierieg ob es auch eine elegante Lösung gibt, die der 
oben angegebenen Schreibweise ähnelt...

[(prx) A. K. (prx)]

Micheel schrieb:
> trotzdem mal neugierieg ob es auch eine elegante Lösung gibt, die der
> oben angegebenen Schreibweise ähnelt...

"\xC3" "Balafasel"

[Rufus Τ. F. (rufus)]

"\0303Blafasel"

[Yalu X. (yalu) (Moderator)]

Die erste 0 ist zuviel. So wird der String wie

"\030" "3Blafasel"

interpretiert.

[Micheel (Gast)]

Vielen Dank für die Antworten!

Hab inzwischen probiert, die Lösung

uint8_t x[] = "\xC3Blafasel"

macht auf jeden Fall dass wass sie soll. Wieder was dazugelernt. Ich 
hatte bisher immer im Hinterkopf dass der Backslash das folgende Zeichen 
maskiert, war mir aber nicht bewusst dass der auch eine komplette Zahl 
aus der normalen Behandlung als String rausnimmt.

Ist der Default dabei tatsächlich oktal? Muss ich mal googeln...

[Falk B. (falk)]

@ Micheel (Gast)

>Hab inzwischen probiert, die Lösung

>uint8_t x[] = "\xC3Blafasel"

FALSCH! Die Zahl wird als C3B interpretiert! Eben um das zu verhindern, 
muss man das mit Gänsefüsschen trennen!

"\xC3" "Balafasel"

Man kann es nur zusammen schreiben, wenn KEIN Zeichen 0-9, a-f und A-F 
folgt!

[(prx) A. K. (prx)]

Micheel schrieb:
> Ist der Default dabei tatsächlich oktal?

Definitiv. Die PDP-11 lässt grüssen. Hex kam erst später.

[Micheel (Gast)]

womöglich hast Du in der Theorie recht - mein AVR-GCC macht allerdings 
damit genau was ich wollte, fügt also ein Byte mit dem Wert 0xC3 am 
Anfang des String ein.
Womöglich ist das ein Detail bei dem verschiedene C Systeme sich 
unterschiedlich verhalten?

[(prx) A. K. (prx)]

C99 ist eindeutig. Hex werden solange Zeichen eingesammelt, bis es nicht 
mehr passt. Oktal ist nach dem dritten Schluss.

octal-escape-sequence:
  \ octal-digit
  \ octal-digit octal-digit
  \ octal-digit octal-digit octal-digit

hexadecimal-escape-sequence:
  \x hexadecimal-digit
  hexadecimal-escape-sequence hexadecimal-digit

[(prx) A. K. (prx)]

Micheel schrieb:
> womöglich hast Du in der Theorie recht - mein AVR-GCC macht allerdings
> damit genau was ich wollte, fügt also ein Byte mit dem Wert 0xC3 am
> Anfang des String ein.

Ich erlaube mir, da Zweifel anzumelden. Aus
  char a[] = "\xc3b@";
produziert gcc 4.7.2 neben einer Warnung
  .string  ";@"

[Micheel (Gast)]

@A.K.: sorry, ich meinte Falk mit meinem Kommentar "womöglich hast Du in 
der Theorie recht", Antworten haben sich überkreuzt.

Praktisch ist das Problem gelöst - und ich hab mir paar zusätzliche 
Krakel-Notizen in mein Lieblings-C-Buch gemacht ;)

[(prx) A. K. (prx)]

Falk liegt auch in der Praxis richtig. Das passt bei dir vermutlich 
bloss deshalb, weil dein Blafasel nicht mit B anfängt.

[Micheel (Gast)]

Ja, konkret fing der folgende String mit einem K an, das nicht in den 
Wertebereich Hexadezimaler Zahlen fällt.
So gesehen hatte ich im Einzelfall Schwein gehabt. Muss dann wohl die 
Krakeleien in meinem C Buch noch mal ausradieren und neu schreiben ;)

Auf jeden Fall Danke für die hilfreichen Kommentare!