for(i=0;i<256;i++) funktioniert nicht!

Ja.

i ist ein unsigned char (nicht unsinged char, vermute ich)
und kann als solches Werte von 0 bis 255 annehmen.
Hat es bereits den Wert 255 und man erhöht es nochmals
wird es wieder 0.

Damit ist i<256 immer erfüllt.

Fabian schrieb:
> Zum Glück macht er das nicht. Ich will immernoch durch mein Programm
> bestimmen, was es zu tun hat und nicht der Compiler.
>
> Davon abgesehen ist unsigned char als [0..255] und nicht als [0; 255]
> definiert. (Wobei ich mir grad nicht sicher bin, ob ein char
> grundsätlich 8 Bit hat oder ob es bei anderen Sprachen/Systemen auch
> noch unterschiede gibt.
Ja, auf manchen System hat ein char nur 7 Bits.

Gruß,
Bernd

Hallo,

Mmmh schrieb:
> danny schrieb:
>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
>> CP   Rxy, 0xFF
>> BREQ adr
>> erstellt!
>>Macht er also nicht...
>
> Seufz!

Er macht, was Du ihm sagst...

Bestenfalls wäre es also CPI Rxy, 256 und das ginge schlecht.
Springen müßter er mit BRLO, Du hast ja nicht

for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges 
Konstrukt ergeben können.

Ein Computer macht nicht immer das, was er soll.
Er macht aber IMMER, was man ihm sagt.

Gruß aus Berlin
Michael

Stefan Salewski schrieb:
>>for(i=0;i<256;i++)
>> dooo();
>
> Ich hätte eh
>
> for(i=0;i<=255;i++)
>
> geschrieben -- 256 passt ja nicht mehr in ein Byte.

Dir ist aber schon klar, dass das genau so wenig funktioniert? Die 
Bedingung ist auch immer wahr.

eklige Tunke schrieb:
> Michael U. schrieb:
>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>> Konstrukt ergeben können.
> Bevor er das ausprobiert, kleine Korrektur:
> for (i=0; i == 255; i++)
> ;-)  <-- das ist ein Smiley, kein Code!

Aber das macht doch auch keinen Sinn, die Schleife würde nie ausgeführt 
werden, da bereits 0 != 255 ist.

Bernd O. schrieb:
> Ja, auf manchen System hat ein char nur 7 Bits.

Das wäre allerdings nicht C-Standard-konform.  Ein char muss
mindestens 8 bits haben, um eine konforme Implementierung zu
erreichen.

Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
definiert).

danny schrieb:
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, [...]

Die Intelligenz des Compilers besteht darin, dass er dir bei
eingeschalteten Warnungen (-Wall -Wextra ist immer eine gute Idee)
sagt, dass du da soeben eine Endlosschleife von ihm verlangt hast
("comparison is always true due to limited range of operands" oder
sowas).

eklige Tunke schrieb:
> Michael U. schrieb:
>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>> Konstrukt ergeben können.
> Bevor er das ausprobiert, kleine Korrektur:
> for (i=0; i == 255; i++)

Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm 
bestimmt weiter. ;-)

Ich behaupte ja, man kann keine Schleife mit 256 Durchgängen machen, 
wenn man nur von 0 bis 255 zählen kann.

Du täuschst dich, denn du hast 257 Zustände. 256 mal "innerhalb" der 
Schleife und einen Zustand, der symbolisiert, dass die Schleife zu ende 
ist.

Hallo,

Stefan Ernst schrieb:
> eklige Tunke schrieb:
>> Michael U. schrieb:
>>> for (i=0; i = 255; i++) bei ihm bestellt, das würde Dein obiges
>>> Konstrukt ergeben können.
>> Bevor er das ausprobiert, kleine Korrektur:
>> for (i=0; i == 255; i++)
>
> Jap, aus der Immer-Schleife eine Niemals-Schleife zu machen, hilft ihm
> bestimmt weiter. ;-)

von meinem Tipfehler abgesehen: ich habe nicht gesagt, daß es in seinem 
Sinn funktioniert, ich habe nur gesagt, das könnte besagten ASM-Code 
erzeugen:
>> CP   Rxy, 0xFF
>> BREQ adr

;-))

Gruß aus Berlin
Michael

Stefan Salewski schrieb:
> i=0;
> while (i++ != 0) {}

das wird nie ausgeführt.
Du meinst vielleicht ++i statt i++?

yalu schrieb:

> Das ist zwar nicht klinisch sauber, da der Additionsüberlauf genutzt
> wird, aber auf Mikrocontrollern erlaubt :)

Da du ein uint8_t benutzt hast, ist das sogar "klinisch sauber".
Der Überlauf einer vorzeichenlosen Zahl nach 0 ist definiert, und
bei einem uint8_t ist auch klar, dass der Typ genau 8 bits breit
ist.

Ok, zusammen mit dem Überlaufbit hat man natürlich 9 Bits :-)

Wusste nicht, wie man das gescheit in der Schleife nutzen kann. Danke 
yalu!

Flo schrieb:
> es geht nicht mit nur einer Abfrage (egal ob do while, while oder for)
> mit einem(!) 8 bit Zähler (256 Möglichkeiten) eine Schleife mit 256
> Durchläufen zu bauen.
> Denn bei welchem Wert des Zählers soll er aufhören? 256 gibts nicht und
> alles andere wird schon vor dem 256. Durchlauf durchlaufen (was ein
> Wortspiel).
>
> Viel Spaß beim Suchen der Möglichkeiten :-)

Siehe ein Beitrag über deinem. Das Überlaufbit fungiert als 9. Bit.

Rolf Magnus schrieb:
> Das Überlaufbit hat damit nichts zu tun. Man benutzt auch keine 9 Bits.

Entweder du erklärst das, oder ich unterstelle dir, dass du yalus 
Beitrag nicht gelesen hast.

EDIT: Ok, ich muss das noch mal ausprobieren bei Gelegenheit. Sicher, 
dass bei yalu's Methode 256 Iterationen gemacht werden?
Bin leider gerade in Klausurübungen vertieft.

Jörg Wunsch schrieb:
> Ein char muss
> mindestens 8 bits haben, um eine konforme Implementierung zu
> erreichen.
>
> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
> Implementierungen auf irgendeinem DSP,

Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020 
und noch andere. Das sind zwar alles seeeehr alte Dinger, aber immer 
noch viel benutzt in gewissen Technik-Bereichen. :-/
Hat aber einen Vorteil, eine Exception wegen "unaligned access" passiert 
dort nicht. :-) Ein Adressinkrement sind dort immer 32 Bit.

> der als kleinste adressierbare
> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
> definiert).
Genauso verhält es sich.


> uint8_t i;

Soetwas gibt es dann auch nicht. Wenn man einen Zähler bis 255 braucht, 
dann kann man nicht mit dem Überlauf arbeiten, sondern man muß das 
explizit kodieren, ansonsten Pech gehabt :-) Der Compiler ist nicht so 
schlau und setzt das selber um.

doc schrieb:
> Und siehe da, es geht mit 8 Bit.

Das ist doch aber nichts anderes als yalus Variante, nur dass er
das Inkrementieren in die while-Klausel verlegt hat (als Präfix-
Operator).

900ss D. schrieb:

> Nicht auf irgendeinem, es gibt mehrere, z.B. TMS320C3x oder ADSP21020
> und noch andere. [...]

Ich kannte sie gerade nicht mit Vornamen, daher habe ich das etwas
anonymisiert geschrieben. ;-)

>> uint8_t i;
>
> Soetwas gibt es dann auch nicht.

Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"
wäre es nicht).  Wenn man nicht "exakt 8 bits breit" meint, sollte
man sich ohnehin besser angewöhnen, "uint_fast8_t" statt "uint8_t"
zu benutzen.  Dann hat der Compiler die Freiheit, auf einem 32-bit-
Prozessor auch 32 bits stattdessen zu nutzen, wenn diese schneller
sind (bspw. ein komplettes 32-bit-Register auf einer 32-bit-CPU).

Jörg Wunsch schrieb:
> Richtig, daher ist diese Schreibweise auch sicher ("unsigned char i;"
> wäre es nicht).

Ja, ich nutze eigentlich auch nur noch die "neuen" Typen. Und es gibt 
sooo viele Leute, die das nicht machen. Gestern hat man mir Code aus dem 
Jahre 2000 vorgelegt, den ich jetzt adaptieren soll.

Dort steht dann z.B. drin:

#define BIT_AND &
#define LOG_AND &&
#define BIT_OR |
#define LOG_OR ||

if( status BIT_AND BIT_RX )
  machWas();

Der ganze Code ist mit solchen Makros vollgestopt. Kann man nicht lesen.
Mir ist nichts mehr eingefallen :-(
Ähh ja, Offtopic :-)

> Wenn man nicht "exakt 8 bits breit" meint
Schön formuliert :-)

900ss D. schrieb:

> #define BIT_AND &
> #define LOG_AND &&
> #define BIT_OR |
> #define LOG_OR ||

Das erinnert mich an ein Stück Software namens "team".  War ein
wirklich interessantes Stück von der Funktion: ein Ringpuffer
zur Zwischenspeicherung von Daten für ein Magnetbandgerät, damit
das Band am gleichmäßigen Laufen ("streaming") bleibt.  Anders als
das "creeping featurism"-Teil von GNU (heißt wohl "buffer") kam
team mit den Möglichkeiten eines V7 UNIX aus: für jeden der
umzuschaltenden Puffer wurde ein eigener Prozess per fork()
erzeugt, alle diese Prozesse haben sich die Deskriptoren für stdin
(Quell-Datenstrom) und stdout (Magnetband) geteilt, und die
Synchronisation zwischen den Prozessen (wer liest und wer schreibt)
erfolte über Pipes zwischen diesen.  Wirklich "cool", wie man das
heutzutage nenne würde.

Aber der Sourcecode.  Oh Gott. :-)

1

# define call           (void)

2

# define were           if

3

# define fast           register

4

# define global         /* extern */

5

# define local          static

6

# define when           break; case

7

# define otherwise      break; default

8

# define mode(which,name) typedef which name name; which name

9

# define bool   int

10

# define true           1

11

# define false          0

12

# define nil(type)      ((type) 0)

13

# define scalar         int

:-)

danny schrieb:
> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!
>
> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
> CP   Rxy, 0xFF
> BREQ adr
> erstellt!
>
> Macht er also nicht...

Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal 
semantisch korrekten Code schreiben, was haeltst Du davon?

Michael G. schrieb:
> danny schrieb:
>> Ok Ok.. mir ist klar das unsigned char als [0; 255] definiert ist!
>>
>> Ich habe nur dem Compiler soviel "Intelligenz" unterstellt, dass er ein
>> CP   Rxy, 0xFF
>> BREQ adr
>> erstellt!
>>
>> Macht er also nicht...
>
> Bevor Du die Qualitaet des Compilers anzweifelst solltest Du erst einmal
> semantisch korrekten Code schreiben, was haeltst Du davon?

Danke für deinen Kommentar.

Jörg Wunsch schrieb:
> Aber der Sourcecode.  Oh Gott. :-)

Ja das genauso schlimm :-)

Rolf Magnus schrieb:
> Der wußte wohl nicht, daß es einen Standard-C-Header gibt, der dafür
> extra schon Makros mitbringt.

Da schlägt es einen nieder. Das gibt es sogar vorgekaut ;-)
Nun ja, nicht mein Stil. Kann man sich wohl drna gewöhnen, wenn man es 
muß.

Dann kann man nachher Programme schreiben im Stil von

int main()
{
    Use Elevator() in case of "Fire";
}

oder sowas ;)

Jörg Wunsch schrieb:
> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
> definiert).

D. h. folgender Code würde nicht wie erwartet funktionieren?

1

#define BUFFSIZE 128

2

char * buff = malloc(sizeof(char)*BUFFSIZE);

3

if (buff) {

4

  uint8_t i;

5

  for (i = 0; i < BUFFSIZE; i++) {

6

    *(buff+i) = 42;

7

  }

8

}

weil malloc nur 128 Byte reserviert, aber 128 mal in 32 Bit Schritten 
weiter gegangen wird?

Falsch.
Genauer gesagt: der Code würde arbeiten wie ich es erwarte.
Was du erwartest weiß ich nicht genau :-)

Auf einem solchen System ist doch wie gesagt ein char
32 Bit groß (also nicht ein Byte, sondern 4).

Mit sizeof(char) ist dort 1, sizeof(char)*128 ist 128.
Also reserviert malloc(sizeof(char)*BUFFSIZE) dann
128 char, also 128*4 Byte.

Mit *(buff+0) bis *(buff+127) greift man auf jeweils eines
dieser 4-Byte-char zu und alles ist in Ordnung.
Außer daß jede 42 in 4 Byte gespeichert ist, weil ein char
ja so groß ist.

Malte __ schrieb:
> Jörg Wunsch schrieb:
>> Es können allerdings mehr Bits sein, es gibt beispielsweise konforme
>> Implementierungen auf irgendeinem DSP, der als kleinste adressierbare
>> Einheit einen 32-bit-Integer hat.  Dort ist ein char dann auch 32
>> bits breit (aber sizeof(char) ist trotzdem 1!, denn das ist so
>> definiert).
>
> D. h. folgender Code würde nicht wie erwartet funktionieren?

Kommt auf deine Erwartungen an :-)

>

1

> #define BUFFSIZE 128

2

> char * buff = malloc(sizeof(char)*BUFFSIZE);

3

> if (buff) {

4

>   uint8_t i;

5

>   for (i = 0; i < BUFFSIZE; i++) {

6

>     *(buff+i) = 42;

7

>   }

8

> }

9

>

> weil malloc nur 128 Byte reserviert,

warum sollte es?

Hinweis. Der C-Standard weiß eigentlich nichts von Bytes, so wie wir den 
Begriff benutzen. Im C-Standard ist Byte synonym zu sizeof(char) zu 
sehen. malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System 
dann 512 unsere üblichen 8 Bit Bytes entsprechen. In diesem Sinne ist 
die übliche Beschreibung für malloc, dass es 'Bytes' allokiert 
eigentlich nicht richtig. malloc allokiert die angegebene Anzahl 
char-Einheiten :-)

Bleifuss schrieb:
> Mit Pointercasting kann man sich dann aber eine rostige Scud durch den
> Fuss schiessen.

Auch nicht.
Das ist alles so abgestimmt, dass ein Rädchen ins andere greift :-)

Einzig und alleine auf Hardware-Bytes kann man dann nicht mehr direkt 
zugreifen.

ALlerdings macht man so etwas ja auch nicht nach Lust und Laune. 
Meistens stecken da Hardware-Restiktionen dahinter. D.h. dass es bei 
besagtem DSP höchst wahrscheinlich gar nicht möglich ist, auf 8 Bit 
Bytes im Speicher zuzugreifen.

Klaus Wachtler schrieb:
> Genauer gesagt: der Code würde arbeiten wie ich es erwarte.
> Was du erwartest weiß ich nicht genau :-)
Ich denke meist kann man von einem Code erwarten, dass nicht das Ziel 
ist in nicht zugewiesenen Speicher zu schreiben ;-)

Karl heinz Buchegger schrieb:
> malloc allokiert in dem Fall 128 C 'Bytes', die auf diesem System
> dann 512 unsere üblichen 8 Bit Bytes entsprechen.
Ok, dass macht dann wieder Sinn.

Klaus schrieb:

>> for(i=0;dooo(),++i;);
>
> Was will uns dieser Beitrag sagen?!?

Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
beinahe IOCCC-verdächtig. ;-)

Jörg Wunsch schrieb:
> Klaus schrieb:
>
>>> for(i=0;dooo(),++i;);
>>
>> Was will uns dieser Beitrag sagen?!?
>
> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
> 256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
> beinahe IOCCC-verdächtig. ;-)

Aaaah. Gut entziffert!

Btw, for-Schleifen wo nicht alle 3 "Teile" vorhanden sind, sind meist 
einfacher durch while oder do-while darstellbar. So als Faustregel.

Jörg Wunsch schrieb:
>>> for(i=0;dooo(),++i;);
>>
>> Was will uns dieser Beitrag sagen?!?
>
> Dass diese Schleife ebenfalls 256mal durchlaufen wird und dabei
> 256mal die Funktion dooo() aufgerufen wird.  Ist allerdings schon
> beinahe IOCCC-verdächtig. ;-)

Jein.

dooo() wird 256 mal aufgerufen, weil es im Test steht.
"Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor
dem Semikolon) wird nur 255 mal durchlaufen.

Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten
zu ersetzen...

Klaus Wachtler schrieb:
> Jein.
>
> dooo() wird 256 mal aufgerufen, weil es im Test steht.
> "Die Schleife" im Sinne des Schleifenrumpfes (das Nichts vor
> dem Semikolon) wird nur 255 mal durchlaufen.
>
> Nur zur Sicherheit, um Mißverständnisse durch neue Unklarheiten
> zu ersetzen...

Ah, ja, wichtiger Hinweis! Dann kann man natürlich keine andere Schleife 
benutzen um den "Effekt" zu benutzen.