"gets" wurde in C11 entfernt!?



  • Hallo,

    ich habe gerade bei Wikipedia die Neuerungen von C11 angeschaut (http://de.wikipedia.org/wiki/Varianten_der_Programmiersprache_C#Neuerungen_von_C11).
    Laut Wikipedia wurde die Funktion "gets" aus der Standardbibliothek entfernt.

    Weiß jemand, warum die Funktion entfernt wurde?



  • Aller wahrscheinlichkeit aus Sicherheitsgründen, denn gets() ist anfällig für Pufferüberläufe und sollte einfach nicht verwendet werden.



  • Könnte sein.

    Pufferüberläufe... das kennt wohl jeder, der in C programmiert. Aber wie sich das irgendwie "nutzen" lassen sollte, erschließt sich mir nicht. Meistens kommt bei Pufferüberläufen einfach nur Müll raus.



  • Man kann Maschinencode einschleusen, der dann ausgeführt wird.



  • gets war schon in C99 als "deprecated" gekennzeichnet und ist folgerichtig in C11 nun endgültig raus.



  • Die Frage ist doch eher warum sowas erst reinkommt.



  • Tim schrieb:

    Die Frage ist doch eher warum sowas erst reinkommt.

    Die Welt des Programmierens war jung und unschuldig.

    😉



  • Die "Frage" ist sehr leicht zu beantworten:
    Weil gets schon seit K&R Zeiten drin war und insbesondere K&R wussten, was sie tun wenn sie gets einsetzen, was man von der Mehrheit ihrer Möchtegernnachfolger nicht behaupten kann.



  • Wutz schrieb:

    gets war schon in C99 als "deprecated" gekennzeichnet und ist folgerichtig in C11 nun endgültig raus.

    C99? wer braucht schon C99? wo doch C90 schon so überflüssig war.

    Das einzig wahre ist nach wie vor C89, aka "ANSI-C". alles andere kann man in die tonne treten.



  • 🤡

    Jetzt versuchst du es aber zu sehr!



  • EinGast schrieb:

    🤡

    Jetzt versuchst du es aber zu sehr!

    ne, das ist mein bitterer ernst.

    C90 ist (fast?) inhaltsgleich mit C89, nur dass C90 von der europäischen ISO standardisiert wurde, und nicht vom amerikanischen ANSI.

    C99 bringt massenhaft unnötiges zeug, z.b. neue datentypen, die niemand braucht, und die ich auch noch nie in irgendwelchen c-quellcodes gesehen hab.



  • Wutz schrieb:

    Die "Frage" ist sehr leicht zu beantworten:
    Weil gets schon seit K&R Zeiten drin war und insbesondere K&R wussten, was sie tun wenn sie gets einsetzen, was man von der Mehrheit ihrer Möchtegernnachfolger nicht behaupten kann.

    Ui, das würde mich jetzt aber schon interessieren: Inwiefern ist gets() von K&R eingesetzt anders als gets() von ~K&R eingesetzt?



  • C11 schrieb:

    EinGast schrieb:

    🤡

    Jetzt versuchst du es aber zu sehr!

    ne, das ist mein bitterer ernst.

    C90 ist (fast?) inhaltsgleich mit C89, nur dass C90 von der europäischen ISO standardisiert wurde, und nicht vom amerikanischen ANSI.

    C99 bringt massenhaft unnötiges zeug, z.b. neue datentypen, die niemand braucht, und die ich auch noch nie in irgendwelchen c-quellcodes gesehen hab.

    Das ist nicht dein ernst oder? Was sollen das für Quellcodes gewesen sein? C99 ist heutzutage Pflicht, schon wegen den genannten Datentypen wie z.B. uint8_t, uint16_t etc.. Sobald du platformunabhängigen code oder daten festergröße brauchst sind sie unverzichtbar. In C weißt du eben nicht wie groß ein int ist. Klar kann man die auch nachbauen, aber hier sind sie standardisiert, du musst dir nicht bei jeder Platform darüber informieren wie groß int, long etc. groß sind und deine Defines anpassen.
    Außerdem bieten die neuen Standards auch endlich einen richtigen bool Typen an (stdbool.h) und eingebaute Komplexezahlen. Und das sind nicht die einzigen Gründe.



  • uint8_t schrieb:

    Das ist nicht dein ernst oder? Was sollen das für Quellcodes gewesen sein? C99 ist heutzutage Pflicht, schon wegen den genannten Datentypen wie z.B. uint8_t, uint16_t etc.. Sobald du platformunabhängigen code oder daten festergröße brauchst sind sie unverzichtbar. In C weißt du eben nicht wie groß ein int ist. Klar kann man die auch nachbauen, aber hier sind sie standardisiert, du musst dir nicht bei jeder Platform darüber informieren wie groß int, long etc. groß sind und deine Defines anpassen.
    Außerdem bieten die neuen Standards auch endlich einen richtigen bool Typen an (stdbool.h) und eingebaute Komplexezahlen. Und das sind nicht die einzigen Gründe.

    mein beitrag war wohl etwas missverständlich. natürlich weiß ich, dass die bytegröße eines datentypen in c nicht genormt ist.

    mit den "neuen Datentypen" meinte ich: _Bool , _Complex , _Imaginary

    C99 ist heutzutage Pflicht

    Da kann ich nicht zustimmen. C99 sieht beispielsweise vor, dass man das " return x; " (ersetze "x" mit einer beliebigen zahl) weglassen darf, wenn man die main-Funktion verlässt.

    Ein C99 Hello World sähe also so aus:

    #include <stdio.h>
    
    int main()
    {
         printf("Hello World\n");
    }
    

    und jetzt erzähl mir nicht, dass das standard ist. wenn du so einen code schreibst, ist man schneller weg vom fenster, als dass man "Das ist C99" sagen kann.

    Deine Aussage müsste heißen:
    "C89/C90 ist heutzutage Pflicht"

    ich denke, es hat schon seinen grund, dass viele compilerhersteller C99 nur rudimentär implementieren, oder ganz weglassen. das lässt tief blicken.



  • return x;
    

    kannst du laut aktuellem C-Standard nur weglassen solange x gleich 0 ist!

    Bei anderen Werten für x musst du es schreiben!

    Und, wenn du bei "gets" schon Panik bekommst, dann schau mal in das MSDN was da noch eventuell alles bei denen auf der Entfernen-Liste oder Ersetzen-Liste steht.
    Und Microsoft ist nicht verdächtig C99 gross zu unterstützen.



  • f.-th. schrieb:

    return x;
    

    kannst du laut aktuellem C-Standard nur weglassen solange x gleich 0 ist!

    Bei anderen Werten für x musst du es schreiben!

    wusste ich garnicht. aber das ist auch gut so. soetwas ist sehr schlechter programmierstil, den man sich garnicht angewöhnen sollte.

    ja, ich hab, als ich gesagt hab, dass manche compiler C99 nicht unterstützen, an ms gedacht.

    für mich ist C89 das einzig wahre. C90 von der ISO hat C keinen schritt weitergebracht. mag sein, dass C99 diese pseudo-genormten datentypen mitgebracht hat, aber deshalb werde ich trotzem nicht absichtlich einen schlechten code schreiben, auch wenn C99 das anscheinend erlaubt und unterstützt.



  • Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. 😕 Wie passt das zusammen?
    Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
    Ganz ehrlich, das ist Meckern auf höchsten Niveau.



  • uint8_t schrieb:

    Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. 😕 Wie passt das zusammen?
    Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
    Ganz ehrlich, das ist Meckern auf höchsten Niveau.

    1. es ist wahr, C bringt einem große Freiheit, mit der anscheinend nicht jeder umgehen kann. aber deshalb programmier ich ja in C.
    2. nun ja, du musst wissen: mit der Funktion "gets" hab ich mich eigentlich noch nie so richtig beschäftigt. ich hab immer fgets benutzt (auch wenn ich von stdin lese).
    3. Es weiß eben leider nicht jeder C-Programmierer, z.b. Anfäger könnten das nicht wissen. es ist nicht gut, wenn man erlaubt, code wegzulassen, den dann der compiler "automatisch" dazugibt.
    manchmal liest man hier im forum auch noch so sachen wie "main()" (ohne int) (das ist ein überbleibsel aus dem K&R-"Standard"). das zeigt, dass sich anscheinend nicht jeder mit allen c-standards auskennt, und nicht jeder selbst entscheiden kann, was im standard "gut" oder "schlecht" ist. außerdem kompiliert nicht jeder mit der option "-Wall".
    C99 ist ein standard für Programmierer, die schon programmieren können, und wissen, was sich "gehört" und was nicht, bzw. die wissen, wann man etwas weglassen darf und wann nicht.

    darf ich fragen, warum du hier jetzt C99 so unterstützt?

    es ist fast nicht möglich "vollständig" in C99 zu programmieren, einfach aus dem grund, weil die meisten compiler c99 nur teilweise unterstützten, manche auch garnicht: http://en.wikipedia.org/wiki/C99#Implementations
    deshalb hat sich die sache mit c99 schon seit jahren erledigt.



  • C11 schrieb:

    ich denke, es hat schon seinen grund, dass viele compilerhersteller C99 nur rudimentär implementieren, oder ganz weglassen. das lässt tief blicken.

    Von welchen sprichst du? MSVC stammt von Microsoft, was erwartest du von denen? Die wollen C++ pushen nichts anderes und meinen sie wissen was die Entwickler brauchen 🤡. Deshalb haben sie dann ab C89 aufgehört, manche Dinge wie stdint.h siehst du nur weil das für C++ sowieso rein muss.
    Dann wären da noch die anderen großen Kompiler für x86 GCC und Clang => C11, bei Intel bin ich mir gerade nicht sicher aber C99 unterstützt der auf jeden Fall. ARM Kompiler von Keil unterstützt auf jeden Fall C99 wahrscheinlich auch C11. GCC-AVR kann sowieso C99, ist glaube ich auch automatisch eingestellt. Beim PIC Kompiler genauso. Also welche wichtigen Kompiler meinst du, das wahren so ziemlich die wichtigsten auf der Welt. Wie du siehst ist dreht sich die Welt nicht um Microsoft.

    Achso schau mal auf C11, also wenn Multithreading nichts wichtiges ist, was dann? Mal ausgenommen im Bezug auf Embeddedsystemen.



  • bevors untergeht:

    C11 schrieb:

    uint8_t schrieb:

    Zwingt dich jemand diesen Stil anzuwenden? Nein. C war schon immer eine Sprache, die von einem verlangte zu wissen was man da tut. Dafür bekommst du völlige Freiheit. Es ist paradox, zum einen stellst du das als schlechten Stil hin, andererseits wunderst du dich warum gets entfernt wurde. 😕 Wie passt das zusammen?
    Außerdem bekommst du sowieso eine Warnung mit -Wall, wenn du eine non-void Funktion nur mit return; beendest (außer indem Fall von main(), was aber so gewollt ist). Ohne -Wall sollte niemand ein C Programm kompilieren, Warnungen sollte man ernst nehmen. Das sollte jeder C-Programmierer wissen.
    Ganz ehrlich, das ist Meckern auf höchsten Niveau.

    1. es ist wahr, C bringt einem große Freiheit, mit der anscheinend nicht jeder umgehen kann. aber deshalb programmier ich ja in C.
    2. nun ja, du musst wissen: mit der Funktion "gets" hab ich mich eigentlich noch nie so richtig beschäftigt. ich hab immer fgets benutzt (auch wenn ich von stdin lese).
    3. Es weiß eben leider nicht jeder C-Programmierer, z.b. Anfäger könnten das nicht wissen. es ist nicht gut, wenn man erlaubt, code wegzulassen, den dann der compiler "automatisch" dazugibt.
    manchmal liest man hier im forum auch noch so sachen wie "main()" (ohne int) (das ist ein überbleibsel aus dem K&R-"Standard"). das zeigt, dass sich anscheinend nicht jeder mit allen c-standards auskennt, und nicht jeder selbst entscheiden kann, was im standard "gut" oder "schlecht" ist. außerdem kompiliert nicht jeder mit der option "-Wall".
    C99 ist ein standard für Programmierer, die schon programmieren können, und wissen, was sich "gehört" und was nicht, bzw. die wissen, wann man etwas weglassen darf und wann nicht.

    darf ich fragen, warum du hier jetzt C99 so unterstützt?

    es ist fast nicht möglich "vollständig" in C99 zu programmieren, einfach aus dem grund, weil die meisten compiler c99 nur teilweise unterstützten, manche auch garnicht: http://en.wikipedia.org/wiki/C99#Implementations
    deshalb hat sich die sache mit c99 schon seit jahren erledigt.


Log in to reply