Hi, On Mon, 18 Aug 2003, Oli Weiss wrote:

Mit dem Schluesselwort unsigned wird das erste Bit als "echte" Stelle interprtiert und nicht als Vorzeichenbit:

TYP WERTEBEREICH char, signed char -128 ... 127 unsigned char 0 ... 255

Also, um noch das letzte Quentchen zu diesem Thread beizutragen (nachdem Ralf und Phillip schon das wesentliche gesagt haben): "char", "signed char" und "unsigned char" sind drei _verschiedene_ Typen (!) . "char" ist als "signed char" oder "unsigned char" zu implementieren, welcher gewaehlt wird ist plattformabhaengig. Die Breite von char richtet sich nach der kleinsten addressierbaren Einheit. Ueblicherweise (aber nicht immer!) sind dies 8 Bit. (sh4 z.B. hat sizeof(char)==sizeof(int)==4). Wie diese 8 Bit interpretiert werden richtet sich nach der signedness von "char", i.e. ob's 0-255 oder -128-127 ist, ist plattformabhaengig. Man beachte, dass "int" gleich "signed int" ist, das gleiche gilt fuer "short", "long" und "long long", sowie vorraussichtlich fuer alle weiteren integer Typen die eventuell mal definiert werden. D.h. dass nur "char" einen Sonderstatus betreffend seiner signedness hat. So, Extrapunkte fuer den, der mir die signedness von bitfields herunterbeten kann ;-) (Ohne in den Standard zu gucken, also Phillip: du bist raus ;-) ) Ciao, Micha.

On Mon, 2003-08-18 at 10:06, Arndt Stedler wrote:

Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8) Nein. Es ist zwar wahr, dass auf den meisten Systemen ein char 8bit besitzt, doch ist nicht sichergestellt, dass ein char auf allen Systemen 8 Bit besitzt - Strenggenommen ist es jedoch blanker Zufall.

- Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden.

Nein. Die Grössen aller Typen sind hardware- und Compiler-flag abhängig, Das trifft auf char ebenso zu wie auf short und int. Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int) Ralf

Am Montag, 18. August 2003 13:12 schrieb Arndt Stedler:

Ups, dass auch short mehr als 16 bit haben kann war mir nicht klar. Danke dafür. (Liegt aber daran, dass ich bisher nur mit Prozessoren (und kompilern) gearbeitet habe, die das so gehandhabt haben. --- Äh, nein, Aussnahme war der AD SHARK-Compiler. Liegt aber daran, dass der SHARK alles mit minimum 32 bit behandelt und man immer komische konstrukte bauen musste, wenn man byteweise arbeiten wollte)

- Arndt

Am Montag, 18. August 2003 11:30 schrieb Ralf Corsepius:

...

On Mon, 2003-08-18 at 10:06, Arndt Stedler wrote:

...

Hallo Jan, also hier mal ein kurzer überblick: - unsigned char: ist ein BYTE ohne Vorzeichen, also ein 0 bis 255 - char ist ein BYTE MIT Vorzeichen, also -128 bis 127 beide haben einen Wertebereich von 2^8 (sprich 2 hoch 8)

Nein. Es ist zwar wahr, dass auf den meisten Systemen ein char 8bit besitzt, doch ist nicht sichergestellt, dass ein char auf allen Systemen 8 Bit besitzt - Strenggenommen ist es jedoch blanker Zufall.

...

- Der Datentyp "int" ist Hardwareabhängig und wariiert je nach Prozessor und sollte daher gemieden werden.

Nein. Die Grössen aller Typen sind hardware- und Compiler-flag abhängig, Das trifft auf char ebenso zu wie auf short und int.

Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)

Ralf

Jo, was unsigned char ist, ist mir jetzt klar! Danke!!!! mfg Jan

Hi, On Mon, 18 Aug 2003, Jan Hendrik Berlin wrote:

Hab mir mal kylix3 installiert! Läuft baer nicht!

Aha. Nun ja, der Bugfix wird wohl darin bestehen, es einfach zum Laufen zu bringen. Im Ernst: deine Bugbeschreibung ist reichlich duerftig. Was laeuft nicht?

Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h .

Was genau ist "der Aerger" mit time.h? Wie sind die Meldungen? Usw.

Kennt einer den Fehler schon?

Ich persoenlich habe mit Kylix3 noch nicht gearbeitet, deshalb kenne ich ihn nicht. Wenn du allerdings etwas praeziser fragen wuerdest, koennte man dir vielleicht trotzdem helfen. Ciao, Micha, der sechs Bier hatte.

Hi Leute! Am Dienstag, 19. August 2003 13:09 schrieb Jens Nixdorf:

Am Mon, 18 Aug 2003 22:10:16 +0200 schrieb Jan Hendrik Berlin :

...

Hi Leute! Hab mir mal kylix3 installiert! Läuft baer nicht! Also, arbeiten kann ich damit soweit, nur wenn ich was kompilieren möchte, macht er ärger mit der time.h . Jo, auf meiner SuSE 7.3 Machiene hatte ich das ohne weiteres schonmal am laufen! Kennt einer den Fehler schon?

nebenbei bemerkt: Daß Betreff falsch eingegliedert ist, dafür kann ich nichts. Ich habe das selbe Problem unter SuSE 8.2 Kylix bleibt beim öffnen von Dateien oder speichern im Dateifenster einfach hängen. so daß man da nur noch mit einem kill von Kylix wider raus kommt, oder wenn man Glück hat und sehr lange wartet

Mögliche Lösung: in den Projekt-Optionen unter Verzeichnisse/Bedingungen mit der Reihenfolge der Einträge unter Include-Pfad experimentieren. Bei manchen hilft es z.B. den Eintrag /usr/include ganz nach vorn zu setzen.

Das habe ich auch schon alles überprüft, und war von der Installation von Kylix alles richtig eingetragen. Ich habe irgend wo in der Mailingliste gelesen (weiss aber nicht mehr wo),mit: strace -fo /dev/null /usr/local/kylix3/bin/startdelphi & in einer Console gestartet würde alles funtionieren. Das trifft zwar auf den von mir oben genannten Fehler zu, Dateifenster kann man öffnen und schliessen, aber ein normales Arbeiten ist nicht möglich. Laut Aussage in der entsprechenden Mailingliste schiebt Borland den schwarzen Peter dem neuen Kernel zu und das selbe umgekehrt. Ich kann nur sagen daß ich kein Programm kenne, das nicht zu SuSE gehört und auch schon so alt ist und älter ist als Kylix 3 professional, solche Probleme keines macht. Meine Meinung ist, solange Borland kein Upgrade zur ferfügung stellt, wird Kylix 3 niemals ordentlich laufen auf einem SuSE 8.2. Auch auf dem neuen 2.4.21-4 Kernel läuft es nicht. Zu SuSE 8.0 u. 8.1 kann ich nichts dazu sagen, wiel ich es in dieser Zeit nicht installiert hatte (zu wenig Zeit in der damaligen Zeit). Nach meinen Reserchen die ich bis her schon alle angestellt habe, gibt es nur die Möglichkeit, altes SuSE und Kylix 3 oder auf Kylix zu verzichten. Schade, ich hätte Kylix 3 auch gerne am laufen. Viele Grüsse Heinz

Am Tue, 19 Aug 2003 18:42:34 +0200 schrieb Jan Hendrik Berlin :

Hall Heinz Dittmar, hallo leute! Also erstmal zu Heinz Dittmar, bitte lies dich deine mails nochmal, bevor du sie in die weite Welt hinaus schickst! So abgehackte Sätze lesen sich recht schwer!

Das finde ich ganz schön mutig! Wer im Glashaus sitzt... mfG, Jens

Moin! Am Die, 2003-08-19 um 17.06 schrieb Heinz Dittmar:

Ich habe das selbe Problem unter SuSE 8.2

Nutze ich auch

Kylix bleibt beim öffnen von Dateien oder speichern im Dateifenster einfach hängen. so daß man da nur noch mit einem kill von Kylix wider raus kommt, oder wenn man Glück hat und sehr lange wartet

Das habe ich auch schon alles überprüft, und war von der Installation von Kylix alles richtig eingetragen.

Ich habe irgend wo in der Mailingliste gelesen (weiss aber nicht mehr wo),mit: strace -fo /dev/null /usr/local/kylix3/bin/startdelphi & in einer Console gestartet würde alles funtionieren.

Hier sind einige "tricks" gesammelt. http://www.kylixforum.de/forum/viewforum.php?f=11&sid=c2f3f016a235c81dae5d4c25f3f69fd8 Einen Patch gibt es auch.

Meine Meinung ist, solange Borland kein Upgrade zur ferfügung stellt, wird Kylix 3 niemals ordentlich laufen auf einem SuSE 8.2. Auch auf dem neuen 2.4.21-4 Kernel läuft es nicht. Zu SuSE 8.0 u. 8.1 kann ich nichts dazu sagen, wiel ich es in dieser Zeit nicht installiert hatte (zu wenig Zeit in der damaligen Zeit). Nach meinen Reserchen die ich bis her schon alle angestellt habe, gibt es nur die Möglichkeit, altes SuSE und Kylix 3 oder auf Kylix zu verzichten. Schade, ich hätte Kylix 3 auch gerne am laufen.

Kylix/Delphi habe ich hier zumlaufen gekriegt. Ziemlich lange dran rumgebastelt. Selbst mit Patch. Kylix/c++ gibt beim comiplieren des leeren Fensters schon eine ellenlange Fehlerliste aus. Hab ich dann gleich abgebrochen - keinen Bock mehr. Obwohl ich C++ gerne hätte, aber irgendwie ist mir die Zeit zu schade. Meine Meinung ist das Borland ein ganz klein wenig misslungen. Support - nicht wirklich. Elchtest mässig...

On Wed, 2003-08-20 at 22:40, Thorsten Haude wrote:

Moin,

* Ralf Corsepius [2003-08-18 11:30]:

...

Das einzige, worauf man sich verlassen kann. wäre: sizeof(char) <= sizeof(short) <= sizeof(int)

Wie ich gerade gelesen habe, fordert ISO C Mindestgrößen, char 8 Bit, short und int 16 Bit, long 32 Bit.

Ist ja schön für ISO-C (Ich habe keine Kopie des ISO-C/C99 oder C89), nur sieht die Praxis anders aus. Beispiele: 1. Auf DSPs gilt oft sizeof(char) == sizeof(short) == sizeof(int) = 1 == 32bit. z.B.: TI TMS320C[34]x-Prozessoren (als c4x|c3x in gcc-2.95 und tic3x/4x CPU in gcc-3.x zu finden) 2. Auf 16-bit-Systemen gilt oft sizeof(char) = 1 == 8bit sizeof(short) == sizeof(int) = 2 == 16bit z.B.: Hitachi h83xx (als h8300 in gcc zu finden) IIRC, gehören der C6502 (C64-Prozessor) und der Z80 ebenfalls in diese Kategorie von Prozessoren. 3. Es gibt historische Systeme (Heute praktisch ohne Belang), die mit weniger als 8bit pro char gearbeitet haben (z.B. 6bit/7bit-Systeme). IIRC, gehören frühe PDPs dazu. Ralf

Unterlass bitte den TOFU (näheres unter http://learn.to/quote), das bringt dir keine Freunde ein. Arndt Stedler [Mon, 18 Aug 2003 10:06:34 +0200]:

- Der Datentyp "int" ist Hardwareabhängig und variiert je nach Prozessor und sollte daher gemieden werden. Wenn du mit 16 bit auskommst benutze besser: "short" oder "unsigned short", für 32-bit "long" oder "unsigned long"

Falsch! Der ISO C Standard definiert nur Mindestlängen für Datentypen. Präziser definiert die Datentypen das zur jeweiligen Plattform gehörende ABI. So gilt z.B. für Linux auf AMD64 (Opteron, Athlon64): char 8 Bit short 16 Bit int 32 Bit long 64 Bit Datentypen wie int kann man sehr wohl verwenden, wenn es vorrangig um schnelle Verarbeitung geht. Wer Datentypen exakter Länge benötigt, verwendet unter ISO C99 die in inttypes.h definierten Typen. Dort findet man dann z.B. int8_t, int16_t oder int32_t. Philipp -- Philipp Thomas Arbeit: pthomas@suse.de SuSE Linux AG Privat: philipp.thomas@t-link.de

Moin, * Daniel Feist [2003-08-18 10:12]:

Normalerweise hat ja char einen Wertebereich zwischen minus 127 und plus 128 - dieser Bereich wird auch 'signed char' gennant. 'char' wird automatisch als 'signed char' betrachtet bzw. 'char' oder 'signed char' ist das gleiche.

Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein. "Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions. (Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)

Jetzt gibt es aber auch noch eine Möglichkeit, den Wertebereich von char zu erweitern - das geht mit 'unsigned char'.

s/erweitern/verschieben/

...

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com

Einfach löschen, was Du nicht mehr brauchst. Thorsten -- It is exactly because markets are amoral that we cannot leave the allocation of resources entirely to them. - George Soros

Hi, On Wed, 20 Aug 2003, Daniel Feist wrote:

...

Das gilt nur für die anderen Ganzzahlentypen. Der Wertebereich von 'char' ist vom Compilerbauer frei wählbar und kann 'signed char', 'unsigned char' oder wie ich gerade lese eine Mischform sein.

"Mischform?" fragt Ihr Euch jetzt: Type char may be a "pseudo-unsigned" integral type - that is, it can contain only nonnegative values, but it is treated as if it were a signed type when performing the usual unary conversions.

(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)

Ist aber Unsinn. 6.2.5 #15: The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char.35) NB der letzten Halbsatz. Das Verhalten von 'char' muss exakt mit entweder 'signed char' oder 'unsigned char' uebereinstimmen. Nix Mischform.

Genau so ist das - es ist ja so, dass da mit signed und unsigned nicht nur bei char so ist, sodern auch bei anderen - hier eine kleine Tabelle:

char, signed char 1 Byte == 8 Bit -128 +127

Nein, du hast nicht verstanden worum es ging. 'char' ist ein _dritter_ Typ, neben 'signed char' und 'unsigned char'. Seine Attribute sind gleich denen von _entweder_ 'signed char' _oder_ 'unsigned char'. Das ist ein Unterschied zu den anderen integer Typen, wo 'xx' implizit die signed Variante ist (xx == {short int,int,long,long long}), d.h. fuer diese gibt es nur jeweils zwei Varianten. Ein char hat auch nicht immer 8 Bit. Genau wie die Breiten aller anderen von dir angegebenen Typen nicht festgelegt ist. Insbesondere ist "long" sehr oft auch 64bit gross. Ciao, Micha.

Thorsten Haude [Wed, 20 Aug 2003 22:44:09 +0200]:

...

Ist aber Unsinn. 6.2.5 #15:

Wenn Du das so deutlich beurteilst, solltest Du vielleicht die Quelle nennen.

Die massgebliche: ISO/IEC 9899:1999, besser bekannt als ISO C99, sprich der aktuelle C Standard :) Philipp

Moin, * Michael Matz [2003-08-21 12:09]:

On Wed, 20 Aug 2003, Thorsten Haude wrote:

...

...

...

...

(Samuel P. Harbison, Guy L. Steele: C: A Reference Manual)

Ist aber Unsinn. 6.2.5 #15:

Wenn Du das so deutlich beurteilst, solltest Du vielleicht die Quelle nennen.

Err. Hab ich ja. Du hast sie sogar noch zitiert: 6.2.5 #15.

Das hätte ich an der Kapitelnummer erkennen sollen?

Natuerlich im ISO/IEC 9899:1999 .

Ach so. Gibt's die im Netz?

...

Es ist gut möglich, daß das C:ARM sich irrt, aber aus irgendeinem Grund werden sie das so beschrieben haben.

Entweder sie irren sich, oder du interpretierst zuviel hinein.

Naja, so viel kann man da nicht falsch interpretieren. Es sind drei Punkte, erster und zweiter sind 'signed char' und 'unsigned char', den dritten habe ich zitiert. Die Brüder scheinen da einfach falsch zu liegen. Thorsten -- It has become appallingly obvious that our technology has exceeded our humanity. - Albert Einstein

Moin, * Daniel Feist [2003-08-20 11:01]:

On Wed, 20 Aug 2003, Thorsten Haude wrote:

...

* Daniel Feist [2003-08-18 10:12]: Genau so ist das - es ist ja so, dass da mit signed und unsigned nicht nur bei char so ist, sodern auch bei anderen

Nein, eben nicht. Der Typ 'char' hat eine ganz besondere Rolle. Nur bei den anderen integralen Typen ist <typ> == signed <typ>. Die Längen, die Du anschließend in der Tabelle aufführst, sind auch nur Zufall, die Typen können auch eine andere Länge haben. Es gibt zwar einige Regeln, aber nur Mindestgrößen: (signed) int: INT_MIN...INT_MAX unsigned int: 0...UINT_MAX Mit INT_MIN <= -32767, INT_MAX >= 32767, UINT_MAX >= 65535 Und so weiter, mit char >= 8 Bit, short >= 16 Bit, long >= 32 Bit. Außerdem gibt es noch CHAR_BIT, das die Anzahl Bits für den Typ char enthält. (Kann ich nicht fein aus der Referenz abtippen?)

printf("a = %c\n", b); /*Überrascht?*/

Nein.

Wichtig ist, dass der richtige Datentyp mit %c dem Compiler richtig gesagt wird - dann weiß dieser, dass er die ASCII-Tabelle nehmen soll - hätte man eben %d genommen, wäre 65 richtig ausgegen worden.

Richtig ist, daß Du printf() mitteilst, wie es den Parameter interpretieren soll. Du kannst auch einen Pointer als Integral interpretieren, kein Problem.

...

...

...

-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-programming-unsubscribe@suse.com Um eine Liste aller verfügbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-programming-help@suse.com

Einfach löschen, was Du nicht mehr brauchst.

Hallo? Jemand zuhause? Thorsten -- Calvin: "Who can fathom the feminine mind?" Hobbes: "I like `em anyway"