Problem mit String

[jens (Gast)]

Hey

Ich glaub ich sitz grad total auf der Leitung. Hab in der eingefügten 
Schleife nur ein paar Comments hinzugefügt und auf einmal funktioniert 
sie nicht mehr. Anscheinend ist irgendwas schief gelaufen, aber ich find 
den Fehler einfach nicht.

Folgendes Problem: Mein char- Feld bekommt die ersten acht Werte 
korrekt. Dann sollte das Feld eigentlich zu Ende sein, aber irgendwie 
werden noch drei Nullen dazugefügt, auf insgesamt 11 Stellen.

Das Tolle dabei ist ja, dass genau diese Schleife nur mit anderen 
Variablennamen vorher im Programm verwendet wird-und auch funktioniert.
Ich hoffe ihr könnt mir helfen.

jens

[Klaus W. (mfgkw)]

- ind ist nicht initialisiert
- es gibt gar keine Kommentare
- der Quelltext ist nicht vollständig
- es wäre nett, den Quelltext in

[c]
  ...
[/c]

  formatiert einzufügen

[der (Gast)]

ind ist nicht initialisiert! dh es steht irgendein wert drin! schreib 
mal  int ind = 0;

[Klaus W. (mfgkw)]

und dann noch:
i<(ind+8), l<8 soll wohl i<(ind+8) && l<8 heißen?

[Klaus W. (mfgkw)]

PS: aber daran liegt es nicht, weil das hier egal ist; i und l werden ja 
gleichzeitig hochgezählt.

[jens (Gast)]

Nein, Missverständnis.
ind wird vorher schon verwendet.
Zur Erklärung: Ich habe ein Feld von 128 Elementen und ind bestimmt den 
Index in diesem Feld. Dieses große Feld wird nun in kleinere Felder 
aufgeteilt.

Also der Vollständigkeit halber:

void test()
{
int i, l;
int ind;
unsigned char simData[8];
ind = 100;                //Globale Variable

for(i = ind, l = 0; i<(ind+8), l<8; l++, i++)
{
  if(signal[i] == 0)
  {
    simData[l] = '0';
  }
  else
  {
    simData[l] = '1';
  }
}
}

Es muss was anderes sein.

jens

[jens (Gast)]

Klaus Wachtler schrieb:
> i<(ind+8), l<8 soll wohl i<(ind+8) && l<8 heißen?
Im Normalfall schon. Aber es funktioniert ja zweimal tadellos und erst 
beim dritten kleinen Feld passt was nicht.

jens

[jens (Gast)]

Kann der Grund sein, dass ind beim dritten Mal schon über die 128 
Feldelemente ist und deswegen der Fehler auftritt?

jens

[Klaus W. (mfgkw)]

Kann es sein, daß du sein simData danach als String verwendest?
Dann fehlt die abschließende 0.

Das kann man aber so wieder nicht sehen, weil der Quelltext
wieder nicht vollständig ist :-((
Glaubst du, hier wohnen die Hellseher?

[der (Gast)]

Steht deine Funktion so im Programm?
Dann kann das nicht gehen weil "ind" dann eine lokale Variable in der 
Funktion ist! Wenn du außerhalb der Funktion "Test()" eine Variable hast 
die auch "ind" heißt hat die nicht das geringste mit der in der Funktion 
zu tun ;)

[jens (Gast)]

jens schrieb:
> Kann der Grund sein, dass ind beim dritten Mal schon über die 128
> Feldelemente ist und deswegen der Fehler auftritt?
Nein, grade probiert. Ist nicht der Fehler.

jens

[der (Gast)]

der schrieb:
> Steht deine Funktion so im Programm?
> Dann kann das nicht gehen weil "ind" dann eine lokale Variable in der
> Funktion ist! Wenn du außerhalb der Funktion "Test()" eine Variable hast
> die auch "ind" heißt hat die nicht das geringste mit der in der Funktion
> zu tun ;)

hab was übersehen, sorry passt schon so ;)

[Klaus W. (mfgkw)]

jens schrieb:
> Kann der Grund sein, dass ind beim dritten Mal schon über die 128
> Feldelemente ist und deswegen der Fehler auftritt?
>
> jens

Bei welchem dritten Mal?
Kann ich nicht sehen...

[Klaus W. (mfgkw)]

Und welche 128 Feldelemente?
Redest du über das Programm, das du hier zeigst?

[jens (Gast)]

Klaus Wachtler schrieb:
> Und welche 128 Feldelemente?
> Redest du über das Programm, das du hier zeigst?
Das Problem ist, dass das Programm in der VirtualBox programmiert wird 
und ich zurzeit den Quelltext nicht hierherkopieren kann. Sorry dafür.

Also nochmal zur Erklärung:
Eine Funktion analyze() enthält drei der oben gezeigten Schleifen, die 
ein char- Feld (global, 128 Elemente) in drei kleine Felder (lokal, 8 
Elemente) aufteilen.

Die Schleife ist kopiert, also genau dreimal gleich, bis eben auf die 
Variablennamen. Zusätzlich wird natürlich auch immer der Index vom 
Hauptfeld erhöht.

Eine dieser Schleifen wurde in der Funktion test dargestellt, hier im 
Post, damit ein wenig Vollständigkeit herrscht und nicht die 
Codesegmente herumfliegen.

Weitere Eingrenzung des Fehlers:

i<(ind+7), l<7

funktioniert einwandfrei, nur eben mit sieben Elementen.

[Klaus W. (mfgkw)]

Dann such deinen Fehler selbst.
In einem Programm, das ich nicht sehe, kann ich keine
Fehler finden, dafür bin ich zu doof. Frag Rüttgers, der kann alles.

Meine stille Vermutung ist immer noch, daß du die Terminierung
vergisst, aber das ist Spekulation - wie alles hier, solange kein 
Programm auf dem Tisch liegt.

Gute Nacht!

jens schrieb:
> ... damit ein wenig Vollständigkeit herrscht und nicht die
> Codesegmente herumfliegen.

haha

[jens (Gast)]

Danke.
Der Grund, warum ich überhaupt ohne Code angefragt habe, ist, dass ich 
gedacht habe, es ist ein kleiner allgemeiner Fehler. Wenn du zB hörst, 
es werden drei Nullen zum String hinzugefügt, dachte ich mir, vielleicht 
ist das ein Zeichen für einen bestimmten Fehler, der dir bekannt ist.

Ich habe auch keine genauen Lösungen gefordert, sondern Vorschläge, was 
falsch sein könnte. Und deinem mit der Terminierung werd ich nachgehen.

Das nicht der ganze Code verfügbar ist, dafür hab ich mich entschuldigt, 
es geht im Moment einfach nicht. Aber man wird ja wohl noch fragen 
dürfen.

jens

[Klaus W. (mfgkw)]

ja, und die einzige Vermutung, die ich abgeben kann, ist
die, daß du das char-Feld anschließend als String nimmst, obwohl
evtl. die abschließende Null fehlt.
Das ist schon Spekulation, aber halt ein typischer Standardfehler.
Mehr kann ich dazu nicht sagen. Alles weitere wäre nicht
Spekulation, sondern wilde Spekulation.
Wenn dein Word abstürzt, kann ich dir auch nicht sagen, in
welcher Quelltextzeile das ist.

[möööp (Gast)]

wobei diese zeile :

for(i = ind, l = 0; i<(ind+8), l<8; l++, i++)

mal irgendwie eine vergewaltigung ist ^^

ein

unsigned char l = 0;
for(i = ind ; i<(ind+8); i++)
{
  if(signal[i] == 0)
  {
    simData[l++] = '0';
  }
  else
  {
    simData[l++] = '1';
  }
}

tuts doch auch oder verwechlse ich grad was ?

[jens (Gast)]

möööp schrieb:
> tuts doch auch oder verwechlse ich grad was ?
Nein, so ging´s auch.

jens

[Stefan E. (sternst)]

Ich würde es mit nur einer Schleifenvariablen machen:

for (uint8_t i = 0; i < 8; i++)
{
  if(signal[ind+i] == 0)
  {
    simData[i] = '0';
  }
  else
  {
    simData[i] = '1';
  }
}

[Klaus W. (mfgkw)]

möööp schrieb:
> tuts doch auch oder verwechlse ich grad was ?

ja, das tut's auch.
Ich finde es aber nicht elegant, weil man die Funktionalität
der Schleife nicht mehr kopmpakt im for hat, sondern mehr oder
weniger mühsam suchen muß.
Ok, das Suchen ist hier nicht schwer, aber zumindest bei etwas
aufwendigeren Konstruktionen mag ich so versteckte ++ nicht recht.

Stefan Ernst schrieb:
> Ich würde es mit nur einer Schleifenvariablen machen:

Das ist sicher die bessere Variante.

[Klaus W. (mfgkw)]

Was aber nach wie vor krank ist (und nur eher zufällig nicht
stört) ist die Bedingung:
... i<(ind+8), l<8;...
Das i<(ind+8) wird nicht geprüft bzw. bewirkt nichts!

[möööp (Gast)]

Klaus Wachtler schrieb:
> ja, das tut's auch.
> Ich finde es aber nicht elegant, weil man die Funktionalität
> der Schleife nicht mehr kopmpakt im for hat, sondern mehr oder
> weniger mühsam suchen muß.
> Ok, das Suchen ist hier nicht schwer, aber zumindest bei etwas
> aufwendigeren Konstruktionen mag ich so versteckte ++ nicht recht.


naja stimmt schon
aber das for konstrukt sieht so

for(i = ind, l = 0; i<(ind+8), l<8; l++, i++)

unübersichtlicher aus
finde ICH jedenfalls

wobei mir

for (uint8_t i = 0; i < 8; i++)
{
  if(signal[ind+i] == 0)
  {
    simData[i] = '0';
  }
  else
  {
    simData[i] = '1';
  }
}

besser gefällt
ich bin noch nicht so lange am programmieren
ein anderer würde vlt noch anders lösen ^^


aber gerade die verrückten sachen machen in C spass :)
siehe funktionszeiger und so ..

[möööp (Gast)]

jens schrieb:
> Weitere Eingrenzung des Fehlers:i<(ind+7), l<7
> funktioniert einwandfrei, nur eben mit sieben Elementen.

und unsigned char simData[8];
macht mich stutzig

die abbruchbedingen scheint nicht zustimmen und er schreibt vieleicht
in simData[8] was rein .. was leider nicht geht .. da es nur ein array 
mit 8 elementen ist 0 .. 7

aus diesem grunde verteufle ich das verschachtelte for konstukt ^^
und würde die variante von Stefan Ernst bevorzugen

 ^^

[jens (Gast)]

So, nun habe ich endlich den Quelltext aus der VirtualBox bekommen.
Hab gestern noch ein wenig herumprobiert, jetzt habe ich beim 
addressByte das gleiche Problem wie beim simData, es werden zum String 
drei Nullen dazugehängt.
adData funktioniert dagegen einwandfrei.
Hinweis:
Es ist nicht sehr schön programmiert, das kommt erst. Also bitte keine 
Einwürfe diesbezüglich. Bin im Moment nur an der schnellen Lösung des 
String- Problems interessiert.

jens

[Klaus (Gast)]

Und wie dir nun schon mehrmals gesagt wurde, musst du an einen String 
auch ein abschließendes 0-Zeichen anhängen!!!

[Klaus W. (mfgkw)]

Woher kommt eigentlich die Unsitte, Quelltexte als *.txt hoch zu laden?

(Bis man sie mit Syntaxhighlighting zu sehen bekommt, muß man sie
erst unter einem anderen Namen abspeichern und dann öffnen.)

[Klaus W. (mfgkw)]

Im Kommentar steht: "Die Variable ind ist ebenfalls global."
Das kann ich so nicht unterschreiben...

[Klaus W. (mfgkw)]

jens schrieb:
> Bin im Moment nur an der schnellen Lösung des
> String- Problems interessiert.

Dann mach das doch mal endlich! :-)
Seit einem Tag läufst du hier ohne Terminierung rum und wunderst dich.

mfg, der andere Klaus

[Klaus W. (mfgkw)]

PS: dazu muß das Feld natürlich auch groß genug sein;
8 Elemente reichen nicht für 8 Zeichen plus Terminierung.

[jens (Gast)]

Klaus Wachtler schrieb:
> Seit einem Tag läufst du hier ohne Terminierung rum und wunderst dich.
Ich habs ja schon mal probiert mit neun Elementen und '\0'. Aber es hat 
trotzdem nicht funktioniert.
Das komische ist ja, das adDataByte auch ohne die vermeintliche 
Terminierung geht. Warum soll das dann auf einmal nicht mehr gehen?

Hab das Problem aber schon gelöst. Einfach für adDataByte und 
simDataByte nur ein Feld dataByte genommen und jetzt funktionierts.
Danke für die Hilfe.

jens

[Klaus W. (mfgkw)]

jens schrieb:
> Das komische ist ja, das adDataByte auch ohne die vermeintliche
> Terminierung geht. Warum soll das dann auf einmal nicht mehr gehen?

Das ist einfach Glückssache:
Wenn vorher in dem Byte zufällig eine Null steht (durch vorige
Verwendung oder $(MYGOOD)es FÜgung), dann klappt es.
Ansonsten geht der String scheinar soweit, bis irgendwo dahinter
im Speicher eine 0 steht.

[Klaus W. (mfgkw)]

Ach ja: es gibt auch Bücher über die Grundlagen von C.

[Karl H. (kbuchegg)]

jens schrieb:
> Klaus Wachtler schrieb:
>> Seit einem Tag läufst du hier ohne Terminierung rum und wunderst dich.
> Ich habs ja schon mal probiert mit neun Elementen und '\0'.

Das Problem ist, das du 'probierst'.

Wenn du ein Problem siehst, dann behebe es. Aber tu das, in dem du das 
Problem analysierst, dein Wissen einsetzt, und es behebst.

Aber hör auf zu 'probieren'.

> Aber es hat
> trotzdem nicht funktioniert.

Dann wartet mglw. schon der nächste Fehler in den Startlöchern?

> Hab das Problem aber schon gelöst. Einfach für adDataByte und
> simDataByte nur ein Feld dataByte genommen und jetzt funktionierts.

Fehler kaschieren ist keine Problemlösung.

Lies wenigstens die Minimalversion dessen, was du eigentlich über 
Strings aus deinen Büchern wissen solltest.
http://www.mikrocontroller.net/articles/FAQ#Wie_funktioniert_String-Verarbeitung_in_C.3F