C: unsigned long als binärzahl ausgeben

Zitat von buechsengustel

ein unsigned long ist ja 32 bit.

Nicht unbedingt. Das ist plattformabhängig.

Zitat

also zb unisgned long x = 12;
ist als 00000000000000000000000000001100 gespeichert. (ich hoff das ist soweit richtig?)

Auch nicht unbedingt. C trifft IIRC keine Annahmen über die interne Repräsentation seiner Datentypen, insbesondere zum Beispiel hat ein NULL-Pointer auf manchen Architekturen nicht "0....0" als Bitmuster, obwohl das Makro NULL tatsächlich einfach zur Integralzahl "0" expandiert. Es liegt in der Verantwortung des Compilers, ohne dein Wissen die notwendigen typabhängigen Umrechnungen zu veranlassen.

Zitat

wie krieg ich jetzt mein programm dazu, mir genau das, die 32 bit, auszugeben?

Hab dir auf die schnelle was gebastelt:

/* bitify.c */


#include <errno.h>
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>


void
bitify(unsigned long n, unsigned minwidth)
{
    unsigned long mask = 1;
    unsigned width = 1;
    unsigned long tmp = n;
    while (tmp / 2 || width < minwidth) {
        mask *= 2;
        width++;
        tmp /= 2;
    }
    while (mask) {
        if (putchar(((n & mask) == mask) ? '1' : '0') == EOF) {
           fprintf(stderr, "bitify: error writing to stdout\n");
           exit(-1);
        }
        mask /= 2;
    }
}


int
main(int argc, char *argv[]) {
    unsigned int n;
    if (argc != 2) {
        fprintf(stderr, "Usage: bitify NUMBER\n");
        exit(-1);
    }
    n = strtoul(argv[1], NULL, 10);
    if (n == ULONG_MAX && errno == ERANGE) {
        fprintf(stderr, "bitify: argument should be an "
            "unsigned long in decimal representation.\n");
        exit(-1);
    }
    bitify(n, 32);
    if (putchar('\n') == EOF) {
      fprintf(stderr, "bitify: error writing to stdout\n");
      exit(-1);
    }
    return 0;
}

Viel einfacher dürfte es tatsächlich nicht gehen.

Zitat

ich mein mit
(void) printf ("x ist: %lu", x);
krieg ich die zahl im zehnersystem ausgegeben, also 12
mit
(void) printf ("x ist: %lo", x);
als oktalzahl, also 14

Ja. Abgesehen davon, dass es Pfusch ist, printf nach (void) zu casten, und davon, dass du den Zeilenvorschub vergessen hast.

Zitat

jetzt gibt's denn da wirklich nichts, womit ich die zahl im binärsystem kriege? und am liebsten eben die ganzen 32 bit, so wie das ding gespeichert ist.

Nicht mit Hilfe von printf und seinen Geschwistern - ausser, deine Entwicklungsumgebung/dein Runtime unterstützt irgendeine nicht standardkonforme Erweiterung. Wenn du eine solche verwenden würdest, hättest du aber auch keine Portabilität mehr, also versuch's besser gar nicht erst.

.

Zitat von Georg Kraml

Nicht unbedingt. Das ist plattformabhängig.

Nicht unbedingt. Eigentlich ist es Compilerabhängig.

Zitat

Abgesehen davon, dass es Pfusch ist, printf nach (void) zu casten

Er kann nichts dafür, das ist in uns in Sysprog so eingetrichtert worden. Damit soll ausgedrückt werden, dass der Programmierer weiß, dass die Funktion einen Wert zurückliefert und er explizit drauf furzt. Ich würd sowas nie hinschreiben (außer in Sysprog natürlich).

Zitat von hal

Nicht unbedingt. Eigentlich ist es Compilerabhängig.

Und der Compiler ist kein Teil der Plattform?

Zitat

Er kann nichts dafür, das ist in uns in Sysprog so eingetrichtert worden. Damit soll ausgedrückt werden, dass der Programmierer weiß, dass die Funktion einen Wert zurückliefert und er explizit drauf furzt.

Alles klar... nur sollte man halt strenggenommen nicht drauf furzen. Rückgabewerte, mit genau zwei Ausnahmen, gehören überprüft. Aber gut, ihr vom Mediaclan überprüft ja nicht einmal den von malloc.

.

Zitat von Georg Kraml

Und der Compiler ist kein Teil der Plattform?

Wie ich in Übersetzerbau vor kurzem gelernt habe ist ein Compiler nur ein Übersetzer von einer Sprache in die andere, und damit ist er eigentlich nur ein besseres sed, grep oder X11. Nur von RMS ist mir bekannt, dass er dieses für Teil einer "Plattform" hält.

Zitat

Alles klar... nur sollte man halt strenggenommen nicht drauf furzen. Rückgabewerte, mit genau zwei Ausnahmen, gehören überprüft.

Wie sinnvoll ist das in diesem Fall? Wenn der output nicht funktioniert ist es doch sch***egal, tut das Programm halt nix.

Zitat von hal

Wie ich in Übersetzerbau vor kurzem gelernt habe ist ein Compiler nur ein Übersetzer von einer Sprache in die andere, und damit ist er eigentlich nur ein besseres sed, grep oder X11. Nur von RMS ist mir bekannt, dass er dieses für Teil einer "Plattform" hält.

Cool, wieder was gelernt. War bisher der Ansicht, "Plattform" wäre nicht wirklich strikt definiert und könnte ohne Weiteres auch den Compiler und insbesondere seine Runtimes mitumfassen.

Zitat

Wie sinnvoll ist das in diesem Fall? Wenn der output nicht funktioniert ist es doch sch***egal, tut das Programm halt nix.

Wäre meiner Meinung nach halt cool für den Anwender, zu wissen, warum es nix tut, besonders bei Vorliegen irgendwelcher Redirects. Ausserdem bekomme ich einfach nicht gerne die Schuld für Seltsamkeiten in die Schuhe geschoben, für die ich nichts kann.

.

Zitat von Georg Kraml

Cool, wieder was gelernt. War bisher der Ansicht, "Plattform" wäre nicht wirklich strikt definiert und könnte ohne Weiteres auch den Compiler und insbesondere seine Runtimes mitumfassen.

Tja, dann versuch nicht, eine defintion zu machen
Wird wohl jeder seine eigene davon haben... Runtimes würd ich zB schon dazuzählen.

Zitat

Wäre meiner Meinung nach halt cool für den Anwender, zu wissen, warum es nix tut, besonders bei Vorliegen irgendwelcher Redirects. Ausserdem bekomme ich einfach nicht gerne die Schuld für Seltsamkeiten in die Schuhe geschoben, für die ich nichts kann.

Du bist sowieso an allem Schuld, also mach dir nicht die Mühe es zu verschleiern und es dem User in die Schuhe zu schieben (UID: der Benutzer ist niemals schuld!)

Zitat von buechsengustel

edit: außerdem, ich denk, das macht schon sinn, manchmal auf (void) zu casten; wenn ich was hab
if ( machIrgendwas() liefert einen fehler)
(void) gibFehlermeldungAus();

weil sonst werd ich da ja nie fertig. jaja, ich weiß, das hab ich aus dem sysprog buch abgeschaut, bin ich aber spitzfindig, aber hier wird eben genau das diskutiert.

hää ... das check ich jetzt nicht
-> ich hab noch niemals jemanden eine funktion nach void casten gesehen und ich wüsste auch nicht für was das gut sein sollte, außer um den code länger und unübersichtlicher zu machen!

an den bösen wolf:
warum einfach wenns auch kompliziert geht ?!!

void print_32bit(long val)
{
   int shift = 32;


   while (shift)
      printf("%d", (val>>--shift)&1);
}

mfg marX

Zitat von Georg Kraml

Nicht unbedingt. Das ist plattformabhängig.

Es kann aber mehr als einen Compiler geben, die sich nicht unbedingt über solche Sachen einig sein müssen. Von daher isses ungenau, von Plattformabhängigkeit zu schreiben.

Zitat von Georg Kraml

C trifft IIRC keine Annahmen über die interne Repräsentation seiner Datentypen, ...

Doch, es nimmt an, dass ganze Zahlen binär repräsentiert werden und dass alle Werte verschieden sind.

Zitat von buechsengustel

zb überprüfst du gewissenhaft bei einer funktion den rückgabewert darauf, ob ein fehler aufgetreten ist. ist ein fehler aufgetreten, gibst du mit fprintf(stderr, "blabla"); eine fehlermeldung aus.
nun ist es aber so, dass auch dieses fprintf einen rückgabewert liefert. allerdings ist es kaum sinnvoll, ihn zu überprüfen und im fehlerfall irgendwas zu machen, weil wenn das schreiben auf stderr nicht funktioniert, was will man dann noch groß machen.

nun predigens in sysprog eben, dass man da dann auf (void) casten soll, um zu zeigen, dass man sich bewusst ist, dass da ein rückgabewert ist, man ihn aber absichtlich ignoriert.

na ja...ich programmiere nun schon seit ca. 6 jahren c/c++ und hatte noch nie das bedürfniss (durch einen void-cast) zu zeigen, dass ich einen rückgabewert absichtlich ignoriere

da würde ich es sogar gerne zu einer diskussion mit dem prof. kommen lassen

mfg marX

Naja, wenn du den gcc im hyper-paranoiden -ansi -pedantic-modus startest (was verlangt wird), ist das notwendig. Bei der Sysprog VO-Prüfung stand in einer Angabe sowas wie "Nachdem Maxi Sysprog jetzt geschafft hat und sich supercool fühlt, hat er bei seinem neuen Programm alle warnings abgedreht. Jetzt funktioniert allerdings gar nix mehr, streichen Sie die Fehler an, die er gemacht hat:" und dann ham sie erwartet, dass man so Dinge wie "verwendet 25 statt 25.0 wenn ein float erwartet wird" anstreicht. Das Hauptziel von Sysprog ist, dem Studenten defensive Programmierung anzugewöhnen, inwieweit das erfolgreich ist ist natürlich eine andere Sache.

na ja ein saubrer programmierstil ist ja schon wichtig ... ich bin z.B. bei der klammernsetzung etwas übergenau (weil ich durch zu wenig klammern schon einige dumme fehler bekam), aber bei einer floatvariable den zahlenwert explizit als solchen zu deklarieren (durch '.0') macht eigentlich auch keinen sinn oder ?!!
-> man behindert sich halt nur mehr selbst ....

mfg marX

Zitat von marX

an den bösen wolf:
warum einfach wenns auch kompliziert geht ?!!

Ich bilde mir ein, dass meine Lösung halt ein bisschen allgemeiner und portabler ist.

Abgesehen davon funktioniert deine Lösung einfach nicht. Hint: der erste Fehler ist in Zeile 1. Und für das "(val>>--shift)&1" gehörst du offen gesagt grün und blau gedroschen, sofern das nicht ironisch gemeint war.

.

Zitat von marX

na ja...ich programmiere nun schon seit ca. 6 jahren c/c++ und hatte noch nie das bedürfniss (durch einen void-cast) zu zeigen, dass ich einen rückgabewert absichtlich ignoriere

Das macht nichts, du brauchst dich nicht dafür zu genieren - es ist nie zu spät, etwas doch noch ordentlich lernen zu wollen.

OK, bösartige Scherze beiseite: Es ist schön für dich, dass deine bisherigen Programme in so barmherzigen Umgebungen gelaufen sind, und dir deine Nachlässigkeit bisher nicht auf den Kopf gefallen ist. In der Real World [tm] wirst du dir mit der Attitüde freilich früher oder später die Nase blutig hauen. Fallbeispiel aus einer bekannten österreichischen Telekommunikationsfirma, anno ca. 2000:

• Ein SMS-Zustellprogramm gibt Statusreports auf stdout aus.
• Der stdout des Zustellprogrammes wird - für die Abrechnung - allerdings in eine Datei auf der Festplatte einer Sun redirected.
• Die Festplatte ist voll.
• Da der verantwortliche Programmierer sich zu gut dazu war, den Rückgabewert des fraglichen printf zu testen, gibt es keine Fehlermeldungen, sondern eine halbe Nacht an SMS-Traffic verschwindet kommentarlos und unabrechenbar im Nirwana. (Unabrechenbar, weil die verlorenen Daten zwar rekonstruierbar gewesen wären, diese Rekonstruktion aber mehr gekostet als nachher wieder eingebracht hätte.)
• Der Projektleiter ist blöderweise Informatiker, hat also Sysprog gemacht und weiss daher, dass das Ignorieren des Rückgabewerts von printf eine nicht nur provokante, sondern dank Sysprog auch unentschuldbare Verantwortungslosigkeit ist. Der Programmierer fliegt raus.

Zitat

da würde ich es sogar gerne zu einer diskussion mit dem prof. kommen lassen

Schick mir aber rechtzeitig ein Mail, damit ich mir vorher noch Cola und Popcorn holen kann.

.

Zitat von Georg Kraml

• Ein SMS-Zustellprogramm gibt Statusreports auf stdout aus.
• Der stdout des Zustellprogrammes wird - für die Abrechnung - allerdings in eine Datei auf der Festplatte einer Sun redirected.

Alleine dieses Systemkonzept ist ja schon ein Wahnsinn Passiert der SMS-Versand seriell, oder gibts ab und zu ein bisschen Chaos in diesem logfile? Wär ein daemon á la syslog vom Programmierer zu viel verlangt gewesen?

Ah ja, bitte keine Beleidigungen Georg, das ist nicht notwendig.

Zitat von hal

Alleine dieses Systemkonzept ist ja schon ein Wahnsinn

Jo, absolut.

Zitat

Passiert der SMS-Versand seriell, oder gibts ab und zu ein bisschen Chaos in diesem logfile?

Da war IIRC so eine Art Vorserialisierung vorgeschaltet. Das Logfile hat auch immer sauber ausgesehen. War übrigens zeitweise sehr unterhaltsame Lektüre. Har har har.

Zitat

Wär ein daemon á la syslog vom Programmierer zu viel verlangt gewesen?

Sagen wir so: du liegst sicher richtig mit der Implikation, dass die printf-Panne nicht die einzige Fehlleistung in diesem Projekt gewesen sein dürfte. Aber sie war eben die ausschlaggebende Fehlleistung, die unmittelbar viel Geld gekostet und den Kollegen den Job gekostet hat.

Wird wohl damit zu tun gehabt haben, dass man sich in Sachen Überprüfung von Rückgabewerten - im Gegensatz zu architektonischen Fragen - nicht auf "Geschmackssache" rausreden kann. Aber ich versteh ja genau gar nichts von HRM; vielleicht war das alles damals auch ganz anders.

Zitat

Ah ja, bitte keine Beleidigungen Georg, das ist nicht notwendig.

OK, kein M-Wort in diesem Post.

.

Zitat von Georg Kraml

Ich bilde mir ein, dass meine Lösung halt ein bisschen allgemeiner und portabler ist.

stimmt, aber ich glaube halt, dass ein c-anfänger mit einer kurzen (einfachen) lösung besser bedient ist!

Zitat von Georg Kraml

Abgesehen davon funktioniert deine Lösung einfach nicht. Hint: der erste Fehler ist in Zeile 1.

irrtum sie funktioniert perfekt

Zitat von Georg Kraml

Und für das "(val>>--shift)&1" gehörst du offen gesagt grün und blau gedroschen, sofern das nicht ironisch gemeint war.

na ja, du kannst dein glück gerne mal versuchen ... wird für dich aber nicht lustig enden
nein im ernst: wieso denn?? ok man hätte noch klammern setzen können, die reihenfolge ist aber nach posix geregelt und somit klar!

wegen dem beschriebenen fehler:
ok das ist natürlich blöd, jedoch ist hier auch der admin schuld wenn er nicht regelmäßig checkt, ob noch genügend platz auf der platte ist ....
man kann als programmierer nie alle eventualitäten vorhersehen ...

mfg marX

Zitat von marX

ok man hätte noch klammern setzen können, die reihenfolge ist aber nach posix geregelt und somit klar!

lt. posix sind auch die variablennamen AAA, aaa, Aaa, aAa, aaA, AAa, AaA, aAA innerhalb einer Funktion ganz ok und geregelt...

Zitat

man kann als programmierer nie alle eventualitäten vorhersehen ...

naja, aber wenn einem der rückgabewert schon so aufs aug gedrückt wird... du musst ja nicht den festplattenplatz oder sowas kontrollieren.