Wolfgang wrote:
Was passiert 2038?
Das Ende der Welt. Genauso wie am letzten Samstag.
-Wolfgang
Wie ich M$ so kenne werden die ab diesem Jahr damit von ihren Y2k Bugs ablenken und versuchen alle von Linux weg zu bringen. So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-) So dumm wie das klingt, aber M$ schafft es ja auch den Leuten die grafische Oberfläche als NEU zu verkaufen. Die glauben auch das jemand der Linux installieren kann, zu blöd sein soll dieses wieder von der Kiste zu entfernen. (Machen wir ja hin und wieder, aber nur um die neue Distri zu installieren :-) ) so long, Holger --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 03-Jan-00 holgerj.keilhauer@gecits-eu.com wrote:
Wolfgang wrote:
Was passiert 2038?
Das Ende der Welt. Genauso wie am letzten Samstag.
-Wolfgang
Wie ich M$ so kenne werden die ab diesem Jahr damit von ihren Y2k Bugs ablenken und versuchen alle von Linux weg zu bringen. So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-)
Tatsache ist, dass die MFC-Bibliothek auch nicht Jahr 2038 sicher ist. Viele Programme, die mit Visual C++ erstellt wurden, werden auch nicht richtig laufen. Aber ich schätze mal, dass es für Linux und die MFC irgendwann Patches geben wird (ich bin nun mal Optimist).
so long, Holger
MfG Florian Rauh ------------------------------------------------------ May the source be with you! ------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, Jan 03, 2000 Florian Rauh wrote: [Y2038-problem...]
Aber ich schätze mal, dass es für Linux und die MFC irgendwann Patches geben wird (ich bin nun mal Optimist).
auf suse.de hab ich irgendwo was dazu gefunden. da schreiben die, man müsste einfach ne variable im kernel-source umstellen und dann würde das datum wieder für weitere millionen (?) jahre reichen. afaik hängt das problem damit zusammen, dass linux ein 32bit-system ist, da is einfach nur platz fürs datum bis 2038. sun solaris is afaik ein 64bit-system, die haben das problem nicht. aber...in 38 jahren, ist linux da doch wohl auch 64bit'ig, oder? bye, moritz -- Moritz Schulte - hp9001.fh-bielefeld.de/~moritz/, PGP Key available| ---- Zufallssignatur #18: -----------------------------------------| "The number of UNIX installations has grown to 10, with more | expected" - The UNIX Programmers Manual, 2nd Edition, June 1972 - | --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Moritz Schulte schrieb am 03.Jan.2000:
auf suse.de hab ich irgendwo was dazu gefunden. da schreiben die, man müsste einfach ne variable im kernel-source umstellen und dann würde das datum wieder für weitere millionen (?) jahre reichen.
Nein, viel, viel länger. 292277 mal eine Millionen Jahre.
afaik hängt das problem damit zusammen, dass linux ein 32bit-system ist, da is einfach nur platz fürs datum bis 2038. sun solaris is afaik ein 64bit-system, die haben das problem nicht. aber...in 38 jahren, ist linux da doch wohl auch 64bit'ig, oder?
Es hängt damit zusammen, daß bei Linux das Datum mit einer 32 bit Zahl dargestellt wird. Natürlich kann man auch auf einem 32bit-System 64 Bit Zahlen darstellen. Double-werte sind noch viel länger. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: file://usr/doc/susehilf/index.html | mit Apache: http://localhost/doc/susehilf/index.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo,
Es hängt damit zusammen, daß bei Linux das Datum mit einer 32 bit Zahl dargestellt wird. Natürlich kann man auch auf einem 32bit-System 64 Bit Zahlen darstellen. Double-werte sind noch viel länger.
Was mir bei diesem Thread irgendwie abgeht ist die Feststellung, dass sich ein 32-bit Prozessor mit 64-bittigen Variablen irgendwie mehr plagen muss, als mit 32-bittigen. Warum sollte der Kernel jetzt (! - nicht mehr sobald 64-bittige CPUŽs Standard sind; aber vor 2030) sich plagen und ein viel zu großes Datum darstellen koennen - wir sind ja nicht bei Microsoft, dass wir Beschaeftigungstherapie fuer die CPU machen muessen. Waere halt nett, wenn die Breite rechtzeitig aendert... nicht dass wieder so ein Kuddelmuddel/Medienrummel wie mit 2000 rauskommt "... man hat ja vor 2 jahren noch nicht wissen koennen, dass das jahr 2000 so schnell kommen wird ..." (OOe Nachrichten von irgendwann 1. Halbjahr 1999) ciao, Adalbert --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Bernd Brodesser wrote:
Es hängt damit zusammen, daß bei Linux das Datum mit einer 32 bit Zahl dargestellt wird. Natürlich kann man auch auf einem 32bit-System 64 Bit Zahlen darstellen. Double-werte sind noch viel länger.
Falsch: double ist auch 64 bit. long double ist 80 bit. double wird z.B. von Excel zum Speichern des Datums benutzt. Als Tage seit 1900. Eine Stunde ist z.B. 1/24 = 0,4166666... aber das wird OT. -- __ _ Raymond Häb, ray.haeb@gmx.net, cologne, germany / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . . --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Raymond Haeb schrieb am 05.Jan.2000:
Falsch: double ist auch 64 bit. long double ist 80 bit.
Ok, meinetwegen long double.
double wird z.B. von Excel zum Speichern des Datums benutzt. Als Tage seit 1900. Eine Stunde ist z.B. 1/24 = 0,4166666...
Was hat exel mit Linux zu tun? Windows benutzt sicherlich einen anderen C-Kompiler, wenn es überhaupt C benutzt. Wie groß ein double ist hängt nur vom kompieler ab. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: file://usr/doc/susehilf/index.html | mit Apache: http://localhost/doc/susehilf/index.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Bernd Brodesser (B.Brodesser@online-club.de) [20000106 07:23]:
anderen C-Kompiler, wenn es überhaupt C benutzt. Wie groß ein double ist hängt nur vom kompieler ab.
Falsch! Die Mindestgrößen von Datentypen in C legt der ISO-Standard fest. Alles weitere hängt vom Prozessor, nicht aber vom Compiler, ab. So arbeitet der Coprozessor in iX86 Chips z.B. intern mit erweiterter Präzision, was zu Problemen führen kann, wenn es nicht berücksichtigt wird. -- Mit freundlichen Gruessen, Ihr SuSE Support-Team Philipp Thomas ------------------------------------------------------------ SuSE GmbH, Tel: +49-911-7405330 Mo/Do 13-18.00 Schanzaeckerstr. 10, Fax: +49-911-3206727 90443 Nuernberg, Email: support@suse.de Germany WWW: http://www.suse.de/Support/sdb ------------------------------------------------------------ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Date sent: Thu, 6 Jan 2000 12:17:17 +0100
From: Philipp Thomas
anderen C-Kompiler, wenn es überhaupt C benutzt. Wie groß ein double ist hängt nur vom kompieler ab.
Falsch! Die Mindestgrößen von Datentypen in C legt der ISO-Standard fest. Alles weitere hängt vom Prozessor, nicht aber vom Compiler, ab. So arbeitet der Coprozessor in iX86 Chips z.B. intern mit erweiterter Präzision, was zu Problemen führen kann, wenn es nicht berücksichtigt wird.
nicht ganz. Es haengt schon vom Compiler ab. Nur dass es halt ueblich ist, die Datentypen hardware-nah abzubilden, weil es halt so schneller ist. Es hindert keinen auf 8086 mit 256 bittigen Floats zu rechnen, aber ich moechte nicht, dass meine Gehaltsabrechnung auf solchen Systemen erstellt wird ;-) Dito bei integers. Im uebrigen gibt es Systeme(Interpreter- Compiler), die mit beliebiger Genauigkeit rechnen koennen (natuerlich im Rahmen des Speichers). Und das freut primzahlsucher :-)) Waldemar --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Waldemar Krzok wrote:
Dito bei integers. Im uebrigen gibt es Systeme(Interpreter- Compiler), die mit beliebiger Genauigkeit rechnen koennen (natuerlich im Rahmen des Speichers). Und das freut primzahlsucher :-))
Das ist interessant, duerfte aber sehr Rechenleistungsintensiv sein, also werden meine Programme noch langsamer. Wieviele Deep Blues musz ich denn statt meinem Athlon dafuer einsetzen? Ich suche naemlich soetwas aehnliches, allerdings will ich vollkommene Zahlen haben und keine primes, was noch zusaetliche Kontrollrechnungen bedeutet! CU Kaj M. Berggreen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Kaj Merten Berggreen wrote: [Beliebig genaue Zahlen]
Das ist interessant, duerfte aber sehr Rechenleistungsintensiv sein, also werden meine Programme noch langsamer. Wieviele Deep Blues musz ich denn statt meinem Athlon dafuer einsetzen? Ich suche naemlich soetwas aehnliches, allerdings will ich vollkommene Zahlen haben und keine primes, was noch zusaetliche Kontrollrechnungen bedeutet!
Bastel dir doch mit c++ ne Klasse die das kann. Vieleicht (wahrscheinlich?) gibet die auch schon. Das Datenformat intern kanns du beliebig basteln, und die Grundrechenarten als überladene operatoren implementieren. -- __ _ Raymond Häb, ray.haeb@gmx.net, cologne, germany / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . . --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Kaj Merten Berggreen schrieb am 06.Jan.2000:
Das ist interessant, duerfte aber sehr Rechenleistungsintensiv sein, also werden meine Programme noch langsamer. Wieviele Deep Blues musz ich denn statt meinem Athlon dafuer einsetzen? Ich suche naemlich soetwas aehnliches, allerdings will ich vollkommene Zahlen haben und keine primes, was noch zusaetliche Kontrollrechnungen bedeutet!
Wieso, eine gerade vollkommene Zahl ist von der Gestalt: 2^(k-1) (2^k-1) und zwar ngenau dann, wenn (2^k-1) eine Primzahl ist. Dies kann nur der Fall sein., wenn auch k eine ist. Ungerade vollkommene Zahlen gibt es unter 10^20 nicht. Aus dtv-Atlas zur Mathematik. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Thu, 06 Jan 2000, Philipp Thomas wrote:
* Bernd Brodesser (B.Brodesser@online-club.de) [20000106 07:23]:
anderen C-Kompiler, wenn es überhaupt C benutzt. Wie groß ein double ist hängt nur vom kompieler ab.
Falsch! Die Mindestgrößen von Datentypen in C legt der ISO-Standard fest. Alles weitere hängt vom Prozessor, nicht aber vom Compiler, ab. So arbeitet der Coprozessor in iX86 Chips z.B. intern mit erweiterter Präzision, was zu Problemen führen kann, wenn es nicht berücksichtigt wird.
Das gilt aber nur für Typen wie long, short, double usw. Was int
oder float darstellen (und wie lang diese sind) ist im Allgemeinen
architekturspezifisch. Siehe dazu auch: Programmieren in C von
Kernighan / Ritchie, die sollten das eigentlich wissen ;-)
In diesem tollen Buch gab es übrigens einen Hinweis auf die
Include-Dateien
Hi, Jan! Trying to kill the keyboard, Jan Trippler (Jan.Trippler@t-online.de) produced 1,4K in 39 lines: [Mindestgrößen von Datentypen, compilerabhaengig ...]
Das gilt aber nur für Typen wie long, short, double usw. Was int oder float darstellen (und wie lang diese sind) ist im Allgemeinen architekturspezifisch. Siehe dazu auch: Programmieren in C von Kernighan / Ritchie, die sollten das eigentlich wissen ;-)
Da wir bei dem Thema sind: Denkt mal nach, warum in den RFCs stets von octets die Rede ist statt von bytes die Rede ist.
P.P.S.: Das Buch ist wirklich genial und noch dazu von den Erfindern der Programmiersprache C. Für alle Interessenten: Kernighan / Ritchie Programmieren in C
Du meinst "Programming in C"? (Soweit ich weiss, sprechen K&R nicht deutsch) :-) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Fri, 07 Jan 2000, Wolfgang Weisselberg wrote: [...]
Da wir bei dem Thema sind: Denkt mal nach, warum in den RFCs stets von octets die Rede ist statt von bytes die Rede ist.
Aha, und was ist ein Octet? Und was ist der Unterschied zwischen Octet und Byte?
Du meinst "Programming in C"? (Soweit ich weiss, sprechen K&R nicht deutsch) :-)
Ich meine: "Programmieren in C". Es gibt eine Volksgruppe, die sich hauptamtlich damit befasst, gesprochene oder geschriebene Sachen von einer in eine andere Sprache zu übertragen. Der Durchschnittsbürger nennt sie: Übersetzer. Im Falle eines geschriebenen Textes zwischen zwei Pappdeckeln (= Buch) bleibt aber der Verfasser trotzdem der des Originals. Jan P.S.: Was ich meinte, war eigentlich klar erkennbar (z. B. an den ISBN's und Verlagsangaben). Was eigentlich hast Du mit Deiner Mail bezweckt? Manchmal kann ich Deinen Gedanken einfach nicht mehr folgen ;-) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 7th of Chaos, 3166, Jan Trippler wrote:
On Fri, 07 Jan 2000, Wolfgang Weisselberg wrote: [...]
Da wir bei dem Thema sind: Denkt mal nach, warum in den RFCs stets von octets die Rede ist statt von bytes die Rede ist.
Aha, und was ist ein Octet? Und was ist der Unterschied zwischen Octet und Byte?
Ich schätze mal dass ein Octet wirklich acht (8) Bit sind, während
ein Byte durchaus mehr sein kann. Z.B. ist ein "char" auf einer
Honeywell 6000 neun (9) Bit lang.
Thorsten
--
Thorsten Jens
* Jan Trippler schrieb am 07.Jan.2000:
On Fri, 07 Jan 2000, Wolfgang Weisselberg wrote: [...]
Da wir bei dem Thema sind: Denkt mal nach, warum in den RFCs stets von octets die Rede ist statt von bytes die Rede ist.
Aha, und was ist ein Octet? Und was ist der Unterschied zwischen Octet und Byte?
Ein Byte ist die kleinste adressierbare Einheit. Auf einem PC und vielen Rechner sind das acht Bit, aber nicht auf jedem Rechner. Bernd -- Hast Du bei Problemen schon in der SuSE-Support-Datenbank (SDB) nachgesehen? Auf Deinem Rechner: file://usr/doc/susehilf/index.html | mit Apache: http://localhost/doc/susehilf/index.html | Zufalls- Tagesaktuell bei SuSE: http://sdb.suse.de/sdb/de/html/index.html | signatur 2 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Jan Trippler schrieb in 1,1K (34 Zeilen):
On Fri, 07 Jan 2000, Wolfgang Weisselberg wrote:
Denkt mal nach, warum in den RFCs stets von octets die Rede ist statt von bytes die Rede ist.
Aha, und was ist ein Octet? Und was ist der Unterschied zwischen Octet und Byte?
Ein Octet sind 8 bits. Ein Byte kann auch mal 7 bits sein, oder auch 16 ... ein Word kann auch ziemlich interessant sein. Haengt alles von der Architektur ab. Bloss weil ihr alle US-Cent^WIntel-Zentrisch denkt, ist das noch lange nicht die Realitaet. (Sieh z.B. RFC 1037 ...)
Du meinst "Programming in C"? (Soweit ich weiss, sprechen K&R nicht deutsch) :-)
Ich meine: "Programmieren in C". [Uebersetzer]
P.S.: Was ich meinte, war eigentlich klar erkennbar (z. B. an den ISBN's und Verlagsangaben). Was eigentlich hast Du mit Deiner Mail bezweckt? Manchmal kann ich Deinen Gedanken einfach nicht mehr folgen ;-)
In der Regel ist das Buch besser als der Film^W^W^W^W^WOriginal besser als die Uebersetzung, so man die Originalsprache beherrscht. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 8th of Chaos, 3166, Wolfgang Weisselberg wrote: [... Programmieren in C ...]
In der Regel ist das Buch besser als der Film^W^W^W^W^WOriginal besser als die Uebersetzung, so man die Originalsprache beherrscht.
Bei Romanen und Shakespeare hast du natürlich Recht. Aber da es bei
Programmierbüchern zum großen Teil auf die Sourcen ankommt, spielt
es da IMHO kein so *große* Rolle.
Thor "haupt(){..." sten
--
Thorsten Jens
On Sat, 08 Jan 2000, Wolfgang Weisselberg wrote:
Ein Octet sind 8 bits. Ein Byte kann auch mal 7 bits sein, oder auch 16 ... ein Word kann auch ziemlich interessant sein. Haengt alles von der Architektur ab. Bloss weil ihr alle US-Cent^WIntel-Zentrisch denkt, ist das noch lange nicht die Realitaet. (Sieh z.B. RFC 1037 ...)
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1037.txt Was soll uns das denn wieder sagen? Dieser RFC handelt von NFILE (A File Access Protocol). Danke für die Belehrung. Ich programmiere auch auf einigen RISC- Rechnerarchitekturen, auf allen ist ein Byte = 8 Bit. 16 Bit sind auf allen 1 Word. Es mag sein, dass es andere gibt, aber das führt hier doch wohl ein wenig zu weit, oder? BTW: Davon auszugehen, dass ^W immer ein Backspace darstellt, ist auch ziemlich architekturspezifisch gedacht ;-) Und um mit Deinen Worten zu sprechen: Nein, ich erwarte darauf keine Antwort. [Programmieren in C]
In der Regel ist das Buch besser als der Film^W^W^W^W^WOriginal besser als die Uebersetzung, so man die Originalsprache beherrscht.
Ich habe keine Regel :-) 1. Ich kann ein deutsch geschriebenes Buch schneller lesen als ein englisches, also ist es effektiver für mich. 2. Das Buch war (in der deutschen Übersetzung!) gut zu verstehen, nach meiner Einschätzung frei von Fehlern und in gut zu lesendem Stil. Was will ich mehr? 3. Meine ich immer noch "Programmieren in C". Jan P.S.: Du belehrst gern? P.P.S.: OT? --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
hello world! On Sun, 09 Jan 2000, ca.14:00 las ich erschuettert folgende Zeilen: (leicht umformattiert)
Ein Byte kann auch mal 7 bits sein, FALSCH. Ein Byte kann auch mal 16 bits sein, FALSCH Haengt alles von der Architektur ab. FALSCH
Hoffentlich hat das niemand geglaubt! Ich frage mich nur, woher solche Infos bezogen werden. Wenn aus Buechern -> bitte weiterverwenden als Monitorunterlage usw. aber nicht als Lektuere!
ein Word kann auch ziemlich interessant sein. Alles in C ist interessant - wieso ausgerechnet ein 'word' ?
[ ... ] Ich programmiere auch auf einigen RISC- Rechnerarchitekturen, auf allen ist ein Byte = 8 Bit. 16 Bit sind auf allen 1 Word. Es mag sein, dass es andere gibt, aber das führt hier doch wohl ein wenig zu weit, oder?
Komme gerade von einem RISC-System und haette mich doch sehr gewundert, wenn jetzt alles anders waere ... In grauer Vorzeit soll ein Wort mal eine Breite von acht Bits gehabt haben und ein Langes Wort das Doppelte - aber nie eine Betaetigung gefunden. Und wenn das mal gestimmt hat; dann ist es laengst ueberholt.
[Programmieren in C]
Darum geht es hier doch - oder?
[ ... ] Meine ich immer noch "Programmieren in C".
Na, dann is ja gut! ;-) Was koennte an einem 'word' interessant sein? Dass mal 0xffff == -1 sein kann oder auch 65535 ?!? dann ist aber ein char genauso interessant: 0xff == -1 aber auch 0xff == 255 und wenn ich nun in ein signed char unbedingt Characters schreiben will, dann stehen mir eben nur 7 Bit zur Verfuegung: von 0 ... 127 -->> ASCII aber daraus zu folgern, dass ein Byte gelegentlich nur 7 Bit haette ... Vielleicht hat der Autor der Falschzeilen oben das mal gehoert. Da kann ich nur empfehlen, kein Octet sondern ein Six-Pack zu nehmen, (Holsten z.B.) und 'The C Programming Language' von K&R in Ruhe zu studieren und dann wieder hier zu schreiben. Gerade der Weitsicht der Herren Kernighan and Ritchie ist es zu verdanken, dass endlich mit (fast) allen Unklarheiten aufgeraeumt wurde - - ueber alle Plattform-Grenzen hinweg - und das war 1977 ! ANSI - C hat darauf aufgesetzt und den Rest erledigt. Das ist Standard - und gcc haelt sich dran. Das ist, was mir an C so gefaellt: egal, wo man hinkommt, C bleibt C Dass aber 1 Byte von 7, 8 ... 16 Bit in der Breite schwanken soll, dass war ne echte Ente! - Taugt noch nicht mal fuern 1. April -- mit freundlichen Grüßen Hajo C Jeske u. Tux --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Hajo C Jeske wrote on Sun, Jan 09, 2000 at 14:02 +0100:
Ein Byte kann auch mal 16 bits sein, FALSCH Haengt alles von der Architektur ab. FALSCH
Wenn ich einen Microcontroller habe, der intern vollständig mit 6 oder 10 oder weiß ich was bits arbeitet, kann ich mir schon vorstellen, das ein char in 10 bit gespeichert wird, sonst wäre es ja brechend langsam und umständlich!
Komme gerade von einem RISC-System und haette mich doch sehr gewundert, wenn jetzt alles anders waere ...
Vermutlich aber ne "normale" Architektur? 8, 16, 33 oder 64 Bit werden nun mal in sehr vielen Processoren verwendet. Aber es _gibt_ eben auch andere...
Was koennte an einem 'word' interessant sein? Dass mal 0xffff == -1 sein kann oder auch 65535 ?!?
Das ist IHMO ein Relikt aus grauer Steinzeitprogrammierung, das ein char z.B. -1 werden darf. Normalerweise hat ein typ einen Wertebereich, in dem darf dann ein Wert liegen. Bei char ist 0-255 üblich, damit KEIN -1, damit müsste ein Fehler ausgelöst werden. Aber C hat sich nie um Typen geschert, C++ gibts auch nicht ohne Grund...
Gerade der Weitsicht der Herren Kernighan and Ritchie ist es zu verdanken, dass endlich mit (fast) allen Unklarheiten aufgeraeumt wurde - - ueber alle Plattform-Grenzen hinweg - und das war 1977 ! ANSI - C hat darauf aufgesetzt und den Rest erledigt.
Hast Du mal überlegt, daß sich seit 1977 evtl. einige neue Erkentnisse ergeben haben? Das z.B. die Compilerbau Theorie weiterentickelt wurde? Das man Softwareengineering kennt? Das man gelernt hat, das Typprüfungen ne sehr sinnvolle Sache ist?
Das ist Standard - und gcc haelt sich dran. Das ist, was mir an C so gefaellt: egal, wo man hinkommt, C bleibt C
Bitte? C ist nicht ein Standard, sondern etliche. ANSI-C und K&R-C ist doch schon ein ganz schöner Unterschied... Wenn C immer gleich C wäre, wozu dann ./configure? OK, wenn man nur den C-Sprachumfang, ohne Libc und so ansschaut, mag das ja teils stimmen, aber C ist nun mal hardwareabhänig, und kann ja damit nicht überall gleich sein. Besonders solch -1 Geschichten können schon unterschiedliche Werte auf unterschiedlichen Architketuren sein. "int" ist ein schneller Typ, der auch mal 64 bit breit sein kann. z.b.
Dass aber 1 Byte von 7, 8 ... 16 Bit in der Breite schwanken soll, dass war ne echte Ente! - Taugt noch nicht mal fuern 1. April
Klingt IMHO dann doch etwas resolut - vielleicht hat er ja mal einen Controller programmiert, und da war ein "byte" eben etwas 16 bittiges? Man kann ja nicht alles kennen, oder?? oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Steffen Dettmer wrote:
* Hajo C Jeske wrote on Sun, Jan 09, 2000 at 14:02 +0100:
Was koennte an einem 'word' interessant sein? Dass mal 0xffff == -1 sein kann oder auch 65535 ?!?
Das ist IHMO ein Relikt aus grauer Steinzeitprogrammierung, das ein char z.B. -1 werden darf. Normalerweise hat ein typ einen Wertebereich, in dem darf dann ein Wert liegen. Bei char ist 0-255 üblich, damit KEIN -1, damit müsste ein Fehler ausgelöst werden. Aber C hat sich nie um Typen geschert, C++ gibts auch nicht ohne Grund...
Es gibt da einen Unterschied zwischen "signed char" und "unsigned char". Bei dem ersten wird das erste Bit für das Vorzeichen benutzt, bei dem anderen wird es als normales Bit benutzt. signed char kann also Werte von -128 bis +127 annehmen. Dabei ist 0x7F -> 127, 0x80 -> -128 und 0xFF -> -1 Wenn beim Anlegen einer Variablen nicht signed oder unsigned angegeben wird wird IIRC automatisch signed benutzt. -- __ _ Raymond Häb, ray.haeb@gmx.net, cologne, germany / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . . --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Raymond Haeb (ray.haeb@gmx.net) [000111 22:49]:
Wenn beim Anlegen einer Variablen nicht signed oder unsigned angegeben wird wird IIRC automatisch signed benutzt.
Hängt von der Architektur ab. Die meisten nehmen signed char, aber es gibt
auch welche, da ist unsigned char der default.
Das ist übrigens auch der Grund, warum der gcc bei Verwendung einer char
Variablen/Konstanten als Array-Index eine Warnung ausspuckt (wenn man
Warnungen eingeschaltet hat).
--
Philipp Thomas
* Jan Trippler schrieb am 09.Jan.2000:
On Sat, 08 Jan 2000, Wolfgang Weisselberg wrote:
Danke für die Belehrung. Ich programmiere auch auf einigen RISC- Rechnerarchitekturen, auf allen ist ein Byte = 8 Bit. 16 Bit sind auf allen 1 Word. Es mag sein, dass es andere gibt, aber das führt hier doch wohl ein wenig zu weit, oder?
Trotzdem sollte man sich bewußt sein, daß ein Byte nicht unbedingt und immer 8bit sein müssen.
BTW: Davon auszugehen, dass ^W immer ein Backspace darstellt, ist
Backspace ist ^H. ^W ist ein Wort zurück.
auch ziemlich architekturspezifisch gedacht ;-) Und um mit Deinen Worten zu sprechen: Nein, ich erwarte darauf keine Antwort.
Es ist schlicht und einfach ASCII. Das man ASVII benutzt ist architekturspezifisch, aber wenn man ascii benutzt, so ist ^H ein Backspace. Was mit ^W ist weiß ich jetzt nicht aus dem Kopf. Ich kann wegen defekten Monitor auch nicht nachsehen., aber nächste Woche habe ich, hoffentlich, einen neuen alten.
Jan P.S.: Du belehrst gern?
Ist doch gut. Durch Wolfgang kann man viel lernen. Was ist gegen lernen einzuwenden? Wenn Du meinst, ich habe in der Schule schon soviel gelernt und brauche das jetzt nicht mehr, so liegst Du falsch. Wenn Du meinst, der "Lehrer" erhebt sich über den "Schüler", so hast Du in der Schule die falschen Lehrer gehabt. Es ist schon interessant, daß zumindest in Deutschland, ein Lehrender/Lernender-Verhältnis immer als Machtgefälle betrachtet wird. Dem ist nicht so. Besser gesagt, es sollte nicht so sein. Die typische Lehrender/Lernender Situation ist schon die zwichen Lehrer und Schüpler. Zwichen einem Erwachsenen und einem Kind kann es nie volle Gleichberechtigung geben, daß ist klar. Stehen sich aber zwei Erwachsene gegenüber, so sieht die Sache schon anders aus. Und das ist immer häufiger der Fall.
P.P.S.: OT?
Jetzt ja, vorher nicht. Bernd -- Umsteiger von Microsoft Windows xx? Hast Du schon file://usr/doc/howto/de/DE-DOS-nach-Linux-HOWTO.txt gelesen? Auch file://usr/doc/Books/Linuxhandbuch.dvi ist zu empfehlen. |Zufallssignatur 1 --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 13-Jan-00 Bernd Brodesser wrote:
Trotzdem sollte man sich bewußt sein, daß ein Byte nicht unbedingt und immer 8bit sein müssen.
Dazu muß man erstmal schauen, welche Definition man verwendet.
In ANSI-C ist ein Byte 8 Bit breit, das wird durch den Standard eindeutig
definiert (die Diskussion gabs vor Jahren mal in C_ECHO.GER im Fidonet, und da
wurden auch die entsprechenden Stellen zitiert, AFAIK war die Definition
recht indirekt, char = 1 byte und char = 8 Bit oder so).
Im Allgemeinen Sprachgebrauch ist dem wohl inzwischen auch so. In anderen
Programmiersprachen oder Betriebssystemen kann das aber durchaus anders
betrachtet werden.
--
Erhard Schwenk
At 16:51 07.01.00 +0100, Wolfgang Weisselberg wrote:
Hi, Jan!
Trying to kill the keyboard, Jan Trippler (Jan.Trippler@t-online.de) produced 1,4K in 39 lines: ...
P.P.S.: Das Buch ist wirklich genial und noch dazu von den Erfindern der Programmiersprache C. Für alle Interessenten: Kernighan / Ritchie Programmieren in C
Du meinst "Programming in C"? (Soweit ich weiss, sprechen K&R nicht deutsch) :-)
die nicht, aber eine gewisser Schreiner und Janich, diese haben das
übersetzt, und da heisst das Teil "Programmieren in C" ;-)
ISBN 3446154973 Hanser Verlag
hab ich zufällig mal gefunden.
--
und servus
* Jan Trippler (Jan.Trippler@t-online.de) [20000107 00:41]:
Was int oder float darstellen (und wie lang diese sind) ist im Allgemeinen architekturspezifisch.
Wie lang sie sind ist architekturspezifisch, nicht aber ihre Mindestlänge. Die ist standardisiert. Und ISO C99 führt auch Ganzzahltypen mit exakt spezifierter Größe ein, wie z.B. int32_t.
P.S.: Für C heisst es wohl ANSI-Standard, nicht ISO (siehe wieder mein Lieblingsbuch ;-)
Nicht ganz ;-) Der ursprüngliche Standard war ANSI, wurde aber von ISO so
gut wie komplett übernommen. Bei C99 und C++ hat man das Kuddelmuddel, Gott
sei Dank, von vornherein vermieden. Zumindest bei C++ fand die Abstimmung
zur gleichen Zeit statt.
Philipp
--
Philipp Thomas
Hi, Raymond! Trying to kill the keyboard, Raymond Haeb (ray.haeb@gmx.net) produced 0,8K in 23 lines: [Excel]
Als Tage seit 1900. Eine Stunde ist z.B. 1/24 = 0,4166666...
Wird ja immer schlimmer mit Microsoft. Bei mir ist 1/24 ca. 0.041666... ^ -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Wolfgang Weisselberg wrote:
Hi, Raymond!
Trying to kill the keyboard, Raymond Haeb (ray.haeb@gmx.net) produced 0,8K in 23 lines:
[Excel]
Als Tage seit 1900. Eine Stunde ist z.B. 1/24 = 0,4166666...
Wird ja immer schlimmer mit Microsoft. Bei mir ist 1/24 ca. 0.041666... ^
Sorry, mein Fehler :-( Excel rechnet natürlich richtig. -- __ _ Raymond Häb, ray.haeb@gmx.net, cologne, germany / / (_)__ __ ____ __ / /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a /____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . . --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
* Bernd Brodesser wrote on Tue, Jan 04, 2000 at 22:41 +0100: [64 Bit Datum]
Nein, viel, viel länger. 292277 mal eine Millionen Jahre.
Dann haben wir also 292 Millarden Jahre Zeit, 128 Bit Maschinen einzuführen :) Das ist dann also 15 mehr Zeit, als das Universum alt ist. Dann müßte man nur den Urknallzeitpunkt genau bestimmen, damit man dann den Zeitpunkt 0 sec besser festlegen kann :) SCNR :) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Wie ich M$ so kenne werden die ab diesem Jahr damit von ihren Y2k Bugs ablenken und versuchen alle von Linux weg zu bringen. So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-)
Gibts da Mircosoft überhaupt noch - höchstens als Klopapier Monopol...
So dumm wie das klingt, aber M$ schafft es ja auch den Leuten die grafische Oberfläche als NEU zu verkaufen. Die glauben auch das jemand der Linux installieren kann, zu blöd sein soll dieses wieder von der Kiste zu entfernen. (Machen wir ja hin und wieder, aber nur um die neue Distri zu installieren :-)
Da kauft man sich ne neue Fetsplatte (nie würde ich mein linux löschen) *brrr*
so long, Holger so laaaang,
Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, Stephan Beyer wrote:
So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-)
Gibts da Mircosoft überhaupt noch - höchstens als Klopapier Monopol...
Hoffentlich nicht... die bringens fertig, daß das Klopapier alle drei Minuten abstürtzt, abreißen kannst du's auch nur wenn du noch mindestens fünf akrobatische Übungen auf einmal machst... *eg*
Die glauben auch das jemand der Linux installieren kann, zu blöd sein soll dieses wieder von der Kiste zu entfernen. (Machen wir ja hin und wieder, aber nur um die neue Distri zu installieren :-)
Da kauft man sich ne neue Fetsplatte (nie würde ich mein linux löschen) *brrr*
:-) cu flo -- Florian Groß e-mail: mailto:florian.gross@gmx.net Pinguin Nr. 42127 WWW: http://top-de.com/florian.gross/ Hinweis: Nach § 28 Abs.3 Bundesdatenschutzgesetz WIDERSPRECHE ich der Nutzung meiner Daten fuer Werbezwecke! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, 03 Jan 2000, you wrote:
Wolfgang wrote: Wie ich M$ so kenne werden die ab diesem Jahr damit von ihren Y2k Bugs ablenken und versuchen alle von Linux weg zu bringen. So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-)
So dumm wie das klingt, aber M$ schafft es ja auch den Leuten die grafische Oberfläche als NEU zu verkaufen. Die glauben auch das jemand der Linux installieren kann, zu blöd sein soll dieses wieder von der Kiste zu entfernen. (Machen wir ja hin und wieder, aber nur um die neue Distri zu installieren :-) ) Na, ja was erwartest Du von Menschen die Linux hassen und dabei versuche die Linux Myth aufzuklären oder defekte SP's raus geben. Wobei ich immer noch der Überzuegung bin das da zu 90% nur neue Icon drin sind. Hab's aber noch nicht überprüfen können mangels NT.
O.K. um dieser Mail noch etwas Inhalt zu verschaffen: 2038 geht bei Linux irgendeine Uhr/Counter oder sonstwas zuende und es funktioniert dann nicht mehr. Da wir bis in über 30Jahren bestimmt keine x86 Architektur mehr haben werden ist es genauso sinnig wie die Warnung vor dem Y5B Problem. Das heist nichts anderes als das in ca. 5 Billionen Jahren wahrscheinlich die Sonne verlischt. Also fangt schonmal an dem Untergang zu huldigen. SCNR Cu, Sven --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
At 01:09 04.01.00 +0100, Sven Hoexter wrote:
[...] O.K. um dieser Mail noch etwas Inhalt zu verschaffen: 2038 geht bei Linux irgendeine Uhr/Counter oder sonstwas zuende und es funktioniert dann nicht mehr. Da wir bis in über 30Jahren bestimmt keine x86 Architektur mehr haben
Ist das nicht auch so eine aussage, die zum Y2k problem geführt hat; ist auch so ca. 30 Jahre her ? IMHO kann man aber davon ausgehen, dass das 32bit-problem sich bis dahin wohl erledigt haben sollte, egal wie die Architektur irgendwelcher Rechner dann ausschaut. Irgendjemand sollte wohl daraus gelernt haben ? Ich muss aber auch öfter daran denken, das in einem nagelneuen PC immernoch Steckkarten laufen, die schon über 13 Jahre hinter sich haben (zumindest unter Linux). Die Entwicklung geht ja nicht immer an den richtigen stellen schnell genug voran ?!
werden ist es genauso sinnig wie die Warnung vor dem Y5B Problem. Das heist nichts anderes als das in ca. 5 Billionen Jahren wahrscheinlich die Sonne verlischt. Also fangt schonmal an dem Untergang zu huldigen.
SCNR
macht nix ;-)
dazwischen kommt aber noch das Y10k problem !
SCNRtoo
PS: wenn der Thread OT wird sagts einer ;-)
--
und servus
On Mon, Jan 03, 2000 at 03:15:11PM +0100, holgerj.keilhauer@gecits-eu.com wrote:
Wolfgang wrote:
Was passiert 2038?
Das Ende der Welt. Genauso wie am letzten Samstag.
-Wolfgang
Wie ich M$ so kenne werden die ab diesem Jahr damit von ihren Y2k Bugs ablenken und versuchen alle von Linux weg zu bringen. So nach dem Motto: "Linux ist nich Jahr 2038 sicher. Seigen sie noch heute um! Wir helfen Ihnen" :-)
Wenn schon nicht Y2K, weil das schaffen die ja nicht, dann eben Y2+38K. Ist MS eigendlich real Millenium kompatibel (2001) ???
So dumm wie das klingt, aber M$ schafft es ja auch den Leuten die grafische Oberfläche als NEU zu verkaufen. Die glauben auch das jemand der Linux installieren kann, zu blöd sein soll dieses wieder von der Kiste zu entfernen. (Machen wir ja hin und wieder, aber nur um die neue Distri zu installieren :-) )
ACK!!! -- M.f.G. Marcus Registered Linux-User : 136595 Mail : mailings-suse@gmx.de ICQ : 28762595 Bitte keine CC Danke! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Marcus! Trying to kill the keyboard, Marcus Maul (mailings-suse@gmx.de) produced 1,2K in 46 lines:
Ist MS eigendlich real Millenium kompatibel (2001) ???
Hmmm Win 1.0, 2.0, 3.0, 3.1, 3.11 : alle durch Win95 abgeloest. Win95 Verfallsdatum 1995 Win98 Verfallsdatum 1998 WinNT 4.x --> wird durch Win2000Professional abgeloest Win2000Professional, Win2000 Verfallsdatum 2000 Nein. -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Marcus Maul wrote: [...]
Wenn schon nicht Y2K, weil das schaffen die ja nicht, dann eben Y2+38K. Ist MS eigendlich real Millenium kompatibel (2001) ??? MS und kompatibel???
SCNR ;-) Heiner -- Heiner Lamprecht Philosophenweg 79 D - 72076 Tuebingen email: heiner@kijumfo.de http://www.kijumfo.de GnuKontor: http://agenda21.ggi.uni-tuebingen.de/heiner/gk/ KFLog: http://agenda21.ggi.uni-tuebingen.de/heiner/kflog/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (21)
-
a.michelic.suse＠aon.at -
accom＠joker.com -
B.Brodesser＠online-club.de -
eschwenk＠fto.de -
florian.gross＠gmx.net -
fr＠prokscha.de -
hansi.klein＠net-con.net -
heiner＠kijumfo.de -
hoexter＠orgaprog.de -
holgerj.keilhauer＠gecits-eu.com -
Jan.Trippler＠t-online.de -
kaj＠phigg.de -
mailings-suse＠gmx.de -
moritz＠hp9001.fh-bielefeld.de -
PH-Linex＠gmx.net -
pthomas＠suse.de -
ray.haeb＠gmx.net -
steffen＠dett.de -
thodi＠et-inf.fho-emden.de -
Waldemar＠zedat.fu-berlin.de -
weissel＠ph-cip.uni-koeln.de