gcc bug (diesmal wirklich): "shift count is negative"

Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer 
noch auftritt? Meiner ist die letzte Version die das offizielle ARM ppa 
ausspuckt, auf der ARM Webseite gibts aber schon neuere zum direkten 
Download.

Bernd K. schrieb:
> kompiliert es ohne Fehler!

Naja, ohne Fehler compiliert es auch so schon, und das Ergebnis ist 
korrekt. Es gibt ja keinen Fehler, sondern eine Warnung.

Selbst die Warnung ist für sich genommen nicht falsch: der shift count 
an dieser Stelle wäre ja tatsächlich negativ – nur dass die Stelle eben 
aufgrund der äußeren Umstände garantiert nicht erreicht wird (was sich 
ja auch im generierten Code reflektiert). Insofern ist die Warnung 
verwirrend, aber eher eine Unschönheit denn ein tatsächlicher Bug.

Aber wenn du es reportest, vielleicht ließe es sich ja einfach beheben, 
und jemand erbarmt sich. Hab's gerade auf einem (AVR-)GCC 9.1.0 
probiert, gleiches Verhalten. Reporte es daher gegen diese Version, das 
erhöht die Chance, dass es jemanden bei GCC interessiert. ;-)

1

$ avr-gcc -Os -mmcu=atmega1281 -Wall -Wextra -S foo.c

2

foo.c: In function ‘foo’:

3

foo.c:6:18: warning: left shift count is negative [-Wshift-count-negative]

4

    6 |         return x << shift;

5

      |                ~~^~~~~~~~

6

$ avr-gcc -v

7

Using built-in specs.

8

Reading specs from /usr/local/lib/gcc/avr/9.1.0/device-specs/specs-avr2

9

COLLECT_GCC=avr-gcc

10

COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/9.1.0/lto-wrapper

11

Target: avr

12

Configured with: ./configure --target=avr --disable-libssp --with-gmp=/usr/local --enable-languages='c c++' --with-isl=/usr/local --enable-nls --prefix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=x86_64-portbld-freebsd11.2

13

Thread model: single

14

gcc version 9.1.0 (GCC)

Das tritt auch auf nem 9.2er x86 gcc auf. Der passende Check für die 
Warnung wird wohl einfach keine branches und keine nicht-konstanten 
shift offsets prüfen. Ist jetzt wirklich nichts weltbewegendes.

Das ganze gibt nur nen Fehler weil du die Warnung per Compileroption zum 
Fehler machst.

Bernd K. schrieb:
> Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer
> noch auftritt?

Nein, aber es ist nicht auf den ARM-GCC beschränkt. Mit MinGW32 5.1.0 
läßt sich die Meldung reproduzieren.

Jörg W. schrieb:
> Es gibt ja keinen Fehler, sondern eine Warnung.

Oh, da ist mir mein allgegenwärtiges -Werror auf die Füße gefallen. Aber 
auch eine Warnung ist natürlich unschön.

Zum Glück wirft der Optimizer auch dann das if und den unzutreffenden 
Branch wenn shift nicht als const deklariert ist solange der Ausdruck 6 
- 13 zur Kompilezeit konstant ist (was bei mir der Fall ist weil das aus 
Makroauflösungen mit literalen Konstanten kommt).

Hab mir jetzt sowas gebaut:

1

#define SHIFT_LEFT(x, y)       ((y) > 0 ? (x) << (y) : (x) >> -(y))

2

#define SHIFT_RIGHT(x, y)      ((y) > 0 ? (x) >> (y) : (x) << -(y))

das schluckt er überall ohne zu meckern.

Wenn ich mal mehr Zeit hab mach ich nen Bugreport.

c-hater schrieb:
> Die Begründung, warum das ein Bug sein muss, ist überaus simpel: Es gibt
> keine Möglichkeit, die Warnung zu verhindern, ohne den KORREKTEN Code
> substantiell zu ändern.

Doch, natürlich gibt es die.

Aber das wissen C-Hasser natürlich nicht, müssen sie auch nicht.

Bernd K. schrieb:
> Hab mir jetzt sowas gebaut:#define SHIFT_LEFT(x, y)       ((y) > 0 ? (x)
> << (y) : (x) >> -(y))
> #define SHIFT_RIGHT(x, y)      ((y) > 0 ? (x) >> (y) : (x) << -(y))
> das schluckt er überall ohne zu meckern.

Hast Du sonst nichts zu tun?

Johann J. schrieb:
> Bernd K. schrieb:
>> Hab mir jetzt sowas gebaut:#define SHIFT_LEFT(x, y)       ((y) > 0 ? (x)
>> << (y) : (x) >> -(y))
>> #define SHIFT_RIGHT(x, y)      ((y) > 0 ? (x) >> (y) : (x) << -(y))
>> das schluckt er überall ohne zu meckern.
>
> Hast Du sonst nichts zu tun?

Das Freihalten der Buildkonsole von jeglichen Warnungen gehört zu meinen 
Top-Prioritäten. Die Komplexität mehrere Projekte gleichzeitig die ich 
jederzeit (oder auf Zuruf kurzfristig wieder) vollständig überblicken 
muß erlaubt nicht das allergeringste Einfallstor für mögliches Chaos, 
ich dulde nicht das geringste inhaltsleere Rauschen das zusätzlich in 
meinem Informationszugang hineindrängt und ihn verstopft! Das Forum hier 
ist übrigens eine der wenigen Ausnahmen von dieser Regel die ich 
erlaube!

Mit den beiden obigen Zeilen wird der Code aus Post #1 auch klarer und 
kleiner da ich jetzt nicht mehr für jeden shift umständlich 2 if-Zweige 
hinschreiben muß. Meine Haupsorge bei irgendeinem Kompromiss wär die 
Optimierbarkeit gewesen, aber wie sich gezeigt hat hat die 
Constant-Propagation genug Macht um das auch so zu schaffen.

nicht"Gast" schrieb:
> Das ist kein Bug

In obigem Code ist die Shiftcount garantiert nicht negativ.

c-hater schrieb:
> Jörg W. schrieb:
>
>> Doch, natürlich gibt es die.
>
> Zeigen!

Warnung -Wshift-count-negative, option zum ausschalten folglich 
-Wno-shift-count-negative. Ich kompiliere meine Programme immer mit 
-Werror, einzelne Warnungen ausschalten mach ich nur wenn wirklich nötig 
wegen so einem Compiler Bug. Das finde ich auch sehr ärgerlich, wenn es 
mal nötig wird. Bei späteren Versionen sollte man das dann nicht 
vergessen, wieder zu entfernen, wenn es mal behoben wurde.

nicht"Gast" schrieb:
> Das ist kein Bug

Doch, die betroffene stelle kann nie erreicht werden, wenn kein 
undefinierter Code ausgeführt werden kann, ist es in Ordnung. Es ist 
egal, ob der Compiler den Code weglasst, oder dort sonst was hinpflanzt, 
aber falsch ist es nicht. Das er warnt ist aber klar falsch. Ein false 
positive.

nicht"Gast" schrieb:
> Das ist kein Bug
>
> Aus dem freien Draft:
> [...]

Andere Baustelle. Ich hab nämlich gar keine negativen shifts, das kann 
ich sogar zur Compilezeit schon beweisen, der Compiler ist aber leider 
anderer Meinung.

A. K. schrieb:
> nicht"Gast" schrieb:
>> Das ist kein Bug
>
> In obigem Code ist die Shiftcount garantiert nicht negativ.


Doch, ist er.

Bernd K. schrieb:
> src/cap_measure.c:24:18: error: left shift count is negative
> [-Werror=shift-count-negative]
>          return x << shift;

Die Zeile wird zwar niemals ausgeführt, aber der Code ist trotzdem UB.

Oliver

Oliver S. schrieb:
> Die Zeile wird zwar niemals ausgeführt, aber der Code ist trotzdem UB.

Dieser Logik folgend wäre auch
   return p ? *p : 0;
für p==NULL undefiniert.

Nope: Erst die ausgeführte Operation "negative shift" ist undefiniert. 
Ebenso wie es erst der Zugriff über einen NULL Pointer ist. Werden sie 
nicht ausgeführt, ist nichts undefiniert.

A. K. schrieb:
> In obigem Code ist die Shiftcount garantiert nicht negativ.

Durch das Entfernen des "const" ist es aber nur noch eine Optimierung, 
den Codepfad nicht zu betrachten.

Mir sieht das so aus, als ob der gcc da auf sein eigenes Hütchenspiel 
hereinfällt: An einer Stelle weiß er, dass die Zahl negativ ist, an der 
anderen nicht.

leo schrieb:
> Wenn ein Leftshift ploetzlich in
> die andere Richtung losgeht, ist schon voher was faul.

Nein, der geht nicht "plötzlich" in die andere Richtung. Die Shiftweite 
in meinem Beispiel war schon immer eine literale Konstante irgendwo mit 
zwei simplen #define festgenagelt und war immer positiv und zur 
Kompilezeit bekannt.

Jetzt hab ich den Code an einigen Stellen erweitert um später auch 
negative shifts dort haben zu können weil sich ein neuer Anwendungsfall 
ergab. Die Absicht ist daß der Optimizer je nachdem in welchem Projekt 
ich den Code da oben¹ verwende beim Kompilieren entweder nur den if oder 
nur den else Zweig stehen lässt.

Wenn ich das if/else durch dem ternären Operator ersetze klappts und er 
meckert nicht, obwohl die Logik beim Prüfen der Plausibilität die selbe 
sein müsste.

---
¹ Der Code ist Teil eines makrobasierten Templates das ich sehr häufig 
brauche, mehrere Varianten der selben Funktion werden zur Kompilezeit 
generiert mit unterschiedlichen konstanten Parametern und 
unterschiedlichen Datentypen. Zum Beispiel ein Moving Average der Länge 
n von int16_t Werten. Oder uint8_t oder double. Oder ein Gauss-Filter 
für int32_t. Solche Sachen lass ich dann mit einer einzigen Zeile Code 
generieren wo immer ich schnell mal einen brauche.

Daniel A. schrieb:
> Ich kompiliere meine Programme immer mit -Werror,

Was durchaus vernünftig ist, machen wir in der Firma auch so.

> einzelne Warnungen
> ausschalten mach ich nur wenn wirklich nötig

Schalt sie doch für genau die eine Funktion aus.

leo schrieb:
> Du schreibst also nicht sauberen Code sondern sauber obfuscated Code

Deine Aussage ergibt keinen Sinn. Du weißt nicht welchem Zweck mein Code 
dienen soll, das oben gepostete ist ein Minimalbeispiel das den selben 
Fehler demonstriert über den ich bei mir gestolpert bin, den echten Code 
kennst Du gar nicht, deshalb kannst Du auch nicht darüber urteilen.

Und jetzt unterlasse bitte diese an mich gerichteten niederen Attacken, 
hier gehts um eine klar abgegrenzte technische Fragestellung bezüglich 
des Compilers, nicht um meinen Kodierstil, der stand gar nicht zur 
Debatte! Also Bitte!

mh schrieb:
> Ich würd irre werden, wenn ich beim entwickeln Fehler der Formerror:
> unused parameter 'foo' [-Werror=unused-parameter]
> oder ähnlich belommen würde.

Einige harmlose oder bedeutungslose Warnungen wie diese werden global 
deaktiviert. Alles andere verdient es unverzüglich behandelt zu werden, 
das stört auch nicht bei der Arbeit, nach einiger Zeit spürt mans schon 
beim Schreiben, noch lange bevor einem der Compiler auf die Finger 
klopft.

mh schrieb:
>>> Ich kompiliere meine Programme immer mit -Werror,
>> Was durchaus vernünftig ist, machen wir in der Firma auch so.
>
> Wirklich immer?

Ja, immer.

Eine Ausnahme wäre maximal, dass man es während einer größeren 
Entwicklung vielleicht temporär abschaltet, dann typischerweise auf 
einem Branch, und es würde vor dem Merge back wieder aktiviert.

Committet wird bei DVCSen sowieso laufend, ggf. halt (lokaler Branch) 
auch mal "unfertiger" Code. Einfach, damit man bei Bedarf einen 
"Checkpoint" hat, zu dem man wieder zurück kehren kann.

Daniel A. schrieb:
> nicht"Gast" schrieb:
>> Das ist kein Bug
>
> Doch, die betroffene stelle kann nie erreicht werden, wenn kein
> undefinierter Code ausgeführt werden kann, ist es in Ordnung.

Das kann der Compiler nicht immer 100% genau erkennen. Dazu ist schon 
etwas Code-Analyse notwendig. Deshalb ist es auch nur eine Warnung und 
kein Fehler. Wenn du per -Werror dann einen Fehler draus machst, ist das 
nicht die Schuld des Compilers.
In dem Fall ist es ja noch relativ einfach, aber das kann man beliebig 
verkomplizieren. Generell immer kann der Compiler das nicht 
sicherstellen.
Ggf hängt das übrigens auch noch von den Optimierungs-Einstellungen ab. 
Da er bei hohen Optimierungsstufen mehr Code-Analyse machen muss, 
erkennt er dann manche Fälle etwas präziser.

> Es ist egal, ob der Compiler den Code weglasst, oder dort sonst was
> hinpflanzt, aber falsch ist es nicht. Das er warnt ist aber klar falsch.

Er warnt, weil es falsch sein könnte.

Wenn ich sowas schreibe wie:
[C]
int ret;
if (ret = myFunction())
[C]

warnt er auch, weil er glaubt, das müsse bestimmt keine Zuweisung, 
sondern ein Vergleich sein.

Generell bin ich auch dafür, alle Warnungen aus dem Code zu entfernen. 
Nur warnt gcc heute an so vielen Stellen, wo eigentlich kein Problem 
ist, dass es schon langsam nervt, dauernd im Code irgendwas umschreiben 
oder hinzufügen zu müssen, nicht weil dadurch der Code besser würde, 
sondern nur um die an einigen Stellen eigentlich unnötigen Warnungen 
wegzubekommen.

Bernd K. schrieb:
> Hat jemand einen aktuellen gcc und kann bestätigen daß das dort immer
> noch auftritt? Meiner ist die letzte Version die das offizielle ARM ppa
> ausspuckt, auf der ARM Webseite gibts aber schon neuere zum direkten
> Download.

Ich habe den avr-gcc 9.2.0 zur Verfügung. In der Arduino IDE getestet 
bringt es nur eine "left shift" Warnung.

1

void setup(void) {

2

  Serial.begin(250000);

3

}

4

5

void loop(void) {

6

  for (int i = -10; i < 11; i++)

7

  {

8

    Serial.println( foo(i) );

9

  }

10

}

11

12

int foo(int x) {

13

  const int shift = 6 - 13;

14

  if (shift < 0) {

15

    return x >> -shift;

16

  } else {

17

    return x << shift;

18

  }

19

}

Ausgabe:

1

Sketch wird kompiliert...

2

"C:\\avrToolchain\\avr-gcc-9.2.0-mingw64-selfmade/bin/avr-g++" -c -g -Os -Wall -Wextra -std=gnu++17 -fno-exceptions -fpermissive -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mmcu=atmega2560 -DF_CPU=16000000L -DARDUINO=10809 -DARDUINO_AVR_MEGA2560 -DARDUINO_ARCH_AVR -fno-sized-deallocation -fconcepts "-IC:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\cores\\arduino" "-IC:\\Program Files (x86)\\Arduino\\hardware\\arduino\\avr\\variants\\mega" "C:\\Users\\devil\\AppData\\Local\\Temp\\arduino_build_977774\\sketch\\sketch_aug22b.ino.cpp" -o "C:\\Users\\devil\\AppData\\Local\\Temp\\arduino_build_977774\\sketch\\sketch_aug22b.ino.cpp.o"

3

C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino: In function 'int foo(int)':

4

C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino:24:21: warning: left shift count is negative [-Wshift-count-negative]

5

   24 |         return x << shift;

6

      |                     ^~~~~

7

Compiling libraries...

Veit D. schrieb:
> In der Arduino IDE getestet bringt es nur eine "left shift" Warnung.

Um genau diese geht es ja.

Bernd K. schrieb:
> leo schrieb:
>> Wenn ein Leftshift ploetzlich in
>> die andere Richtung losgeht, ist schon voher was faul.
>
> Nein, der geht nicht "plötzlich" in die andere Richtung. Die Shiftweite
> in meinem Beispiel war schon immer eine literale Konstante irgendwo mit
> zwei simplen #define festgenagelt und war immer positiv und zur
> Kompilezeit bekannt.

Ja, dann solltest Du das auch mit constexpr ausdrücken.

1

int foo(int x) {

2

  constexpr int shift = 6 - 13;

3

  if constexpr(shift < 0) {

4

    return x >> -shift;

5

  } else {

6

    return x << shift;

7

  }

8

}

Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist 
korrekterweise weg.

Rolf M. schrieb:
> Wenn ich sowas schreibe wie:
> [C]
> int ret;
> if (ret = myFunction())
> [C]
>
> warnt er auch, weil er glaubt, das müsse bestimmt keine Zuweisung,
> sondern ein Vergleich sein.

Das ist auch grenzwertiger Stil. Ich würde das nicht so hinschreiben. 
IMHO ist das ein grober Designfehler der Sprache daß eine Zuweisung als 
Ausdruck ausgewertet werden kann, ich finde es gut daß der Compiler da 
warnt, denn man verliert nichts wenn man generell auf dieses "Feature" 
verzichtet.

Wilhelm M. schrieb:
> Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist
> korrekterweise weg.

Es ging aber eben nicht um C++, damit erübrigt sich deine Lösung.

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Allerdings: das geht nur mit einem C++-Compiler, un die Warnung ist
>> korrekterweise weg.
>
> Es ging aber eben nicht um C++, damit erübrigt sich deine Lösung.

Sehe ich nicht so: es ist wieder ein Grund über die Verwendung von C 
nachzudenken. Vor allem, weil der Umstieg so einfach ist. Für den TO 
könnte constexpr in genau dieser Übersetzungseinheit ein Anreiz sein.

Wilhelm M. schrieb:
> es ist wieder ein Grund über die Verwendung von C nachzudenken

Diese Evangelisiererei nervt einfach.

Ihr „C++-Evangelisten“ solltet nicht davon ausgehen, dass C++ nur das 
unerkannte Mauerblümchen sei, welches niemand kennt, weshalb ihr es 
unbedingt allen nahelegen müsst. Diese Auffassung ist schlicht falsch: 
jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine 
Vorteile, seine Nachteile. Nichtsdestotrotz können sich (von ein paar 
eigentständigen Hobbyprojekten vielleicht mal abgesehen) die meisten 
dieser Programmierer einfach nicht aussuchen, die Sprache zu wechseln – 
der Wechsel ist eben nicht so einfach, wie du suggerierst. Außerdem: 
da, wo man sich die Sprache aussuchen kann, gewinnen oft andere, Python 
beispielsweise.

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> es ist wieder ein Grund über die Verwendung von C nachzudenken
>
> Diese Evangelisiererei nervt einfach.

Ich denke, ein Vorschlag in eine andere Richtung ist noch keine 
Evangelisiererei. Ok, es ist vielleicht ein Vorschlag der Dir nicht 
passt.

> Ihr „C++-Evangelisten“ solltet nicht davon ausgehen, dass C++ nur das
> unerkannte Mauerblümchen sei, welches niemand kennt, weshalb ihr es
> unbedingt allen nahelegen müsst.

Da liegst Du aber komplett daneben. Allerdings ist dieses Forum in der 
Tat ein Ort, wo viele Personen einfach nicht aus ihrer C-Blase hinaus 
schauen wollen und können.

> Diese Auffassung ist schlicht falsch:
> jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine
> Vorteile, seine Nachteile.

Das wage ich stark zu bezweifeln. Und das behaupte ich auch nicht von 
mir.

> Nichtsdestotrotz können sich (von ein paar
> eigentständigen Hobbyprojekten vielleicht mal abgesehen) die meisten
> dieser Programmierer einfach nicht aussuchen, die Sprache zu wechseln –
> der Wechsel ist eben nicht so einfach, wie du suggerierst.

Auch da bin ich anderer Meinung.

Wilhelm M. schrieb:

> Da liegst Du aber komplett daneben. Allerdings ist dieses Forum in der
> Tat ein Ort, wo viele Personen einfach nicht aus ihrer C-Blase hinaus
> schauen wollen und können.

Das ist die Sicht derer, die nicht aus ihrer C++-Blase hinaus schauen 
wollen und können – um mit deinen Worten zu kontern.

>> Diese Auffassung ist schlicht falsch:
>> jeder halbwegs erfahrende C-Programmierer kennt C++, kennt seine
>> Vorteile, seine Nachteile.
>
> Das wage ich stark zu bezweifeln.

Dann bezweifle es halt. Was genau hilft dir das jetzt?

> Auch da bin ich anderer Meinung.

Kannst du ja sein. Meine Meinung resultiert einfach aus Erfahrung.

Ich hätte persönlich überhaupt kein Problem, unsere Firmware hier in der 
Firma in C++ zu verfassen, aber wir müssen unsere Brötchen irgendwie 
verdienen. Was glaubst du, wer von unseren Kunden unseren Arbeitsaufwand 
bezahlen möchte für einen Umbau von C auf C++? Das würde nur dann jemand 
bezahlen, wenn sich daraus unmittelbar Probleme lösen ließen, die in C 
nicht (mit vertretbarem Aufwand) lösbar wären. Aber so riesig ist der 
Vorteil von C++ wiederum eben dann doch nicht. Es ist manches netter und 
bequemer und schöner, gar keine Frage, aber in dem Bereich, in dem wir 
arbeiten, gibt es kaum was, was nicht in C auch gänge, ohne dass man 
dadurch nun unbillige Härte in Kauf nehmen müsste.

Und überall dort, wo es nicht (unbedingt) in Firmware sein muss, 
dominiert schlicht und ergreifend Python. Da quält sich keiner mehr mit 
C oder C++ ab. Die Millisekunde an Performance interessiert dann sowieso 
keinen, und die Time-to-Market ist damit um Welten besser als in den 
compilierten Sprachen.

Jörg W. schrieb:

> Das würde nur dann jemand
> bezahlen, wenn sich daraus unmittelbar Probleme lösen ließen, die in C
> nicht (mit vertretbarem Aufwand) lösbar wären. Aber so riesig ist der
> Vorteil von C++ wiederum eben dann doch nicht. Es ist manches netter und
> bequemer und schöner,

Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler 
so früh wie möglich aufgedeckt werden. Also: compile-time statt 
run-time.

> gar keine Frage, aber in dem Bereich, in dem wir
> arbeiten, gibt es kaum was, was nicht in C auch gänge, ohne dass man
> dadurch nun unbillige Härte in Kauf nehmen müsste.

Unbillige Härte: nur dann, wenn man die Holzhammermethode einsetzt.

> Und überall dort, wo es nicht (unbedingt) in Firmware sein muss,
> dominiert schlicht und ergreifend Python.

Davon war doch gar keine Rede. Und auch das ist eine Pauschalaussage, 
die so nicht stimmt. Es gibt Branchen, da sieht es anders aus, da spielt 
Python gar keine Rolle. Und ich meine jetzt nicht C++-Nutzung.

Wilhelm M. schrieb:
> ch denke, ein Vorschlag in eine andere Richtung ist noch keine
> Evangelisiererei.

Dann schlage ich Dir an dieser Stelle noch Matlab vor. Der 
"bitshift()"-Befehl hat dort auch keinerlei Probleme mit Vorzeichen.

Wilhelm M. schrieb:

> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler
> so früh wie möglich aufgedeckt werden. Also: compile-time statt
> run-time.

Da hilft uns die Wahl der Programmiersprache praktisch gar nicht.

Aus dem Alter der totalen Anfängerfehler sind wir einfach mal raus. ;-)

> Davon war doch gar keine Rede. Und auch das ist eine Pauschalaussage,
> die so nicht stimmt. Es gibt Branchen, da sieht es anders aus, da spielt
> Python gar keine Rolle.

Keine Frage. Ich wollte damit nur ausdrücken: wenn man die Dose „andere 
Programmiersprache“ öffnet (öffnen kann), dann ist es eben nicht nur C 
vs. C++, sondern die Palette wird einfach breiter.

Wilhelm M. schrieb:
> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler
> so früh wie möglich aufgedeckt werden. Also: compile-time statt
> run-time.

In dem obigen Fall ging es bereits um Compiletime, runtime stand hier 
nirgendwo zur Debatte! Ich will entweder den if oder den else zweig 
kompilieren, niemals beide gleichzeitig, der Optimizer hilft mir dabei. 
Ein if auf ne konstante Bedingung hat schon so manches häßliche #ifdef 
ersetzt. Mein shift ist konstant zur Kompilezeit! Wenn es kompiliert ist 
es korrekt!


Würd ich das alles in C++ machen würd ich sicherlich auch keine Makros 
verwenden die mir zur Compilezeit getypte und parametrierte Funktionen 
generieren sondern ich würde die C++-Templatemechanismen ausschöpfen um 
meine Filterfunktionen und anderen Krempel zu erzeugen. Ich müsste 
etliches umkrempeln. Das will ich nicht. Noch nicht und schon dreimal 
nicht für den alten in Produktion befindlichen Code, es ist nicht so daß 
ich hier rumsitze und Däumchen drehe und aus schierer Langeweile neue 
Baustellen aufreiße in perfekt funktionierenden Projekten. Ich hab hier 
lang gewachsenes C, es war schon C bevor ich hier angefangen habe und 
kein C++. Ende der Durchsage.

Jörg W. schrieb:
> Aus dem Alter der totalen Anfängerfehler sind wir einfach mal raus. ;-)

Du arbeitest nicht zufällig bei Cisco? ;-)

Bernd K. schrieb:
> Wilhelm M. schrieb:
>> Viel wichtiger ist doch, dass man in einen Bereich kommt, in dem Fehler
>> so früh wie möglich aufgedeckt werden. Also: compile-time statt
>> run-time.
>
> In dem obigen Fall ging es bereits um Compiletime, runtime stand hier
> nirgendwo zur Debatte! Ich will entweder den if oder den else zweig
> kompilieren, niemals beide gleichzeitig, der Optimizer hilft mir dabei.

Der Unterschied ist subtil, aber sehr wichtig, gerade auf für templates:

bei einem run-time if (wie bei Dir) müssen beide Zweige compiliert 
werden, deswegen auf die warnings. Der Optimizer erst kann nachweisen, 
dass er hier wegen const den false-Zweig verwerfen kann.

bei einem compile-time (constexpr) if wird der false-Zweig direkt 
verworfen, d.h. nicht compiliert. Deswegen keine warning. Der Optimizer 
ist arbeitslos.

Das ist ja ganz wichtig für templates, die dann im false-Zweig nicht 
instantiiert werden.

Wilhelm M. schrieb:
> gerade auf für templates

templates? In C?

Ach, du lebst in deiner C++-Blase … :)

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> gerade auf für templates
>
> templates? In C?
>
> Ach, du lebst in deiner C++-Blase … :)

Ooch, lies doch mal alles. Ich habe auf Bernd K. geantwortet, der sich 
wieder auf meinen Beitrag bezog.

Wilhelm M. schrieb:
> Ooch, lies doch mal alles

Bitte lass trotzdem dein C++ hier raus. Schön dass dich das so 
begeistert, sogar nachvollziehbar aber hier hilft es nicht.

Wilhelm M. schrieb:
> Ich habe auf Bernd K. geantwortet

Bernd hat aber auch ausdrücklich geschrieben, dass es sich um C-Code 
handelt. Damit sind irgendwelche Betrachtungen über Templates und deren 
Compiler-Effizienz hinfällig genauso wie "constexpr" (ich sehe zumindest 
nicht, dass jemand bereits constexpr in die aktuellen C-Standard-Drafts 
eingebracht hätte).

Jörg W. schrieb:
> Wilhelm M. schrieb:
>> Ich habe auf Bernd K. geantwortet
>
> Bernd hat aber auch ausdrücklich geschrieben, dass es sich um C-Code
> handelt.

Er sprach über alten Code, der schon vor seinem Eintritt in das Projekt 
bestand. Er sagte auch, dass er es anders machen würde, wenn es kein 
legacy-Code wäre.
Und ich hoffe für ihn und seine Firma, dass sie auch mal neue Sachen 
machen.

c-hater schrieb:
> Also genau das, was C macht und
> weswegen ich C so abgrundtief hasse...

Eigentlich magst Du C doch. Ansonsten gäbe es keinen vernünftigen Grund, 
jeden Thread, wo es behandelt wird, aufzusuchen.

Bernd K. schrieb:
> Wenn ich mal mehr Zeit hab mach ich nen Bugreport.

Es ist aber kein Bug: Der Compiler warnt lediglich, dass es hier 
möglicherweise ein Problem gibt (und damit hat er recht).

Wie bereits geschrieben:

Jörg W. schrieb:
> Naja, ohne Fehler compiliert es auch so schon, und das Ergebnis ist
> korrekt. Es gibt ja keinen Fehler, sondern eine Warnung.
>
> Selbst die Warnung ist für sich genommen nicht falsch: der shift count
> an dieser Stelle wäre ja tatsächlich negativ – nur dass die Stelle eben
> aufgrund der äußeren Umstände garantiert nicht erreicht wird (was sich
> ja auch im generierten Code reflektiert). Insofern ist die Warnung
> verwirrend, aber eher eine Unschönheit denn ein tatsächlicher Bug.

Ein Bug würde vorliegen, wenn der generierte Code falsch ist.

Die Prüfung auf mögliche Probleme kann in verschiedenen Compiler Stages 
durchgeführt werden. Ich bezweifle, dass sich die Maintainer für das 
(eigentlich "selbst" eingebrockte) Problem des TE interessieren.

Solcher Code sollte imho gar nicht in einem Projekt auftauchen. -- Auch 
wenn ich durchaus nachvollziehen kann wie es dazu kam.

c-hater schrieb:
> Mikro 7. schrieb:
>
>> Es ist aber kein Bug: Der Compiler warnt lediglich, dass es hier
>> möglicherweise ein Problem gibt (und damit hat er recht).
>
> Nein, er hat eben nicht Recht, es kann hier niemals ein Problem geben
> und dieser Sachverhalt ist bereits zur Compilezeit eindeutig
> verifizierbar. Also, ganz eindeutig: BUG.

Du hast offensichtlich den Unterschied zwischen einer Warn-und einer
Fehlermeldung nicht verstanden.

Der Compiler gibt eine Fehlermeldung aus, wenn der der betreffende
Quellcode formal (d.h. syntaktisch oder semantisch) inkorrekt ist.

Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode
zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,
dass er nicht das tut, was der Programmierer beabsichtigt hat.

Der zweite Fall trifft auf den Code des TE definitiv zu:

- Zu einen steht da (mit eingesetzter Konstante) der Ausdruck x<<-7. So
  etwas ist in den allermeisten Fälle nicht beabsichtigt, weswegen es
  legitim ist, dass der Compiler hier ein potentielles Problem aufzeigt.

- Dass der fragliche Code nie ausgewertet wird, ändert nichts daran,
  dass x<<-7 fehlerhaft aussieht. Da es darüberhinaus auch unüblich ist,
  nicht erreichbaren Code zu schreiben, wäre hier zusätzlich zur
  ausgegebenen Warnung sogar noch eine entsprechende zweite Warnmeldung
  angebracht (von der du vermutlich ebenso behaupten würdest, sie sei
  ein Bug).

Da der TE weiter oben erklärt hat, wie es zu diesem seltsamen Code kam,
wissen wir, dass die Warnmeldung ignoriert werden dürfen. Der Compiler
hingegen kennt diese Erklärung nicht, da er in diesem Forum nicht
mitliest. Also kann man es ihm ein "Häh?" von seiner Seite wirklich
nicht verdenken.

Vermeintlich zu viele oder zu wenige ausgegebene Warnmeldung können
übriges niemals ein Bug sein , da der C-Standard nicht bindend festlegt,
wann und wo eine Warnung ausgegeben werden soll. Dies liegt allein im
Ermessen des Compilerbauers.

Yalu X. schrieb:
> Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode
> zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,
> dass er nicht das tut, was der Programmierer beabsichtigt hat.

Die Wahrscheinlichkeit beträgt in diesem Fall aber ziemlich genau 0%, es 
handelt sich um ein false-positive.

Außerdem: Baut man Code mit "-O0", verändern sich die Warnungen. Viele 
Sachverhalte werden erst im Rahmen der Optimierung untersucht und führen 
dann zu Warnungen - oder eben auch nicht, wenn keine Optimierung 
stattfindet.

Warnungen sind super, und Warnungen zu UB sogar noch viel besser. Aber 
diese ist schlicht irreführend und daher als Bug im Compiler zu 
betrachten.

Yalu X. schrieb:
> Dies liegt allein im Ermessen des Compilerbauers.

Du meinst also, dass "WONTFIX" für sämtliche Warnungen eine angemessene 
Reaktion wäre? :-)

Hallo,

ihr denkt zu kompliziert.  :-)  Die Shiftweite, der Wert, darf nie 
negativ sein. Der Wert ist nur ein Betrag und gibt nur an UM wieviele 
Bits verschoben wird. Die Richtung geben allein die Operatoren vor. Du 
musst also nur dafür sorgen das dein Shiftwert immer positiv ist. Nach 
der einfachen Logik meckert der Compiler zu recht - kein Bug laut meiner 
Meinung.

1

int foo(int x) {

2

  const int shift = -1*(6-13);

3

  if (shift < 0) {

4

    return (x << shift); 

5

  } 

6

  else {

7

    return (x >> shift);        

8

  }

9

}

S. R. schrieb:
> Yalu X. schrieb:
>> Der Compiler gibt eine Warnmeldung aus, wenn der betreffende Quellcode
>> zwar formal korrekt ist, aber eine gewisse Wahrscheinlichkeit besteht,
>> dass er nicht das tut, was der Programmierer beabsichtigt hat.
>
> Die Wahrscheinlichkeit beträgt in diesem Fall aber ziemlich genau 0%, es
> handelt sich um ein false-positive.

Um die Wahrscheinlichkeit auf 0 reduzieren zu können, müsste der
Compiler Gedanken lesen können.

Nur zur Klarstellung: Eine Compilerwarnung kann, muss aber nicht
notwendigerweise durch ein undefined Behavior ausgelöst werden. Der vom
TE gepostete Code bewirkt kein UB, dennoch ist er zunächst – ohne
weitergehende Erläuterungen des Programmierers – einfach nur unsinnig,
und das gleich aus zwei Gründen: wegen des negativen Shift-Arguments und
wegen des nicht erreichbaren Else-Zweigs. Ist es da falsch anzunehmen,
dass der Programmierers evtl. etwas anderes beabsichtigt hat?

> Yalu X. schrieb:
>> Dies liegt allein im Ermessen des Compilerbauers.
>
> Du meinst also, dass "WONTFIX" für sämtliche Warnungen eine angemessene
> Reaktion wäre? :-)

Ich habe nicht geschrieben, dass die Qualität der Warnmeldungen nicht
verbessert werden darf.

Also ich bekomm die Warning ganz einfach weg, also als Workaround:

1

static inline int yshift (int x, int shift)

2

{

3

    if (shift < 0) {

4

        return x >> -shift;

5

    } else {

6

        return x << shift;

7

    }

8

}

9

10

int foo(int x) {

11

    const int shift = 6 - 13;

12

    return yshift (x, shift);

13

}

Inline-Funktionen sind hier ohnehin Makros vorzuziehen, weil:

* Argumente nur 1x ausgewertet werden.  Wenn man z.B. MAX als Makro 
implementiert, werden die Argumente mehrfach ausgewertet.  Das ist 
schlecht bei Seiteneffekten, z.B. bei Ausdrücken (Funktionsaufruf) als 
Argument, x++ o.ä. oder volatile.

* Bessere Diagnostics bei Syntax-Fehlern.

* Besser wartbar.

* Bessere Debugging-Erfahrung (zumindest mit ältlichen Debuggern).

Andererseits: Welche realistisch vorkommende Maschine verhält sich 
anders als üblich? Als C neu war, gab es solche. Und heute?

A. K. schrieb:
> anders als üblich

Was wäre denn "üblich"?

Und je nachdem gibt es auch QA die da drauf schaut und "Nein" sagt.

Johann L. schrieb:
> Inline-Funktionen sind hier ohnehin Makros vorzuziehen

In meinem Fall ist auch der Typ von x erst bekannt wenn die Funktion 
erzeugt wird, ich müsste also auch diese inline-Hilfsfunktion jedesmal 
extra erzeugen, deshalb hab ichs vorerst beim Makro belassen. Scheint 
aber so daß selbst auf der kleinsten Optimierungsstufe schon nichts mehr 
doppelt ausgewertet werden muss, also lass ichs erstmal so.

Durchsteppen (im source) kann ich das ganze Ding eh nicht weil der 
Sourcecode des ganzen Gebildes in seiner endgültigen Form erst nach der 
Makroexpansion überhaupt erst zu existieren beginnt.

Brrrz schrieb:
> Jedesmal wenn jemand vorzeichenbehaftete Werte schiebt, sollte
> eigentlich sein Bürostuhl unter Strom gesetzt werden.

Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als 
auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links 
und recht zwei verschiedene Shift-Operationen mit nur positiven Werten 
gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides 
kann.

Rolf M. schrieb:
> Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als
> auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links
> und recht zwei verschiedene Shift-Operationen mit nur positiven Werten
> gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides
> kann.

Für einen Wertebereich von -32 bis +31 brauchst du 6 Bit. Ob das nun "1 
Bit im Opcode und 5 Parameterbits" sind oder "6 Parameterbits", ist 
egal.

Ersteres ist flexibler, weil es 4 Varianten gibt: LSL, LSR, ASL, ASR. 
Zwei davon (LSL und ASL) sind aber gleich, wenn man die schon im Decoder 
gleich abhandeln kann, spart man Logik. Außerdem spart man Logik, wenn 
man das Zweierkomplement nicht decodieren muss - schieben ist nicht 
addieren.

Bernd K. schrieb:
> Johann L. schrieb:
>> Inline-Funktionen sind hier ohnehin Makros vorzuziehen
>
> In meinem Fall ist auch der Typ von x erst bekannt wenn die Funktion
> erzeugt wird, ich müsste also auch diese inline-Hilfsfunktion jedesmal
> extra erzeugen, deshalb hab ichs vorerst beim Makro belassen.

... und damit wären wir bei templates in C++.

Wilhelm M. schrieb:
> und damit wären wir bei templates in C++

du wirst langweilig.

CPUs, bei denen die Anzahl mit Vorzeichen codiert wurde, gab (gibt?) es. 
Mindestens bei Z8000 und VAX war das der Fall.

Rolf M. schrieb:
> Ich hab ehrlich gesagt noch nie verstanden, warum es sowohl in C, als
> auch auf Maschinen-Ebene (zumindest bei denen, die ich kenne) für links
> und recht zwei verschiedene Shift-Operationen mit nur positiven Werten
> gibt, statt einfach einen Shift mit Vorzeichen zu machen, der beides
> kann.

Auf Maschinenebene kann man das im Grunde definieren wie man will.

In der Definition einer höheren Programmiersprache wäre das schon 
interessanter, denn man hätte dann ja konsequenterweise nur noch einen 
Shift-Operator statt zwei. In C also nicht << und >>, sondern <> oder 
was auch immer, in mitsamt Definition, welches Vorzeichen in welche 
Richtung schiebt.

Spannend bliebe aber weiterhin die Sache bei negativem linkem Operanden. 
Weil bei damaligen Maschinen beim Shift selbst mit definiertem 
arithmetischem Shift nicht so ganz klar war, ob aus -1 einfach linksrum 
-2 oder -3 wird, oder rechtsrum -1 oder -0.

Insofern wäre es leicht pervers gewesen, zwar eine negative Anzahl 
zuzulassen, ohne aber ein klares Ergebnis bei negativem Operand zu 
definieren.

A. K. schrieb:
> In der Definition einer höheren Programmiersprache wäre das schon
> interessanter, denn man hätte dann ja konsequenterweise nur noch einen
> Shift-Operator statt zwei.

Vermutlich gerade WEIL die darunter liegende Maschine zwei 
verschiedene Befehle hat muss man das in der Hochsprache ebenfalls 
abbilden weil ansonsten womöglich der Compiler zur Compilezeit nicht 
mehr wasserdicht beweisen kann ob es immer positiv oder immer negativ 
ist und deswegen jedesmal Code für eine Fallunterscheidung und beide 
Befehle einbauen müsste anstatt einfach nur den einen Befehl 
hinzuschreiben den der Programmierer (der einzige der es wissen kann) 
wollte.

Wir wärs mit:

1

int foo(int x) {

2

    const int shift = 6 - 13;

3

    if (shift < 0) {

4

        return x >> (unsigned)-shift;

5

    } else {

6

        return x << shift;

7

    }

8

}

Es gibt nämlich einen Fall, wo eine negative Zahl x bei -x negativ 
bleibt. Und die Warnung kommt vermutlich schon von einem Compileschritt 
vor der Ersetzung durch eine Konstante.
Bei char ist es die -128, die negativ bleibt.

900ss D. schrieb:
> Wilhelm M. schrieb:
>> und damit wären wir bei templates in C++
>
> du wirst langweilig.

und schaue - etwas schopfschüttelnd - zu wie man sich hier (in C) abmüht 
;-)

Wilhelm M. schrieb:
> und schaue - etwas schopfschüttelnd - zu wie man sich hier (in C) abmüht

Niemand müht sich ab. Wenn man weiß wie die Sprache tickt kann man viele 
solcher Sachen locker flockig und sogar sauber hinschreiben bei denen 
sich ein Anfänger noch die Augen reiben würde und man kommt schon 
verdammt weit damit. Der Anfänger reibt sich aber auch bei C++ die Augen 
wenn ihm die volle Macht dieser Sprache mit all ihren barocken Türmchen 
und Erkerchen ins Gesicht geschleudert wird, also halbwegs Gleichstand.

Bernd K. schrieb:
> Der Anfänger reibt sich aber auch bei C++ die Augen

Unleserliche Programme lassen sich in jeder Programmiersprache verfassen 
…

Jörg W. schrieb:
> Bernd K. schrieb:
>> Der Anfänger reibt sich aber auch bei C++ die Augen
>
> Unleserliche Programme lassen sich in jeder Programmiersprache verfassen

Für einen Anfänger kann auch sauberer Code vollkommen unleserlich sein, 
je mächtiger und komplexer die Sprache umso länger hält dieser Zustand 
an.

Bernd K. schrieb:
> je mächtiger und komplexer die Sprache umso länger hält dieser Zustand
> an.

Nö. Simple Sprachen verursachen da mehr Kopfzerbrechen.

Ich finde Wilhelm durchaus auch in dieser Hinsicht nervig, aber das ist 
noch lange kein Grund, deshalb nun alle möglichen Scheinargumente 
hervorzuzaubern, warum die Sprache C++ Mist wäre. Diese "Argumentation" 
ist einfach noch nerviger.

Jörg W. schrieb:
> Scheinargumente
> hervorzuzaubern, warum die Sprache C++ Mist wäre

Das hab ich doch gar nicht gesagt. Ich versuchte mit einem Augenzwinkern 
einen Gleichstand herbeizuführen damit alle wieder beruhigt ihres Weges 
gehen können. Ich nehme nur deshalb zufällig kein C++ weil sich halt 
eben alles irgendwann mal so ergeben hat wie es heute ist und ich auch 
noch nicht an harte Grenzen gestoßen bin, nicht weil ich irgendwas an 
C++ auszusetzen hätte.

Bernd K. schrieb:
> einen Gleichstand herbeizuführen

Ich finde, dass das eher Kindergartenniveau ist.  "Du eins, ich eins."

Jörg W. schrieb:
> Bernd K. schrieb:
>> einen Gleichstand herbeizuführen
>
> Ich finde, dass das eher Kindergartenniveau ist.  "Du eins, ich eins."

Warum musst Du jetzt anfangen zu pöbeln, aus heiterem Himmel? Und Sachen 
unterstellen die gar nicht gesagt wurden ("c++ sei mist")? Warum?

Bernd K. schrieb:
> Jörg W. schrieb:
>> Scheinargumente
>> hervorzuzaubern, warum die Sprache C++ Mist wäre
>
> Das hab ich doch gar nicht gesagt. Ich versuchte mit einem Augenzwinkern
> einen Gleichstand herbeizuführen damit alle wieder beruhigt ihres Weges
> gehen können. Ich nehme nur deshalb zufällig kein C++ weil sich halt
> eben alles irgendwann mal so ergeben hat wie es heute ist und ich auch
> noch nicht an harte Grenzen gestoßen bin, nicht weil ich irgendwas an
> C++ auszusetzen hätte.

Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen, 
etwas cherry-picking zu machen, indem man beides zusammen führt. Es ist 
ja nun nicht schwer oder undurchsichtig, C und C++ via header-only zu 
mischen.

Bernd K. schrieb:

> Warum musst Du jetzt anfangen zu pöbeln, aus heiterem Himmel? Und Sachen
> unterstellen die gar nicht gesagt wurden ("c++ sei mist")? Warum?

Die wurden nicht direkt gesagt, aber unterschwellig hast du genau das 
ausgedrückt: groß, komplex, "barocke[n] Türmchen und Erkerchen ins 
Gesicht geschleudert".

Das ist das, was ich schlicht unter Niveau fand.

Wilhelm M. schrieb:
> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,
> etwas cherry-picking zu machen

Da hängt noch mehr dran, ich hab zum Beispiel stellenweise stark 
abgespeckten startup-code ohne __libc_init_array und den ganzen Sermon, 
ich initialisiere nur was für C nötig ist, und beim Linkerscript bin ich 
mir auch nicht sicher ob da noch alle sections drin sind die nötig sind.

Und dann ist es die Zeit, ich müsste erstmal Rostlöser an den grauen 
Zellen ansetzen um da wieder halbwegs in die Gänge zu kommen mit C++ und 
wie ich das dann sauber mit dem alten Code mischen kann ohne 
irgendwelchen Mist zu bauen. Und am Ende fang ich dann an vor lauter 
Euphorie alles umzubauen was schon mal funktioniert hat, aber ich hab 
auch nicht unendlich viele Ressourcen. Deshalb lass ich das erstmal. Ich 
bin immer noch zufrieden mit dem was ich habe.

Bernd K. schrieb:
> Wilhelm M. schrieb:
>> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,
>> etwas cherry-picking zu machen
>
> Da hängt noch mehr dran, ich hab zum Beispiel stellenweise stark
> abgespeckten startup-code ohne __libc_init_array und den ganzen Sermon,
> ich initialisiere nur was für C nötig ist, und beim Linkerscript bin ich
> mir auch nicht sicher ob da noch alle sections drin sind die nötig sind.

Und so ein Vorgehen findest Du jetzt klar und durchsichtig? Mmh ...

> Und dann ist es die Zeit, ich müsste erstmal Rostlöser an den grauen
> Zellen ansetzen um da wieder halbwegs in die Gänge zu kommen mit C++ und
> wie ich das dann sauber mit dem alten Code mischen kann ohne
> irgendwelchen Mist zu bauen.

Auch wenn ich mich wiederhole: man muss ja nicht alles auf C++ 
umstellen, es genügt dieses eine kleine Beispiel als Einstieg.

Jörg W. schrieb:
> Die wurden nicht direkt gesagt, aber unterschwellig hast du genau das
> ausgedrückt: groß, komplex, "barocke[n] Türmchen und Erkerchen ins
> Gesicht geschleudert".
>
> Das ist das, was ich schlicht unter Niveau fand.

Also komm, jetzt lass aber mal wieder gut sein. Man kanns echt 
übertreiben. "Unterschwellig". Ich glaub Dein Niveaudetektor läuft Amok, 
kalibrier den bitte mal neu.

Dann lass doch einfach auch solche doofen Anspielungen sein. Ich weiß 
echt nicht, was "barocke Türmchen und Erkerchen" sein sollen wenn keine 
Provokation.

Bezüglich des Startup-Codes: ich sehe ja, dass es Gründe geben kann, ihn 
gelegentlich zu erweitern (selig die AVR-Tage, wo man den mitgelieferten 
Startup-Code eigentlich immer ohne weiteres Nachdenken benutzen konnte, 
da er 99,9 % aller Anwendungsfälle abgedeckt hat), aber warum braucht 
man solche Sonderlocken, __libc_init_array() rauszuwerfen? Wenn du das 
nicht benutzt, wird das doch sowieso automatisch eliminiert.

Wilhelm M. schrieb:
> Und so ein Vorgehen findest Du jetzt klar und durchsichtig? Mmh ...

Ist sehr klar und sehr durchsichtig und ISO-Konform. Der Startupcode ist 
für C, nicht für C++, nicht für Rust und auch nicht für Pascal sondern 
für C.

Jörg W. schrieb:
> solche Sonderlocken, __libc_init_array() rauszuwerfen?

Weil das was es macht in C nicht gebraucht wird? Warum soll ich 
Sonderlocken für C++ einbauen die gar nicht genutzt werden?

Bernd K. schrieb:
> Jörg W. schrieb:
>> solche Sonderlocken, __libc_init_array() rauszuwerfen?
>
> Weil das was es macht in C nicht gebraucht wird? Warum soll ich
> Sonderlocken für C++ einbauen die gar nicht genutzt werden?

C++ ist erstmal einer der standardmäßigen Anwendungsfälle, aber das 
heißt erstens ja nicht, dass es der einzige Fall ist, und zweitens, 
wie schon geschrieben, kostet es nichts, das Ding drin zu lassen. Wenn 
man es nicht benutzt, stört es letztlich nicht. Man muss sich ja nicht 
zusätzliche Arbeit (und potenzielle Fehlerquellen) an Land ziehen, nur 
um vorhandene und erprobte Technik zu kastrieren.

Ich überlege gerade, das Pendant eines statischen Konstruktors in einem 
C-Projekt unterzubringen …

Jörg W. schrieb:
> Ich weiß
> echt nicht, was "barocke Türmchen und Erkerchen" sein sollen
> wenn keine Provokation.

Eine neutrale Tatsachenfeststellung vielleicht, jetzt wo Du so direkt 
fragst?

Ich hätte ja sonst weiter zu dem Thema nichts gesagt aber immerhin hast 
diesmal Du grundlos einen Streit vom Zaun gebrochen und unterstellst 
andern grundlos böse Absichten und dann auch noch Inkompetenz zwischen 
den Zeilen. Und das noch als Moderator. Manchmal frag ich mich echt was 
hier los ist, haben wir gerade wieder Vollmond oder was?

Jörg W. schrieb:
> C++ ist erstmal einer der standardmäßigen Anwendungsfälle

Aber nicht in meinen C-Projekten.

Begründung lass ich jetzt weg, denn das geht keinen was an und wird eh 
nur wieder mir im Munde umgedreht bei dem hohen Streitlustkoeffizienten 
hier.

Dr. Sommer schrieb:
> Dann siehst du die Aussage
>
> "C ist eine antike primitive Sprache zur Verarbeitung von Bytes ohne
> Möglichkeiten zur Abstraktion, Wiederverwendbarkeit, Modularisierung,
> Ressourcen-Verwaltung, strukturierter Fehlerbehandlung und
> Datenkapselung, welche hauptsächlich von Personen verwendet wird, die
> fortschrittlichere Sprachen nicht verstehen"
>
> sicherlich auch als neutrale Tatsachenfeststellung.

Der letzte Telsatz beleidigt Personen, der andere Teil ist faktisch 
falsch bis auf "antik", das ist zutreffend und "primitiv" teilweise 
zutreffend.

Weder meine Türme noch die Erker haben irgendwen beleidigt (außer Dir 
anscheinend) noch sind sie unzutreffend.

Bernd, lass gut sein. Wenn du eine offensichtlich extreme 
Voreingenommenheit als "neutrale Tatsachenfeststellung" auszugeben 
versuchst, dann müssen wir darüber nicht weiter diskutieren, denn wir 
werden hier ohnehin keine Einigkeit erzielen.

Mach dein Ding, dein Problem ist ja zumindest halb gelöst. Ein Ticket 
bei GCC kannst du allemal dafür öffnen, vielleicht interessiert sich 
wirklich einer der Entwickler mal dafür und weiß, wo man dabei ansetzen 
muss für eine Korrektur.

Dr. Sommer schrieb:
> Bernd K. schrieb:
>> Weder meine Türme noch die Erker haben irgendwen beleidigt (außer Dir
>> anscheinend) noch sind sie unzutreffend.
>
> Warum schriebst du dann "Türme" und "Erker" und nicht "mächtige
> Funktionalität" und "effiziente Möglichkeiten"? Nicht beleidigend genug?

Weder "Turm" noch "Erker" sind negativ besetzte Begriffe.

Und in zwei Stunden kommt der andere Moderator und räumt diese ganze 
Bullshit-Diskussion die ihr da jetzt wegen NICHTS und aus purer 
Langeweile vom Zaun gebrochen habt wieder weg.

Dr. Sommer schrieb:
> Bernd K. schrieb:
>> Weder "Turm" noch "Erker" sind negativ besetzte Begriffe.
>
> Warum hast du sie dann benutzt? Wolltest du andeuten, wie dekorativ und
> geräumig C++ ist?

Ja genau. Kurz nachdem ich "die volle Macht" erwähnte wollte ich noch 
das Augenmerk auf die ansprechende Dekoration und Geräumigkeit lenken. 
Und auf die vielen kleinen Winkel in denen man so gut Verstecken spielen 
kann.

Und jetzt geh in den Keller und lach endlich mal!

Bernd K. schrieb:
>> C++ ist erstmal einer der standardmäßigen Anwendungsfälle
> Aber nicht in meinen C-Projekten.

Ich finde es super, wie du überall gerade argumentierst, warum Dinge 
doof sind, weil sie gerade in deinem aktuellen Anwendungsfall nicht 
passen.

Cool, dass du einen zertifizierten Startup-Code für C geschrieben hast 
und den für C++ neu zertifizieren lassen müsstest. Echt geil. Hat aber 
nix mit C++ zu tun, sondern mit deinem zertifizierten Startup-Code.

S. R. schrieb:
> Echt geil. Hat aber
> nix mit C++ zu tun, sondern mit deinem zertifizierten Startup-Code.

Und was hat der ganze Thread hier überhaupt mit C++ zu tun?

Verfolgst Du mich jetzt durch das ganze Forum und mußt überall Deinen 
Senf dazugeben? Was hat das hier diskutierte Thema mit C++ zu schaffen, 
was hab ich damit zu schaffen? Geh woanders hin und nimm die C++ 
Evangelisten gleich alle mit, das nervt echt langsam!

S. R. schrieb:
> Ich finde es super, wie du überall gerade argumentierst, warum Dinge
> doof sind, weil sie gerade in deinem aktuellen Anwendungsfall nicht
> passen.

So? Wo tu ich das denn? Ich glaub Du leidest unter Wahnvorstellungen. 
Hier bei dem Thema gehts um eine reine C-Angelegenheit. Natürlich finde 
ich es dann doof wenn überall Evangelisten aus den Löchern kommen die 
mir andere Programmiersprachen aufschwatzen wollen, so penetrant wie 
verzweifelte Staubsaugervertreter.

Bernd K. schrieb:
> penetrant wie verzweifelte Staubsaugervertreter

 sehr schön gesagt :)

S. R. schrieb:
> Cool, dass du einen zertifizierten Startup-Code für C geschrieben hast

Jetzt geht der Fieberwahn endgültig mit Dir durch, wo hab ich was von 
zertifiziert geschrieben? Wenn ich was zertifiziertes haben will dann 
kauf ich das irgendwo fertig, glaubst Du ich spiel in so einem 
lächerlichen Zertifikatszirkus freiwillig als der Clown in der Manege 
mit?

Jörg W. schrieb:
> Ich überlege gerade, das Pendant eines statischen Konstruktors in einem
> C-Projekt unterzubringen …

Du meinst Attribut constructor?

Johann L. schrieb:
> Jörg W. schrieb:
>> Ich überlege gerade, das Pendant eines statischen Konstruktors in einem
>> C-Projekt unterzubringen …
>
> Du meinst Attribut constructor?

Yo, hatte ich dann auch gefunden und mir angesehen, was dabei rauskommt.

Holm T. schrieb:
> Deine Argumentation kommt mir bekannt vor, so hast Du mich zum Natsieh
> gemacht.

Dazu hast du dich nebenan schon selbst gemacht:

Holm T. schrieb:
> und wenn es hier so weiter geht kommen Neuentwicklungen nur noch in der
> Form vom Kamel- und Schafsrassen, Burkas und fliegenden Teppichen aus
> Deutschland.

Ja, ladet allen Müll den ihr findet hier in meinem Thread ab. Ist noch 
massenhaft Platz nach unten hin.