Re: [C, Shellscript, Perl] Abwärtskompatibilität um jeden Preis?

[Stefan Reuther]

Thomas 'PointedEars' Lahn wrote:
> Stefan Reuther wrote:
>>Ralf Döblitz wrote:
>>>Martin Vaeth <va...@mathematik.uni-wuerzburg.de> schrieb:
>>>>Der Nachteil ist, dass das nur mit ziemlich aktuellen Perl-Versionen
>>>>funktioniert.
>>>
>>>Ja, man muß dafür tatsächlich schon wenigstens Perl 5.6 haben - vom März
>>>2000. Sorry, aber du klebst da an veraltetem Müll, für den man aktiv
>>>nichts mehr entwickeln sollte, insbesondere sollte man sich von dessen
>>>Nachteilen nicht einschränken lassen.
>>
>>Millionen von C-Programmierung entwickeln nach einem Standard von 1989
>
> Nein, C99 existiert.

Genau. Und wird von C-Programmierern im Wesentlichen ignoriert.
Insbesondere deswegen, weil er von zahlreichen Compilern, darunter dem
vom sogenannten Marktführer, ebenfalls ignoriert wird.

> 2008 gab es Embedded C, und an C1X wird gearbeitet (vgl. C++11).

Auch C++11 wird noch eine Weile ignoriert werden. Ich habe gerade Code
auf einen Compiler portiert (neustes Modell!): "wir empfehlen eigentlich
C (nach dem C89/90-Standard), aber C++ haben wir jetzt auch implemen-
tiert. Naja, bis auf export, two-phase-name-lookup, noch ein paar Dinge,
und wenn du nicht ELF benutzt, klappt Inlining usw. auch nicht ganz
spezifikationskonform." Ich bezweifle, dass der in absehbarer Zeit
Lambda-Ausdrücke und Move-Konstruktoren lernt.

>>Da mach ich mir nicht den Aufwand, meine historischen Installationen zu
>>aktualisieren, nur um 'use warnings' statt '-w' schreiben zu können.
>
> Dazu ein Auszug aus perllexwarn(1):
>
> What's wrong with -w and $^W
> Although very useful, the big problem with using -w on the command
> line to enable warnings is that it is all or nothing. [...]

Bekannt. Mir ist allerdings noch kein Perl-Modul über den Weg gelaufen,
das irgendeine Warnung produziert hätte. Warum auch? Während es in C
normal ist, dass ein Compiler etwas anmeckert, was ein anderer
durchgehen lässt, ist das in Perl eher selten, da es da nur einen
Compiler gibt, und wer ein hochqualitatives Perl-Modul produziert, macht
es warnungsfrei.

>>Denn im Tagesgeschäft habe ich noch kaum eine der anderen Neuerungen der
>>neuen Perls gebraucht.
>
> Tragisch.
>
>>UTF-8-Unterstützung ist z.B. auf UTF-8-Systemen sicher gut, auf Latin-1-
>>oder gar Codepage-437-Systemen eher nutzlos.
>
> Welche *uralten* Systeme benutzt Du, die kein UTF-8, dafür aber Latin-1 oder
> CP437 sprechen?

Eins hatte ich zitiert:
This is perl, version 5.005_03 built for dos-djgpp
Damit baue ich ab und an noch Software.

Ein anderes ist mein reguläres Linux. Läuft immer noch mit Latin-1. Das
tut es schließlich schon seit Jahren - warum alles umbenennen?
Prinzipiell könnte es aber UTF-8.


Stefan

[Thomas 'PointedEars' Lahn]

Stefan Reuther wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Stefan Reuther wrote:
>>> Ralf Döblitz wrote:
>>>> Martin Vaeth <va...@mathematik.uni-wuerzburg.de> schrieb:
>>>>> Der Nachteil ist, dass das nur mit ziemlich aktuellen Perl-Versionen
>>>>> funktioniert.
>>>> Ja, man muß dafür tatsächlich schon wenigstens Perl 5.6 haben - vom
>>>> März 2000. Sorry, aber du klebst da an veraltetem Müll, für den man
>>>> aktiv nichts mehr entwickeln sollte, insbesondere sollte man sich von
>>>> dessen Nachteilen nicht einschränken lassen.
>>> Millionen von C-Programmierung entwickeln nach einem Standard von 1989
>> Nein, C99 existiert.
>
> Genau. Und wird von C-Programmierern im Wesentlichen ignoriert.
> Insbesondere deswegen, weil er von zahlreichen Compilern, darunter dem
> vom sogenannten Marktführer, ebenfalls ignoriert wird.

Unsinn. GCC und andere C-Compiler unterstützen die meisten Features von C99
[0]. Microsoft Visual C++ unterstützt einige, wenn auch in seltsamer Weise.

>> 2008 gab es Embedded C, und an C1X wird gearbeitet (vgl. C++11).
>
> Auch C++11 wird noch eine Weile ignoriert werden. Ich habe gerade Code
> auf einen Compiler portiert (neustes Modell!): "wir empfehlen eigentlich
> C (nach dem C89/90-Standard), aber C++ haben wir jetzt auch implemen-
> tiert. Naja, bis auf export, two-phase-name-lookup, noch ein paar Dinge,
> und wenn du nicht ELF benutzt, klappt Inlining usw. auch nicht ganz
> spezifikationskonform." Ich bezweifle, dass der in absehbarer Zeit
> Lambda-Ausdrücke und Move-Konstruktoren lernt.

Zu belegen war von Dir Deine Behauptung, C habe sich seit 1989 nicht
weiterentwickelt und Programmierer würde sich daher davon einschränken
lassen. Da Du keinen *stichhaltigen* Beleg dafür gebracht hast, es aber
gegenteilige Belege gibt (neben den genannten viele Forderungen an M$, C99
*sauber* zu implementieren, da man andernfalls einen *anderen* Compiler
nehmen *müsse* [1]), brauchen wir über Deine Behauptung nicht weiter zu
diskutieren.

>>> Denn im Tagesgeschäft habe ich noch kaum eine der anderen Neuerungen der
>>> neuen Perls gebraucht.
>>
>> Tragisch.
>>
>>> UTF-8-Unterstützung ist z.B. auf UTF-8-Systemen sicher gut, auf Latin-1-
>>> oder gar Codepage-437-Systemen eher nutzlos.
>>
>> Welche *uralten* Systeme benutzt Du, die kein UTF-8, dafür aber Latin-1
>> oder CP437 sprechen?
>
> Eins hatte ich zitiert:
> This is perl, version 5.005_03 built for dos-djgpp
> Damit baue ich ab und an noch Software.

Tragisch. Du bist Dir aber im Klaren darüber, dass es dafür weder eine
Notwendigkeit noch Support gibt [2], also auch *keine* *Sicherheitspatches*
mehr?

> Ein anderes ist mein reguläres Linux. Läuft immer noch mit Latin-1. Das
> tut es schließlich schon seit Jahren - warum alles umbenennen?

Hör bitte auf, FUD zu verbreiten. Nichts *muss* *umbenannt* werden.

> Prinzipiell könnte es aber UTF-8.

Immerhin.

_________
[0] <http://en.wikipedia.org/wiki/C99#Implementations>
[1] <http://blogs.msdn.com/b/vcblog/archive/2007/11/05/iso-c-standard-
update.aspx>
[2] <http://www.effectiveperlprogramming.com/blog/1055>
<http://learn.perl.org/faq/perlfaq1.html#Which-version-of-Perl-should-I-
use->

--
PointedEars

Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[Stefan Reuther]

Thomas 'PointedEars' Lahn wrote:
> Stefan Reuther wrote:
>>>>Ralf Döblitz wrote:
>>>>
>>>>>Martin Vaeth <va...@mathematik.uni-wuerzburg.de> schrieb:
>>>>>
>>>>>>Der Nachteil ist, dass das nur mit ziemlich aktuellen Perl-Versionen
>>>>>>funktioniert.
>>>>>
>>>>>Ja, man muß dafür tatsächlich schon wenigstens Perl 5.6 haben - vom
>>>>>März 2000. Sorry, aber du klebst da an veraltetem Müll, für den man
>>>>>aktiv nichts mehr entwickeln sollte, insbesondere sollte man sich von
>>>>>dessen Nachteilen nicht einschränken lassen.
>>>>
>>>>Millionen von C-Programmierung entwickeln nach einem Standard von 1989
>>>
>>>Nein, C99 existiert.
>>
>>Genau. Und wird von C-Programmierern im Wesentlichen ignoriert.
>>Insbesondere deswegen, weil er von zahlreichen Compilern, darunter dem
>>vom sogenannten Marktführer, ebenfalls ignoriert wird.
>
> Unsinn. GCC und andere C-Compiler unterstützen die meisten Features von C99
> [0]. Microsoft Visual C++ unterstützt einige, wenn auch in seltsamer Weise.

Ich sehe dort eine Tabelle mit 4x "full" und 13x "mostly/partial".

Mir ist noch kein Programm über den Weg gelaufen, das wirklich
C99-Features nutzt (es sei denn, du zählst ein Programm, was
"//"-Kommentare nutzt, dazu). Und das ist auch nicht verwunderlich, wenn
jedem Compiler was anderes fehlt, man also für diese Compiler die
jeweilige C90-Version sowieso vorhalten müsste.

>>>2008 gab es Embedded C, und an C1X wird gearbeitet (vgl. C++11).
>>
>>Auch C++11 wird noch eine Weile ignoriert werden. Ich habe gerade Code
>>auf einen Compiler portiert (neustes Modell!): "wir empfehlen eigentlich
>>C (nach dem C89/90-Standard), aber C++ haben wir jetzt auch implemen-
>>tiert. Naja, bis auf export, two-phase-name-lookup, noch ein paar Dinge,
>>und wenn du nicht ELF benutzt, klappt Inlining usw. auch nicht ganz
>>spezifikationskonform." Ich bezweifle, dass der in absehbarer Zeit
>>Lambda-Ausdrücke und Move-Konstruktoren lernt.
>
> Zu belegen war von Dir Deine Behauptung, C habe sich seit 1989 nicht
> weiterentwickelt

Das habe ich nicht behauptet.

> und Programmierer würde sich daher davon einschränken lassen.

Der Beweis sind die Megabytes Open-Source-Software, die hier auf meiner
Platte liegen, und die C99 ignorieren. Bestenfalls werden GNU-
Erweiterungen genutzt, die ja zum Teil in C99 aufgegangen sind.

Ein weiterer Beweis sind die Megabytes Closed-Source-Software, mit denen
ich sonst noch so zu tun habe.

Wo sind die Megabytes C99-Software? Also so richtig mit <tgmath.h> usw.?

>>>>UTF-8-Unterstützung ist z.B. auf UTF-8-Systemen sicher gut, auf Latin-1-
>>>>oder gar Codepage-437-Systemen eher nutzlos.
>>>
>>>Welche *uralten* Systeme benutzt Du, die kein UTF-8, dafür aber Latin-1
>>>oder CP437 sprechen?
>>
>>Eins hatte ich zitiert:
>> This is perl, version 5.005_03 built for dos-djgpp
>>Damit baue ich ab und an noch Software.
>
> Tragisch. Du bist Dir aber im Klaren darüber, dass es dafür weder eine
> Notwendigkeit noch Support gibt [2], also auch *keine* *Sicherheitspatches*
> mehr?

Sicherheitspatches für einen Sprachinterpreter, der Code ausführt, den
ich selbst geschrieben habe, und der Daten verarbeitet, die ich selbst
auf einem Dateisystem ohne Zugriffsrechte abgelegt habe, sind mir völlig
egal.

>>Ein anderes ist mein reguläres Linux. Läuft immer noch mit Latin-1. Das
>>tut es schließlich schon seit Jahren - warum alles umbenennen?
>
> Hör bitte auf, FUD zu verbreiten. Nichts *muss* *umbenannt* werden.

Dateien mit Latin-1-Namen sind nicht mehr sinnvoll zugreifbar, wenn das
System von UTF-8-Codierung ausgeht, müssen also umbenannt werden. Es sei
denn, man schafft es, das im Filesystemtreiber zu drehen, dann bringt
man aber auch weiterhin nur Latin-1-Zeichen in Dateinamen unter und
damit kann man's auch gleich lassen.


Stefan

[Thomas 'PointedEars' Lahn]

Doch, hast Du. Vollständiges Zitat:

| Millionen von C-Programmierung entwickeln nach einem Standard von 1989

| und lassen sich "von dessen Nachteilen einschränken".

>> und Programmierer würde sich daher davon einschränken lassen.
>
> Der Beweis sind die Megabytes Open-Source-Software, die hier auf meiner
> Platte liegen, und die C99 ignorieren. Bestenfalls werden GNU-
> Erweiterungen genutzt, die ja zum Teil in C99 aufgegangen sind.
>
> Ein weiterer Beweis sind die Megabytes Closed-Source-Software, mit denen
> ich sonst noch so zu tun habe.
>
> Wo sind die Megabytes C99-Software? Also so richtig mit <tgmath.h> usw.?

Megabytes Open-Source-Software implizieren _nicht_ "Millionen von C-
Programmierung" (wobei wohl "Millionen C-Programmierer" gemeint waren).

>>>>>UTF-8-Unterstützung ist z.B. auf UTF-8-Systemen sicher gut, auf
>>>>>Latin-1- oder gar Codepage-437-Systemen eher nutzlos.
>>>>
>>>>Welche *uralten* Systeme benutzt Du, die kein UTF-8, dafür aber Latin-1
>>>>oder CP437 sprechen?
>>>
>>>Eins hatte ich zitiert:
>>> This is perl, version 5.005_03 built for dos-djgpp
>>>Damit baue ich ab und an noch Software.
>>
>> Tragisch. Du bist Dir aber im Klaren darüber, dass es dafür weder eine
>> Notwendigkeit noch Support gibt [2], also auch *keine*
>> *Sicherheitspatches* mehr?
>
> Sicherheitspatches für einen Sprachinterpreter, der Code ausführt, den
> ich selbst geschrieben habe, und der Daten verarbeitet, die ich selbst
> auf einem Dateisystem ohne Zugriffsrechte abgelegt habe, sind mir völlig
> egal.

So weit, so schlecht.

>>>Ein anderes ist mein reguläres Linux. Läuft immer noch mit Latin-1. Das
>>>tut es schließlich schon seit Jahren - warum alles umbenennen?
>>
>> Hör bitte auf, FUD zu verbreiten. Nichts *muss* *umbenannt* werden.
>
> Dateien mit Latin-1-Namen sind nicht mehr sinnvoll zugreifbar, wenn das
> System von UTF-8-Codierung ausgeht, müssen also umbenannt werden.

Unsinn. Das eine oder andere GUI (z. B. KDE) mag ja Probleme damit haben,
ansonsten gibt es aber kein Zugriffsproblem.

> Es sei denn, man schafft es, das im Filesystemtreiber zu drehen,

IOW: Man ändert die Mount-Optionen. OMG, die Welt geht unter!

> dann bringt man aber auch weiterhin nur Latin-1-Zeichen in Dateinamen
> unter und damit kann man's auch gleich lassen.

UTF-8 bzw. Unicode ist nicht nur für Dateinamen gut. Deine Logik ist
(wieder einmal) fehlerhaft.

[Vinzent Hoefler]

Thomas 'PointedEars' Lahn wrote:

> Stefan Reuther wrote:
>
>>> Zu belegen war von Dir Deine Behauptung, C habe sich seit 1989 nicht
>>> weiterentwickelt
>>
>> Das habe ich nicht behauptet.
>
> Doch, hast Du. Vollständiges Zitat:
>
> | Millionen von C-Programmierung entwickeln nach einem Standard von 1989
> | und lassen sich "von dessen Nachteilen einschränken".

Hat er nicht behauptet. Und das, was Stefan da schreibt, ist bis auf das
"Programmierung" vs. "Programmierer" (was wohl gemeint war) auch vollkommen
korrekt.


Vinzent.

--
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

[Georg Bauhaus]

On 28.09.11 08:30, Vinzent Hoefler wrote:

>> | Millionen von C-Programmierung entwickeln nach einem Standard von 1989
>> | und lassen sich "von dessen Nachteilen einschränken".
>
> Hat er nicht behauptet. Und das, was Stefan da schreibt, ist bis auf das
> "Programmierung" vs. "Programmierer" (was wohl gemeint war) auch vollkommen
> korrekt.

Millionen von Programmierern, die nicht wissen, wie sich ihre
Programme verhalten werden, obschon C99 eine überschaubare Zahl
potentieller Änderungen bei weitestgehender Kompatibilität mit
sich bringt?

Irgendwo ist da etwas nicht so, wie es sein sollte.


-Georg

[Vinzent Hoefler]

Georg Bauhaus wrote:

> On 28.09.11 08:30, Vinzent Hoefler wrote:
>
>>> | Millionen von C-Programmierung entwickeln nach einem Standard von 1989
>>> | und lassen sich "von dessen Nachteilen einschränken".
>>
>> Hat er nicht behauptet. Und das, was Stefan da schreibt, ist bis auf das
>> "Programmierung" vs. "Programmierer" (was wohl gemeint war) auch vollkommen
>> korrekt.
>
> Millionen von Programmierern, die nicht wissen, wie sich ihre
> Programme verhalten werden, obschon C99 eine überschaubare Zahl
> potentieller Änderungen bei weitestgehender Kompatibilität mit
> sich bringt?

Nein. Millionen von Programmierern, deren Compiler und/oder Coding-Standards
es verbieten, etwas anderes als C89/90 zu verwenden. Zumindest, solange sie -
oder der Kunde - Wert auf Portabilität legt.

> Irgendwo ist da etwas nicht so, wie es sein sollte.

|MISRA Rule 1: All code shall conform to ISO 9899 Standard C, with no extensions
|permitted.
|
|The standard referred to in this rule is defined in the ISO9899:1990 document
|incorporating ISO/IEC Technical Corrigendum 1:1995.

Das hat sich mit der Version MISRA-C2 von 2004 noch nicht geändert und erst die
kommende MISRA-C Version wird dies "korrigieren" und C99 referenzieren.

Und gerade im µC-Bereich gibt es durchaus eine ganze Menge Compiler, die
tatsächlich nicht viel mehr als C90 und ein paar compilerspezifische (ergo:
unportable) Erweiterungen kennen. Nicht alles basiert auf gcc oder gar einer
aktuellen Version davon.

[Georg Bauhaus]

On 28.09.11 14:04, Vinzent Hoefler wrote:

>> Irgendwo ist da etwas nicht so, wie es sein sollte.

Der Grund für die Sorge um C89 vs C99 dürfte nicht allein
MISRA-begründet sein, wenn Millionen sich scheuen. So reich
ist Gimpel Software dann doch auch nicht, als dass sie
millionenfache Lizensierung von MISRA-C-Tools belegen könnten, oder?
Auch schätze ich, dass nicht alle diese Millionen Programmierer
die Skepsis einiger WG-Mitarbeiter gegenüber C99 teilen. Man
müsste wohl (a) was lernen, was neu ist und (b) jedenfalls Fragen
beantworten können, die den Wechsel betreffen. Scheu ist da
opportun.

> |MISRA Rule 1: All code shall conform to ISO 9899 Standard C, with no extensions
> |permitted.
> |
> |The standard referred to in this rule is defined in the ISO9899:1990 document
> |incorporating ISO/IEC Technical Corrigendum 1:1995.

Schließt das

X:\> type future.h
typedef usigned int uint16_t;

X:\>

aus? (Mal abgesehen davon, dass man gescheiterweise nicht mit
den bedeutungsarmen Standardtypen ohne typedef arbeiten darf.)

[Stefan Reuther]

Georg Bauhaus wrote:
> On 28.09.11 14:04, Vinzent Hoefler wrote:
>>>Irgendwo ist da etwas nicht so, wie es sein sollte.
>
> Der Grund für die Sorge um C89 vs C99 dürfte nicht allein
> MISRA-begründet sein, wenn Millionen sich scheuen. So reich
> ist Gimpel Software dann doch auch nicht, als dass sie
> millionenfache Lizensierung von MISRA-C-Tools belegen könnten, oder?
> Auch schätze ich, dass nicht alle diese Millionen Programmierer
> die Skepsis einiger WG-Mitarbeiter gegenüber C99 teilen. Man
> müsste wohl (a) was lernen, was neu ist und (b) jedenfalls Fragen
> beantworten können, die den Wechsel betreffen. Scheu ist da
> opportun.

Der Grund ist nicht MISRA und auch nicht Scheu vor Neuem. Der Grund ist,
dass es nur wenige Compiler gibt, die C99 voll unterstützen. Wer Code
schreiben will, der praktisch funktioniert und den er an einen großen
Kundenkreis verkaufen kann, wird also C90 nehmen. Dafür, dass man Code
schreibt, dessen C99-Konformität man sodann mit Papier und Bleistift
nachweist, zahlen jedenfalls die wenigsten Kunden.


Stefan

[Georg Bauhaus]

On 28.09.11 18:45, Stefan Reuther wrote:

> Der Grund ist nicht MISRA und auch nicht Scheu vor Neuem. Der Grund ist,
> dass es nur wenige Compiler gibt, die C99 voll unterstützen.

Und warum gibt es im Jahr 2011 nur wenige compiler, die C99 voll
unterstützen?

Warum das Gezögere? Der Markt, in dem C89 als gut genug propagiert
wird, gilt als sehr groß. Er beschäftigt wohl nicht Millionen von
Programmierern, aber eine ganze Menge bezahlter C-Programierer
in Projekten, von denen die Hersteller der compiler leben. Also warum?
Ich glaube einfach, dass Bequemlichkeit, die vermeintlich
Einfachheit von C89 im Vergleich und das Fehlen einer zu C99
passenden Auflage von K&R die Sprache C89 zementieren helfen.
Es ist immerhin billig, in negierender Weise auf die "viel
wichtigeren"(TM) Projektergebnisse zurückzuverweisen. Die
anderen Millionen Programmierer machen das immerhin auch. Man wird
also dafür nicht gefeuert.

[Stefan Reuther]

Georg Bauhaus wrote:
> On 28.09.11 18:45, Stefan Reuther wrote:
>> Der Grund ist nicht MISRA und auch nicht Scheu vor Neuem. Der Grund ist,
>> dass es nur wenige Compiler gibt, die C99 voll unterstützen.
>
> Und warum gibt es im Jahr 2011 nur wenige compiler, die C99 voll
> unterstützen?

Vermutung: C99 ist nicht gut genug. VLAs sind zum Beispiel viel Aufwand
im Compiler, aber wirklich sinnvoll anwendbar sind sie selten.
Insbesondere auf Embedded-Systemen mit sowas wie 256 Byte Stack.
Daher implementieren die Compilerleute eben die einfachen und populären
Teile (z.B. '//'-Kommentare).

C++ hingegen ist ein immens größerer Aufwand, bringt aber auch größeren
Nutzen. Man braucht halt im Wesentlichen den kompletten
C++-Sprachumfang, um sowas wie std::vector zu bauen.

C# ist auch so eine Sprache, die für mich "nicht gut genug" ist, wenn
man Java als Vergleich danebenlegt. Da steckt nur halt eine Multi-
Millionen-Firma dahinter. Diese Firma hat sich gegen C99 entschieden.
Die Welt könnte anders aussehen, wenn MS C99 gepusht hätte, wenn also
z.B. die neuen Vista-APIs C99 benutzen würden.


Stefan