4. kopie eines char[] zurückgeben

kopie eines char[] zurückgeben

  • N

    supertux schrieb:

    net schrieb:

    naja, und du meinst das kriegste nicht zum abstürzen?

    die einzige Möglichkeit, die ich da sehe, ist wenn str kein 0-terminierendes Strings, da sollte man strncpy lieber benutzen, am sonsten fällt mir keine andere Form, diesen Code zum Absturz zu bringen.

    na so z.b:

    const char *s = (const char*)-1;
    copy(s);

    btw: das mit dem _try/_except hätte auch dabei geholfen 😃

    0
  • S

    net schrieb:

    btw: das mit dem _try/_except hätte auch dabei geholfen 😃

    das nervt!

    0
  • N

    Shade Of Mine schrieb:

    net schrieb:

    btw: das mit dem _try/_except hätte auch dabei geholfen 😃

    das nervt!

    weil's kein ansi-c ist?

    0
  • S

    net schrieb:

    weil's kein ansi-c ist?

    das nur zum teil.

    aber was haben in solch einer funktion trys verloren?
    nichts. die funktion wie sie supertux geschrieben hat kann nicht fehlschlagen.

    warum? weil ein ungueltiger string eine verletzung des vertrags ist, den der caller mit dem callee eingeht. dh, dann schlaegt der caller fehl.

    es ist bloedsinn hier _try zu verwenden und das in einem ansi C forum vorzuschlagen ist noch groesserer bloedsinn.

    es hat hier naemlich nicht nur keinen sinn sondern ist auch noch ot.

    0
  • N

    Shade Of Mine schrieb:

    es ist bloedsinn hier _try zu verwenden und das in einem ansi C forum vorzuschlagen ist noch groesserer bloedsinn.

    sagte ich doch schon, dass das nicht portabel ist. blödsinn isses aber auf keinen fall. auf systemen, die das haben sollte man es auch einsetzen. windoofs z.b. hätte 80% weniger blue screens wenn alle treiber-coder _try/_except benutzen würden

    0
  • S

    net schrieb:

    blödsinn isses aber auf keinen fall. auf systemen, die das haben sollte man es auch einsetzen. windoofs z.b. hätte 80% weniger blue screens wenn alle treiber-coder _try/_except benutzen würden

    Doch, es _ist_ bloedsinn.

    du kannst ja nicht jedes statement in einen _try block packen, das waere krank.

    die funktion ist sicher und kann nicht fehlschlagen, was willst du da noch checken? noch ein assert(str) am anfang rein und das ding ist perfekt.

    wenn ja nun ein invalider zeiger reinkommt, dann ist das ein problem des callee und der muss das _try machen wenn er zu dumm ist einen gueltigen zeiger zu liefern.

    oder willst du wirklich bei jedem zeiger zugriff ein _try machen? am besten gleich einen pointer wrapper schreiben der die zugriffe alle checkt...

    tja, aber wozu nimmt man dann C?

    besser als ein _try ist einfach mal valgrind oder der gleichen. oder einfach dem compiler sagen er soll die speicherzugriffe checken... alles 1000mal besser als _try.

    dein windows argument zieht uebrigens ueberhaupt nicht, weil es

    1. unter Win NT quasi keine bluescreens gibt
    2. linux, bsd etc. auch in C geschrieben sind und auch quasi keine kernel panics haben
    3. bluescreens meistens durch schlechte treiber entstehen und da kann man checken was man will, denn aus performance gruenden laufen die meisten treiber im kernel space und da koennen sie alles kaputt machen. da kannst du _try so oft machen wie du lustig bist, es hilft nix

    eine kernel panic ist uebrigens auch kein absturz des systems sondern ein abgefangener fehler der als zu kritisch betrachtet wird als dass der kernel sicher weiterarbeiten kann. der fehler _ist_ also abgefangen worden... nur hilft es hier halt nichts. da nuetzt dir dein _try auch herzlich wenig.

    ist uebrigens in c und c++ ein grundsatz: trust the programmer. wenn du das nicht tust, dann solltest du dir ueberlegen ob eine andere sprache besser waere, denn C ist sicher nicht geeignet alle moeglichen fehler abzufangen. es ist aber auch nicht noetig, denn wenn der callee sagt: das ist ein buffer mit 100 byte dann ist das auch ein buffer mit 100 byte und ich schreibe die ohne bedenke hinein. mein code ist ja korrekt, wozu also unnoetig checken?

    wenn der callee sich nicht sicher ist, kann er ja checken (wobei auch das fraglich ist, weil er dann ja sich selbst nicht vertrauen wuerde...)

    ach da mag ich Debugger die dann bei einem fehler gleich in den code breaken. das ist sinnvoller als alles andere...

    0
  • N

    Shade Of Mine schrieb:

    du kannst ja nicht jedes statement in einen _try block packen, das waere krank.

    das will ja auch keiner

    Shade Of Mine schrieb:

    die funktion ist sicher und kann nicht fehlschlagen, was willst du da noch checken? noch ein assert(str) am anfang rein und das ding ist perfekt.

    z.b. wenn man mit pointern rechnet kann schnell was schiefgehen so dass eine ungültige adresse entsteht, die diese funktion zum abkacken bringt. wieviele 'asserts' willst du einbauen um alles abzufangen?

    Shade Of Mine schrieb:

    ...am besten gleich einen pointer wrapper schreiben der die zugriffe alle checkt...

    unter win gibt es dafür ausser '_try' noch 'IsBadReadPtr(), IsBadWritePtr()' usw. guckst du: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/isbadreadptr.asp

    Shade Of Mine schrieb:

    besser als ein _try ist einfach mal valgrind oder der gleichen. oder einfach dem compiler sagen er soll die speicherzugriffe checken... alles 1000mal besser als _try.

    nee, es sind nur einfach andere möglichkeiten fehler zu finden. kein ersatz für '_try'

    Shade Of Mine schrieb:

    dein windows argument zieht uebrigens ueberhaupt nicht, weil es
    ...
    3) bluescreens meistens durch schlechte treiber entstehen und da kann man checken was man will, denn aus performance gruenden laufen die meisten treiber im kernel space und da koennen sie alles kaputt machen. da kannst du _try so oft machen wie du lustig bist, es hilft nix

    muss auch nicht ziehen. ist tatsache. im win-kernel ist exception-handling eingebaut. der prozessor löst einen interrupt aus bei unerlaubten speicherzugriffen, division durch 0 usw. wenn man's nicht benutzt fängt ein default exception-handler den fehler ab und zeigt einen schicken bluescreen. der performance-verlust ist minimal: es wird einmalig ein 'exception-record' in eine liste eingetragen, das war's auch schon.

    edit: ausserdem laufen treiber nicht aus performance-gründen im kernel, sondern weil sie dort die nötige infrastruktur haben

    0
  • P

    supertux schrieb:

    Laut meiner man pages steht CONFORMING TO: SVID 3, BSD 4.3. strndup(), strdupa(), and strndupa() are GNU extensions.

    Ich weiß ehrlich nicht, ob strdup den Standard gehört, scheint aber nicht so sein.

    Interessant. strdup() ist eine der aeltesten C Funktionen, die's ueberhaupt gibt, sie war schon bei den Compilern der 80er Jahre immer dabei. Deswegen gibt es sie wohl auch immer noch so gut wie ueberall, auch wenn sie nicht im Standard ist (hab grad nachgeguckt; und Tatsache, sie ist nicht im Standard ... komisch).

    0
  • S

    net schrieb:

    das will ja auch keiner

    dann sag nicht, dass du hier _try verwenden wuerdest

    Shade Of Mine schrieb:

    z.b. wenn man mit pointern rechnet kann schnell was schiefgehen so dass eine ungültige adresse entsteht, die diese funktion zum abkacken bringt. wieviele 'asserts' willst du einbauen um alles abzufangen?

    Schnell? Bloedsinn.
    assert macht man fuer 0 adressen. probleme mit wilden zeigern kann man verdammt gut umgehen, sowas kommt idr nur sehr selten vor. viel schlimmer sind nicht gechekte 0 zeiger.

    aber das aendert nichts daran, dass die funktion korrekt ist und immer korrekt laufen wird. sie hat es nicht noetig sich selbst sinnlos zu testen.

    Shade Of Mine schrieb:

    unter win gibt es dafür ausser '_try' noch 'IsBadReadPtr(), IsBadWritePtr()' usw. guckst du: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/memory/base/isbadreadptr.asp

    *gaehn*
    was willst du mir damit sagen?
    dass man auch etwas anderes als try verwenden kann? ja aber _wozu_? die funktion ist garantiert fehlerfrei, sieht ja ein blinder.

    nee, es sind nur einfach andere möglichkeiten fehler zu finden. kein ersatz für '_try'

    aber der trick ist, dass du diese sachen automatisch bekommst und sie somit deinem try ueberlegen sind. weil du sie nebenbei laufen laesst und alles ist paletti. man muss keine 10mio mal try schreiben weil man mit zeigern arbeitet.

    in C arbeitet man naemlich viel mit zeigern, da kann man nicht jedesmal 100 mal checken ob alles OK ist. dann sollte man naemlich eine managed sprache nehmen, weil sonst ist der sinn c zu verwenden ja dahin...

    muss auch nicht ziehen. ist tatsache. im win-kernel ist exception-handling eingebaut. der prozessor löst einen interrupt aus bei unerlaubten speicherzugriffen, division durch 0 usw. wenn man's nicht benutzt fängt ein default exception-handler den fehler ab und zeigt einen schicken bluescreen. der performance-verlust ist minimal: es wird einmalig ein 'exception-record' in eine liste eingetragen, das war's auch schon.

    eben. da ist nicht in jeder strcpy, strlen, fread etc. funktion eine unmenge an trys sondern ein globales handling.

    edit: ausserdem laufen treiber nicht aus performance-gründen im kernel, sondern weil sie dort die nötige infrastruktur haben

    klar, ein switch von usermode in kernelmode ist ja gratis. da hast du natuerlich vollkommen recht.

    0
  • N

    Shade Of Mine schrieb:

    in C arbeitet man naemlich viel mit zeigern, da kann man nicht jedesmal 100 mal checken ob alles OK ist. dann sollte man naemlich eine managed sprache nehmen, weil sonst ist der sinn c zu verwenden ja dahin...

    nee, das haste falsch verstanden. man soll keine 'trys' bei jedem popeligen speicherzugriff verwenden. aber z.b. in (kernel/treiber)funktionen, die von aussen mit pointern versorgt werden (was man nicht unter kontrolle hat) kann ein 'try' lebenswichtig für's ganze systen sein. z.b. hatte die erste win-nt4 version (ohne servicepacks) einen üblen bug: winapi-aufrufe mit zufälligen parametern konnten die kiste abschmiessen. an einigen stellen hat m$ dann 'trys' benutzt um das abzustellen

    Shade Of Mine schrieb:

    muss auch nicht ziehen. ist tatsache. im win-kernel ist exception-handling eingebaut. der prozessor löst einen interrupt aus bei unerlaubten speicherzugriffen, division durch 0 usw. wenn man's nicht benutzt fängt ein default exception-handler den fehler ab und zeigt einen schicken bluescreen. der performance-verlust ist minimal: es wird einmalig ein 'exception-record' in eine liste eingetragen, das war's auch schon.

    eben. da ist nicht in jeder strcpy, strlen, fread etc. funktion eine unmenge an trys sondern ein globales handling.

    ja, und dieses eingebaute 'globale handling' kann man sich zunutze machen, indem man von '_try/_except' gebrauch macht.

    Shade Of Mine schrieb:

    klar, ein switch von usermode in kernelmode ist ja gratis. da hast du natuerlich vollkommen recht.

    wo hab' ich das geschrieben 😕

    0
  • S

    net schrieb:

    nee, das haste falsch verstanden. man soll keine 'trys' bei jedem popeligen speicherzugriff verwenden.

    exakt. aber darum geht es hier. es geht hier um diese winzig kleine funktion und sonst garnichts.

    du bist also OT

    0
  • G

    net schrieb:

    groovemaster schrieb:

    Power Off schrieb:

    Oder ganz einfach strdup() benutzen, dafuer ist es naemlich da

    Was soll das sein? Standard C?

    sowas: http://www.koders.com/c/fidF16762E3999BA95A0B5D87AECB0525BA67CEE45A.aspx

    War mir schon klar. Wollte nur mal wissen, woher er das hat, weil strdup eben nicht zum Standard gehört. Hat sich ja mittlerweile geklärt.

    Power Off schrieb:

    hab grad nachgeguckt; und Tatsache, sie ist nicht im Standard

    Imo auch gut so. Zu schnell kann man vergessen, dass ausserhalb noch ein free notwendig ist. Und gerade bei solchen Sachen bleibt dann Abstraktion nicht mehr unabhängig von der Implementation, was das eigentlich traurige daran ist.

    0
  • S

    net schrieb:

    na so z.b:

    const char *s = (const char*)-1;
    copy(s);

    btw: das mit dem _try/_except hätte auch dabei geholfen 😃

    dein Beispiel ist krank, warum soll ich mich darum kümmern, wenn Programmier Müll in die Funktionen übergeben? Es ist nicht meine Schuld, warum soll ich mich darum kümmern, dass man auch sowas eingeben kann?

    ist uebrigens in c und c++ ein grundsatz: trust the programmer. wenn du das nicht tust, dann solltest du dir ueberlegen ob eine andere sprache besser waere

    das stimme ich zu.

    0
  • N

    supertux schrieb:

    dein Beispiel ist krank, warum soll ich mich darum kümmern, wenn Programmier Müll in die Funktionen übergeben? Es ist nicht meine Schuld, warum soll ich mich darum kümmern, dass man auch sowas eingeben kann?

    jemand sagte einmal "wenn architekten häuser so konstruieren würden, wie programmierer ihre software entwickeln, dann wär' schon die halbe welt zusammengestürzt". naja, kann mir schon vorstellen wie er drauf kommt, wenn manche so denken wie du... 😞

    0
  • M

    LOL. Ich will dich mal sehen, wie du alle möglichen Fehler abfängst.

    0
  • S

    net schrieb:

    supertux schrieb:

    dein Beispiel ist krank, warum soll ich mich darum kümmern, wenn Programmier Müll in die Funktionen übergeben? Es ist nicht meine Schuld, warum soll ich mich darum kümmern, dass man auch sowas eingeben kann?

    jemand sagte einmal "wenn architekten häuser so konstruieren würden, wie programmierer ihre software entwickeln, dann wär' schon die halbe welt zusammengestürzt". naja, kann mir schon vorstellen wie er drauf kommt, wenn manche so denken wie du... 😞

    Dann müsste man nach jedem Befehl die Fehler abfangen, sogar die Fehlerabfang-Prozeduren sollte da man abfangen, usw. Es ist nicht, wie ich denke, sondern was das bringt.

    0
Anmelden zum Antworten