mikrocontroller.net

Forum: Compiler & IDEs gcc bug (diesmal wirklich): "shift count is negative"


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q3-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE
int foo(int x) {
    const int shift = 6 - 13;
    if (shift < 0) {
        return x >> -shift;
    } else {
        return x << shift;
    }
}

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


aber wenn ich das const ertferne:
int foo(int x) {
    int shift = 6 - 13;
    if (shift < 0) {
        return x >> -shift;
    } else {
        return x << shift;
    }
}

kompiliert es ohne Fehler!

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schön. Eröffne nen Bug: https://gcc.gnu.org/bugzilla/

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: CompilerBauer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
online compiler sind dein Freund (bei so kurzen Codeschnippeseln), da 
kannst du von verschiedensten Compilern die Ergebnisse vergleichen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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. ;-)
$ avr-gcc -Os -mmcu=atmega1281 -Wall -Wextra -S foo.c
foo.c: In function ‘foo’:
foo.c:6:18: warning: left shift count is negative [-Wshift-count-negative]
    6 |         return x << shift;
      |                ~~^~~~~~~~
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/local/lib/gcc/avr/9.1.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/avr/9.1.0/lto-wrapper
Target: avr
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
Thread model: single
gcc version 9.1.0 (GCC) 

Autor: Ntldr -. (ntldr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
#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.

Wenn ich mal mehr Zeit hab mach ich nen Bugreport.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
-5 lesenswert
nicht lesenswert
Jörg W. schrieb:

> 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.

Das ist ganz klar und eindeutig ein Bug.

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.

Das sollte NIEMALS passieren. Das konterkariert den Sinn der 
statischen Codeanalyse und unterminiert ihre praktische Nutzbarkeit als 
Sicherungsmechanismus.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Hab mir jetzt sowas gebaut:
> #define SHIFT_LEFT(x, y)   ... : (x) >> -(y))

doubleplusungood

leo

Autor: Jemand (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ich hoffe ja, dass euch das Schieben von vorzeihenbehafteten Variablen 
irgendwann um die Ohren fliegt.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Johann J. (johannjohanson)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Doch, natürlich gibt es die.

Zeigen!

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Das ist kein Bug

Aus dem freien Draft:

The integer promotions are performed on each of the operands. The type 
of the result is that of thepromoted left operand. If the value of the 
right operand is negative or is greater than or equal to thewidth of the 
promoted left operand, the behavior is undefined.


https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf

Grüße,

Autor: nicht"Gast" (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

im Kapitel 6.5.7 Bitwise shift operators

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
nicht"Gast" schrieb:
> Das ist kein Bug

In obigem Code ist die Shiftcount garantiert nicht negativ.

: Bearbeitet durch User
Autor: Daniel A. (daniel-a)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Oliver S. (oliverso)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Das Freihalten der Buildkonsole von jeglichen Warnungen gehört zu meinen
> Top-Prioritäten.

Das ist lobenswert, aber hier zu spaet. Wenn ein Leftshift ploetzlich in 
die andere Richtung losgeht, ist schon voher was faul. Ein assert(3) ist 
die bessere Loesung und zeigt direkt das Problem auf anstatt es zu 
verstecken.

leo

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Heiko L. (zer0)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Beitrag #5948400 wurde vom Autor gelöscht.
Autor: Heiko L. (zer0)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: leo (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Jetzt hab ich den Code an einigen Stellen erweitert um später auch
> negative shifts dort haben zu können

Das wird ja immer schlimmer ...
Du schreibst also nicht sauberen Code sondern sauber obfuscated Code.

leo

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Daniel A. schrieb:
>> Ich kompiliere meine Programme immer mit -Werror,
>
> Was durchaus vernünftig ist, machen wir in der Firma auch so.

Wirklich immer? Oder nur wenn es darum geht den Quelltext zu commiten?
Ich würd irre werden, wenn ich beim entwickeln Fehler der Form
error: unused parameter 'foo' [-Werror=unused-parameter]
oder ähnlich belommen würde.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: DPA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> 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.

Ich sage dem Kompiler bei der Meldung statdessen explizit, dass das OK 
ist. Ganz oben in den Funktionsrump kommt: "(void)foo;", und dann ist 
dem Compiler klar, der Parameter ist absichtlich ungenutzt. Aber nicht 
vergessen, die wieder raus zu nehmen, wenn der Parameter später doch mal 
gebraucht wird.

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
void setup(void) {
  Serial.begin(250000);
}

void loop(void) {
  for (int i = -10; i < 11; i++)
  {
    Serial.println( foo(i) );
  }
}

int foo(int x) {
  const int shift = 6 - 13;
  if (shift < 0) {
    return x >> -shift;
  } else {
    return x << shift;
  }
}

Ausgabe:
Sketch wird kompiliert...
"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"
C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino: In function 'int foo(int)':
C:\Users\devil\AppData\Local\Temp\arduino_modified_sketch_766131\sketch_aug22b.ino:24:21: warning: left shift count is negative [-Wshift-count-negative]
   24 |         return x << shift;
      |                     ^~~~~
Compiling libraries...

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Um genau diese geht es ja.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
int foo(int x) {
  constexpr int shift = 6 - 13;
  if constexpr(shift < 0) {
    return x >> -shift;
  } else {
    return x << shift;
  }
}

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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Walter T. (nicolas)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

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

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

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> gerade auf für templates

templates? In C?

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

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Daniel A. schrieb:

> Warnung -Wshift-count-negative, option zum ausschalten folglich
> -Wno-shift-count-negative.

Das zählt natürlich nicht. Damit deaktivierst du ja das komplette 
Potential dieser Warnung, auf echte (potentielle) Probleme hinzuweisen.

Das ist etwa als wenn du als Workaround für eine quietschende Bremse das 
Bremssystem komplett deaktivierst. Ja klar, die Bremse quietscht dann 
ganz sicher nicht mehr, aber das Auto knallt möglicherweise gegen die 
nächste Wand...

> Das er warnt ist aber klar falsch. Ein false
> positive.

Also doch ein BUG. Das ist der Punkt. Wir haben es bei der statischen 
Codeanalyse nicht mit einer Heuristik zu tun. Wenn sie korrekt 
implementiert wäre, hätte sie herausbekommen MÜSSEN, das hier kein 
erkennbares Problem vorliegt und dementsprechend kein Anlaß für eine 
Warnung vorliegt.

Andererseits müßte sie allerdings auch IMMER eine Warnung ausgeben, 
wenn eine signed-Variable als Quelle für die Bitzahl des Shift dient, 
wenn sie NICHT schon zur Compile-Zeit auflösbar ist. Denn dann hat sie 
schließlich immer das Potential, zur Laufzeit negativ zu werden...

Allerdings würde dann bei sehr vielen Anwendungen der Programmierer mit 
Warnungen geradezu geflutet.

Das eigentliche Problem ist also das absolut unlogische Design dieser 
verschissenen Dreckssprache. Logisch wären zwei Varianten gewesen:

1) Ich akzeptiere negative Shifts und setze sie halt als positive Shifts 
in die Gegenrichtung um.
2) Ich verbiete grundsätzlich signed Parameter für den Shift.

Alles andere ist unlogischer Dreck. Also genau das, was C macht und 
weswegen ich C so abgrundtief hasse...

Autor: Walter T. (nicolas)
Datum:

Bewertung
7 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Walter T. schrieb:

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

Doch: Ich hasse es, weil ich die Schwächen kenne, bin aber viel zu oft 
gezwungen, es zu benutzen. Ja, das (Erwerbs-)Leben ist halt kein 
Ponyhof.

Wenn das kein Grund ist, was denn sonst?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
5 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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? :-)

Autor: Veit D. (devil-elec)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
int foo(int x) {
  const int shift = -1*(6-13);
  if (shift < 0) {
    return (x << shift); 
  } 
  else {
    return (x >> shift);        
  }
}

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Also ich bekomm die Warning ganz einfach weg, also als Workaround:
static inline int yshift (int x, int shift)
{
    if (shift < 0) {
        return x >> -shift;
    } else {
        return x << shift;
    }
}

int foo(int x) {
    const int shift = 6 - 13;
    return yshift (x, shift);
}

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).

Autor: Brrrz (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jedesmal wenn jemand vorzeichenbehaftete Werte schiebt, sollte 
eigentlich sein Bürostuhl unter Strom gesetzt werden. Leider konnte ich 
diese Policy in der Firma noch nicht etablieren.

Autor: A. K. (prx)
Datum:

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

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: leo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Zuerst gab es halt div. CPUs und Assembler. Es ist egal ob du Shiftweite 
+ Richtung oder ein Vorzeichen kodierst. Ersteres is halt klarer. Da 
kann man das ganze auch gleich gut benennen:

  LSL - logical shift left
  LSR - logical shift right
  ASR - arithmetic shift right

Besonders letzteres verkompliziert die Schieberei.

leo

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Brrrz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Außerdem spart man Logik, wenn
> man das Zweierkomplement nicht decodieren muss - schieben ist nicht
> addieren.

Exakt.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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++.

Autor: 900ss D. (900ss)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> und damit wären wir bei templates in C++

du wirst langweilig.

Autor: A. K. (prx)
Datum:

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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Peter D. (peda)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wir wärs mit:
int foo(int x) {
    const int shift = 6 - 13;
    if (shift < 0) {
        return x >> (unsigned)-shift;
    } else {
        return x << shift;
    }
}

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.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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 
;-)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Unleserliche Programme lassen sich in jeder Programmiersprache verfassen 
…

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: DPA (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Aber in keiner geht es besser als in Whitespace, da sieht man Garnichts.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> einen Gleichstand herbeizuführen

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

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Wilhelm M. schrieb:
> Dabei könnte man doch gerade an diesem einen zufälligen Punkt anfangen,
> etwas cherry-picking zu machen, indem man beides zusammen führt.

Vor allem weil das geradezu nach templates schreit... inline+template 
ist der perfekte Ersatz für viele Makros. Ein anderes Beispiel dafür 
sind die min/max-Funktionen - die lassen sich mit Makros nicht so toll 
bauen.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernd K. schrieb:
> 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.

Wer da sein eigenes Süppchen kochen möchte, muss das eben selbst pflegen 
und die entsprechenden 7 Zeilen da hinein kopieren. Alle anderen welche 
den 0815-Standard-Startup-Code aus Beispielen oder Projekt-Templates 
verwenden müssen da gar nix tun.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Weil das was es macht in C nicht gebraucht wird? Warum soll ich
> Sonderlocken für C++ einbauen die gar nicht genutzt werden?

Zirkuläre Argumentation? "Ich kann C++ nicht benutzen weil ich dafür 
meinen Startupcode anpassen muss was nicht nicht brauche weil ich C++ 
nicht benutze"

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 …

: Bearbeitet durch Moderator
Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd K. schrieb:
> Eine neutrale Tatsachenfeststellung vielleicht

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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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!

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bernd K. schrieb:
> penetrant wie verzweifelte Staubsaugervertreter

 sehr schön gesagt :)

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Du meinst Attribut constructor?

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Holm T. (holm)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> 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.

Deine Argumentation kommt mir bekannt vor, so hast Du mich zum Natsieh 
gemacht.

Gruß,

Holm

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

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

Autor: Holm T. (holm)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Rolf M. schrieb:
> 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.

Jörg war schneller, das was Du da zitierst ist noch nicht so alt und ich 
bin nach wie vor der Überzeugung das ich damit nicht falsch liege.

Schicke mir ne PN wenn Du weiter zanken willst.

@Bernd: Nachdem Du Deine Befindlichkeiten wieder des langen und breiten 
ausgekippt und jeden 2. abgecancelt hast stören Dich nun andere User?
Ich sag mal dazu: Achwas. Tut mir unendlich leid.

Gruß,

Holm

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.