# excess elements in scalar initializer



## firefighter1993 (17. Oktober 2013)

Hallo Leite, 
ich habe ein kleines Problem. Und zwar soll bei einem Gerät welches in C Programmiert wurde die Chinesische Sprache hinzu gefügt werden. Um dies zu bewerkstelligen muss ich die einzelnen Buchstaben in HEX Code umwandeln. Hier das ergebnis:


```
const char * const txt_kein_therapiemodul_gefunden[] = {
"Kein Therapiemodul gefunden!",
"Therapy module not found!",
"¡Ningún módulo de terapia encontrado!",
"Apparecchiatura non connessa!",
"Geen therapiemoduul gevonden!",
{ 0x672A, 0x53D1, 0x73B0, 0x6CBB, 0x7597, 0x6A21, 0x5757, 0x21 },
};
```

Leider bekomme ich beim kompalieren mit Cygwin immer folgenden Fehler:

_excess elements in scalar initializer
(near initialization for ‘txt_kein_therapiemodul_gefunden[5]’)
_

Habt ihr einen Tipp für mich? Eigentlich müsste "{ 0x672A, 0x53D1, 0x73B0, 0x6CBB, 0x7597, 0x6A21, 0x5757, 0x21 }" Anstatt des Chinesischen Textes funktionieren oder etwa nicht?

Gruß
firefighter1993


----------



## Caligulaminus (17. Oktober 2013)

Dein char wird aller Wahrscheinlichkeit nach acht Bit breit sein. Wie sollen da 16-Bit-Werte wie 0x53D1 reinpassen?


----------



## firefighter1993 (17. Oktober 2013)

das ist nen Argument .. Char ist normalerweise bei ascii nur 8bit breit
aber wie kann ich es auf 16 bit erweitern?
Sobald ich Chinesiche zeichen habe brauch ich immer 16 bit, wenn ich gemischt mit Lateinischen und Chinesischen Zeichen arbeiten will


----------



## Caligulaminus (17. Oktober 2013)

Das kommt ganz auf das betreffende System an. Pauschal läßt sich da nix sagen.


----------



## firefighter1993 (17. Oktober 2013)

µController
ARM CPU
LH75411-N0 Q100 C0 von Sharp

Entwicklungsumgebung:
Cygwin mit:
GNU Make
GCC
GNU Binutils
GNU Bash
Netpbm
Iamgemagick

  Compiler  (arm-elf):         	GCC 4.1.1
  Binutils  (arm-elf):         	        GNU Binutils 2.16.1 *)
  C-Library (arm-elf):         	Newlib 2.14.0
  Compiler  (msp430):          	GCC 3.2.3
  Binutils  (msp430):          	GNU Binutils 041101 20041101

Hoffe, das reicht an Daten 
In einem anderen Projekt wird xChar verwendet, hab aber nicht im Internet darüber gefunden


Ich glaube ich brauche einen UTF-16 Char, kann das sein?


----------



## Caligulaminus (17. Oktober 2013)

Mit ARM/Newlib kenne ich mich überhaupt nicht aus. Aber wenn die das wie unter Linux machen sollte UTF-8 das Zauberwort sein. Dann bleibt es auch bei acht-Bit-char.


----------



## Caligulaminus (17. Oktober 2013)

Probier doch mal

0xEF, 0xBB, 0xBF, 0xE6, 0x9C, 0xAA, 0xE5, 0x8F, 0x91, 0xE7, 0x8E, 0xB0, 0xE6, 0xB2, 0xBB, 0xE7, 0x96, 0x97, 0xE6, 0xA8, 0xA1, 0xE5, 0x9D, 0x97, 0x21

u.U. die ersten drei weglassen (BOM)


----------



## firefighter1993 (17. Oktober 2013)

Das wären dann die normalen Chars als Hex, oder?


----------



## Caligulaminus (17. Oktober 2013)

Jupp.



Der eingegebene Text ist zu kurz. Bitte erweitere den Text auf die minimale Länge von 10 Zeichen.


----------



## firefighter1993 (17. Oktober 2013)

{ 0xE6, 0x9C, 0xAA, 0xE5, 0x8F, 0x91, 0xE7, 0x8E, 0xB0, 0xE6, 0xB2, 0xBB, 0xE7, 0x96, 0x97, 0xE6, 0xA8, 0xA1, 0xE5, 0x9D, 0x97, 0x21} Eingefügt..

nun folgende Fehler (vielleicht hab ich die auch vorher einfach übersehen)
warning:  type defaults to ‘int’ in declaration of ‘txt_rechteck_1hz’
warning:  initialization from incompatible pointer type
warning:  braces around scalar initializer
warning:  (near initialization for ‘txt_rechteck_1hz[5]’)


----------



## Caligulaminus (17. Oktober 2013)

"\xEF\xBB\xBF\xE6\x9C\xAA\xE5\x8F\x91\xE7\x8E\xB0\xE6\xB2\xBB\xE7\x96\x97\xE6\xA8\xA1\xE5\x9D\x97\x21"

Ich mach' sowas so selten...

Wieder u.U. ohne BOM.


----------



## firefighter1993 (17. Oktober 2013)

eigentlich ist komma getrennt schon richtig meine ich ..
bei ner anderen software funktioniert es mit folgendem aufruf:

const xchar txt_kabel_fehlt[] = { 0x4E22, 0x5931, 0x7535, 0x7EBF, 0x0000 };


mit xchar hab ichs auch schon versucht 

ist vom prinzip her ja bei beiden das gleiche, nur, dass das eine ein String array ist wo mehrere Sprachen in einem sind.
Bei dem anderen sieht die normale Sprache wie deutsch oder englisch volgender maßen aus:


const xchar txt_hauptmenue[] = "Seminarversion";


----------



## firefighter1993 (17. Oktober 2013)

habe nun mit deinem aufruf folgende Fehlermeldung:

texts.c:2396: warning: type defaults to ‘int’ in declaration of ‘txt_modul_auswaehlen’
texts.c:2397: warning: initialization from incompatible pointer type
texts.c:2398: warning: initialization from incompatible pointer type
texts.c:2399: warning: initialization from incompatible pointer type
texts.c:2400: warning: initialization from incompatible pointer type


----------



## Caligulaminus (17. Oktober 2013)

Caligulaminus hat gesagt.:


> ```
> "\xEF\xBB\xBF\xE6\x9C\xAA\xE5\x8F\x91\xE7\x8E\xB0\xE6\xB2\xBB\xE7\x96\x97\xE6\xA8\xA1\xE5\x9D\x97\x21"
> ```



Funktioniert bei mir.


----------



## Cromon (17. Oktober 2013)

Caligulaminus hat gesagt.:


> Das kommt ganz auf das betreffende System an. Pauschal läßt sich da nix sagen.



Jein. Der Standard schreibt vor, dass char 1 Byte ist, 1 Byte muss jedoch nicht immer 8 Bit sein.


----------



## Caligulaminus (17. Oktober 2013)

Cromon hat gesagt.:


> Jein. Der Standard schreibt vor, dass char 1 Byte ist, 1 Byte muss jedoch nicht immer 8 Bit sein.



Ich kann keinen Zusammenhang zwischen deinem Einwand und dem von dir zitierten Satz erkennen.


----------



## Cromon (17. Oktober 2013)

Aus dem Kontext und der Tatsache, dass noch immer viele Leute das Gefühl haben sizeof(char) sei theoretisch irgendwo nicht 1 ging ich davon aus, dass du dich auf das beziehst:



firefighter1993 hat gesagt.:


> Char ist normalerweise bei ascii nur 8bit breit


----------



## Caligulaminus (17. Oktober 2013)

Ich bezog mich zwar auf den zweiten Satz(Was aus dem weiteren Verlauf des Threads m.E. ersichtlich ist.). Aber selbst in Bezug auf "Char ist normalerweise [..] 8bit breit." Sollte meine Replik "Das kommt ganz auf das betreffende System an. Pauschal läßt sich da nix sagen." doch ganz in deinem Sinne (1 Byte muss nicht immer 8 Bit sein.) sein, oder verstehe ich dich falsch?


----------



## Cromon (17. Oktober 2013)

Ich gehe davon aus du hast die Intention meines Postings falsch aufgefasst. Es ging nicht darum die Richtigkeit deines Postings einzuschätzen. Das "Ja" in "Jein" bezieht daher auch auf den Inhalt deiner Aussage und das "Nein" auf die hypothetische Schlussfolgerung eines möglichen Lesers der Art "Wenn Char nicht immer 8 Bits ist muss ich unbedingt immer sizeof(char) verwenden!".


----------



## Caligulaminus (17. Oktober 2013)

Also das 'Ja' bezieht sich auf meine Aussage, und das 'Nein' auf deine eigene - zumal unausgesprochene - Hypothese. Das ganze unter einem Zitat meiner Worte.
Ich finde das hochgradig verwirrend.

Naja, jetzt weiß ich's. Von mir aus genug OT.


----------



## deepthroat (18. Oktober 2013)

firefighter1993 hat gesagt.:


> habe nun mit deinem aufruf folgende Fehlermeldung:
> 
> texts.c:2396: warning: type defaults to ‘int’ in declaration of ‘txt_modul_auswaehlen’
> texts.c:2397: warning: initialization from incompatible pointer type
> ...


Zeig bitte immer den Code dazu. Es ist mühselig raten zu müssen was du nun geschrieben haben könntest...

Scheinbar hast du keinen Typ bei der Deklaration von "txt_modul_auswaehlen" angegeben. Schreib also "const char*" davor.


----------



## firefighter1993 (21. Oktober 2013)

deepthroat hat gesagt.:


> Zeig bitte immer den Code dazu. Es ist mühselig raten zu müssen was du nun geschrieben haben könntest...
> 
> Scheinbar hast du keinen Typ bei der Deklaration von "txt_modul_auswaehlen" angegeben. Schreib also "const char*" davor.



Ja, genau das war dasd Problem :/ das habe ich aber erst Kurz vor Feierabend festgestellt und am Wochenende Leider keine Zeit gehabt zu Antworten bzw. in das Forum zu schauen. Danke für die Hilfe soweit!

Bis auf die Warnung, dass die Hex werte zu groß sind, funktionert der Quelltext. Wenn ich jedoch die Fonts auf 16Bit umstelle, damit ich die Chinesischen Zeichen mit rein bekomme, bekomme ich folgende Fehlermelungen:


```
/usr/local/arm-elf/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ld: region flashp is full (bedien.elf section .textp)
/usr/local/arm-elf/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ld: section .textw [40400000 -> 408d1647] overlaps section .textp [40020000 -> 410b39af]
/usr/local/arm-elf/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ld: section .dataw [408d1648 -> 408e3647] overlaps section .textp [40020000 -> 410b39af]
/usr/local/arm-elf/bin/../lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ld: bedien.elf: section .textw lma 0x40400000 overlaps previous sections
```

Welche Meines erachtens mit Folgendem Abschnitt der bedien.map zu tun haben:

```
Memory Configuration

Name             Origin             Length             Attributes
tcm_ram          0x00000000         0x00004000
flash0           0x40000000         0x00020000
flashp           0x40020000         0x003e0000
flashw           0x40400000         0x00800000
flashu           0x40c00000         0x00400000
sramp            0x44000000         0x000e0000
sramw            0x440e0000         0x00020000
dac              0x48000000         0x00000002
iram             0x60000000         0x00004000
*default*        0x00000000         0xffffffff
```

Nur wie kann ic die Memory Configuration ändern? Ich habe in meiner makefile keinen direkten zusammenhang gefunden, welche die Größe der einzelnen dateien beschreibt und somit die Memory Configuration...

Gruß
firefighter

EDIT:
Wenn ich mich nicht Irre, dann bedeutet das so viel wie: Der µController Flash Speicher ist VOLL! .. kann das sein?


----------

