gcc Division negative int32 Zahl durch unsigned int32 ->Käse..

[Holm T. (Gast)]

..gerade einen Bug in meinem Programm gefunden, ich habe mich über 
seltsame Werte gewundert, diese mit einem Calculator nachgerechnet 
..alles Ok Hmm..

int32_t cval;
uint32_steilheit;

int32_t func(int32t aa,uint32_t steilheit)
{

int32_t cval;

[..]

     cval/=steilheit;
     return(cval);
}

liefert Blödsinn wenn cval vor der Division negativ ist, hätte ich nicht 
gedacht, ist aber klar mein Fehler, auch wenn der gcc (5.4.0) nicht 
warnt.
Ein cval/=(int32_t)steilheit; vertreibt das Problem.

Gruß,

Holm

[Dr. Sommer (Gast)]

Holm T. schrieb:
> auch wenn der gcc (5.4.0) nicht warnt.

Mal mit -Wconversion kompiliert?

[Jörg W. (dl8dtl) (Moderator)]

Dr. Sommer schrieb:
> Holm T. schrieb:
>> auch wenn der gcc (5.4.0) nicht warnt.
>
> Mal mit -Wconversion kompiliert?

$ cc -O -Wall -Wextra -Wconversion -c foo.c
foo.c: In function ‘func’:
foo.c:10:10: warning: conversion to ‘uint32_t {aka unsigned int}’ from ‘int32_t {aka int}’ may change the sign of the result [-Wsign-conversion]
      cval/=steilheit;
          ^
foo.c:10:12: warning: conversion to ‘int32_t {aka int}’ from ‘uint32_t {aka unsigned int}’ may change the sign of the result [-Wsign-conversion]
      cval/=steilheit;
            ^

Gut zu wissen.

[Dr. Sommer (Gast)]

Profis kompilieren immer mit

-Wall -Wextra -Wconversion -Werror -pedantic

;-)

[Holm T. (Gast)]

Dr. Sommer schrieb:
> Profis kompilieren immer mit
>

-Wall -Wextra -Wconversion -Werror -pedantic

> ;-)

Profi zu sein bedeutet das man damit Geld verdient, nicht das man es 
irgendwie gut macht.

HTH.

Holm

[Roland F. (rhf)]

Hallo,

>> Mal mit -Wconversion kompiliert?

und

> $ cc -O -Wall -Wextra -Wconversion -c foo.c

Meine Frage Frage gehört jetzt nicht so ganz zum Thema, aber ich würde 
gerne mal wissen wann bei der GCC die vollständigen Warnmeldungen 
eingeschaltet sind.
Mit -Wall sollte ja eigentlich umfassend gewarnt werden, aber es gibt da 
ja dann auch noch -Wextra (und wie im obigen Fall) -Wconversion und noch 
viele mehr. Warum ist das so und was an Warnstufen ist sinnvoll?

rhf

[(prx) A. K. (prx)]

Holm T. schrieb:
> Profi zu sein bedeutet das man damit Geld verdient, nicht das man es
> irgendwie gut macht.

Yep. Man könnte fast den Eindruck kriegen, dass sich das heutzutage 
ausschliesst. Wahrscheinlich verdient man so mehr Geld. Also wenn man 
erst den Pfusch verkauft, den man dann kostenpflichtig scheibchenweise 
verbessert und zum Ausgleich neuen Pfusch nachlegt.

[Dr. Sommer (Gast)]

Holm T. schrieb:
> Profi zu sein bedeutet das man damit Geld verdient, nicht das man es
> irgendwie gut macht.

Ich tue beides.

Roland F. schrieb:
> Warum ist das so
Es sind halt mit der Zeit immer mehr Warnungen hinzu gekommen. Nicht 
alle davon sind sinnvoll (-Wconversion ist schon sehr pingelig), aber da 
viele Projekte bereits -Wall nutzen wollte man damit nicht jede einzelne 
Warnung aktivieren.

[Holm T. (Gast)]

Dr. Sommer schrieb:
> Holm T. schrieb:
>> Profi zu sein bedeutet das man damit Geld verdient, nicht das man es
>> irgendwie gut macht.
>
> Ich tue beides.
>

Boah ehy!

> Roland F. schrieb:
>> Warum ist das so
> Es sind halt mit der Zeit immer mehr Warnungen hinzu gekommen. Nicht
> alle davon sind sinnvoll (-Wconversion ist schon sehr pingelig), aber da
> viele Projekte bereits -Wall nutzen wollte man damit nicht jede einzelne
> Warnung aktivieren.

-Wall ist auch bei mir der Standard.

Gruß,

Holm

[P.Loetmichel (Gast)]

Profis nehmen BASCOM!

Da wird immer richtig dividiert!

[Holm T. (Gast)]

Nun wissen wir wenigstens das D. Sommer immer BASCOM verwendet.

Gruß,

Holm

[Markus F. (mfro)]

P.Loetmichel schrieb:
> Profis nehmen BASCOM!
>
> Da wird immer richtig dividiert!

Aha. Und warum steht das da:

> Of course you are free to use different data types. The correct result is
> only guaranteed when you are using data types of the same kind or that
> result always can fit into the target data type.

im Handbuch?

[Walter K. (vril1959)]

P.Loetmichel schrieb:
> Profis nehmen BASCOM!
>
> Da wird immer richtig dividiert!

Ich dachte, dass wäre ( neben Pascal) eher so ne Sprache für 
Volkshochschul- und Seiteneinsteiger-Berufsschullehrer, denen C 
intellektuell zu anspruchsvoll erscheint
;-)

Duck und weg! ;-)

[M.A. S. (mse2)]

A. K. schrieb:
> Holm T. schrieb:
>> Profi zu sein bedeutet das man damit Geld verdient, nicht das man es
>> irgendwie gut macht.
>
> Yep. Man könnte fast den Eindruck kriegen, dass sich das heutzutage
> ausschliesst. Wahrscheinlich verdient man so mehr Geld. Also wenn man
> erst den Pfusch verkauft, den man dann kostenpflichtig scheibchenweise
> verbessert und zum Ausgleich neuen Pfusch nachlegt.

Ich stimme Euch zu.
Allerdings muss man auch sagen, dass, wenn man zu langsam ist bzw. nicht 
verspricht, sehr schnell zu sein, man viel Aufträge nicht bekommt, was 
dann eben dazu führt, dass jeder verspricht, schnell zu sein, was 
wiederum zu Pfusch führt...

[A. S. (Gast)]

Die Wahl der Integee-Typen ist und bleibt ein architektonisches 
Minenfeld.

UB beim Überlauf wenn signed, das Problem hier mit Division und noch 
schlimmer bei größer oder kleiner, integral Promotion oder %i, die nicht 
durch einfaches uint_xx portabel werden, ... Und das für all die Werte, 
die doch "sowieso eigentlich nie" größer 100 oder kleiner 0 werden....

[Stefan F. (Gast)]

Ich habe bei Java lange Zeit unsigned integer vermisst und hatte auch 
wenig Verständnis dafür, dass es keine Hardware-Spezifischen Integer 
Größen gab (zur Performance-Optimierung). Nach einigen Jahren Gewöhnung 
muss ich sagen, dass es so besser ist. Dadurch werden viele Fehler von 
vorne herein vermieden.

Was die Leute allerdings geraucht haben, neben dem einfachen integer 
auch Integer Objekte zu haben, anstatt einfach nur eins von beiden, das 
wüsste ich gerne mal.

[Holm T. (Gast)]

M.A. S. schrieb:
> A. K. schrieb:
>> Holm T. schrieb:
>>> Profi zu sein bedeutet das man damit Geld verdient, nicht das man es
>>> irgendwie gut macht.
>>
>> Yep. Man könnte fast den Eindruck kriegen, dass sich das heutzutage
>> ausschliesst. Wahrscheinlich verdient man so mehr Geld. Also wenn man
>> erst den Pfusch verkauft, den man dann kostenpflichtig scheibchenweise
>> verbessert und zum Ausgleich neuen Pfusch nachlegt.
>
> Ich stimme Euch zu.
> Allerdings muss man auch sagen, dass, wenn man zu langsam ist bzw. nicht
> verspricht, sehr schnell zu sein, man viel Aufträge nicht bekommt, was
> dann eben dazu führt, dass jeder verspricht, schnell zu sein, was
> wiederum zu Pfusch führt...

Ist vollkommen logisch weil die Folge von Damager Geschwafel: "Short 
Time to Market". Von Qualität reden die da nicht ansatzweise. Jeder 
Programmierer weiß das die letzten 10% des Codes 90% der Zeit benötigen. 
Hat man die nicht, entstehen zwangsläufig nur 10% des fertigen 
Produktes.

Gruß,

Holm

[Dr. Sommer (Gast)]

Stefanus F. schrieb:
> Was die Leute allerdings geraucht haben, neben dem einfachen integer
> auch Integer Objekte zu haben, anstatt einfach nur eins von beiden, das
> wüsste ich gerne mal.

Das ist ein Resultat aus der Entscheidung, dass alle Klassen nur per 
Referenz zugänglich sind (was Garbage Collection ermöglicht und die 
Programmierung vereinfacht), und damit auch die Integer Klasse. Wenn man 
nur diese hätte, wären Integer ziemlich ineffizient, aber manchmal 
braucht man sie. Scala, welches auf Java basiert, versteckt den 
Unterschied, hat aber auch beides.

[S. R. (svenska)]

Stefanus F. schrieb:
> Ich habe bei Java lange Zeit unsigned integer vermisst und hatte auch
> wenig Verständnis dafür, dass es keine Hardware-Spezifischen Integer
> Größen gab (zur Performance-Optimierung).

Wir haben auf Arbeit mit Bildern hantiert und damit natürlich mit 
Pixeln. Das Fehlen von "unsigned byte" störte da gewaltig, weil 
sämtliche minimalen Algorithmen zur Bildbearbeitung erstmal direkt auf 
die Fresse fallen. Außerdem macht es die Interaktion mit native code 
schwieriger.

Kotlin führt unsigned ein, was mich sehr freut. Noch ein Grund mehr.

[Zeno (Gast)]

P.Loetmichel schrieb:
> Profis nehmen BASCOM!
>
> Da wird immer richtig dividiert!

Och bei Pascal wird es auch richtig gemacht. C++ von Borland macht es 
auch richtig.
Ist wahrscheinlich wieder mal ein Feature von GCC.

[(prx) A. K. (prx)]

Zeno schrieb:
> C++ von Borland macht es auch richtig.

Welches Verhalten verstehst du konkret unter "richtig"?

Die Sprachstandards für C und C++ definieren eindeutig int/unsigned => 
unsigned und long/u_long => u_long. Das war sogar schon vor C89 so, als 
das Verhalten der integer promotion erstmals klar definiert wurde. 
Sollte das wirklich bei Borland anders sein?

Im seltenen Fall von 64-Bit int gilt allerdings int32/unsigned32 => 
int64 und das Vorzeichen bleibt erhalten. Analog dazu gilt bei 32-Bit 
int int16/u_int16 => int32. Das darf auch Borland.

[Jörg W. (dl8dtl) (Moderator)]

Zeno schrieb:
> Och bei Pascal wird es auch richtig gemacht.

… und zwar auf ganz elegante Weise: man hat im Standard gleich mal gar 
keine vorzeichenlosen Datentypen festgeschrieben. Damit musste man sich 
auch keine Standardisierung einfallen lassen, was man bei einer 
Operation macht, die eine vorzeichenbehaftete und eine vorzeichenlose 
Zahl miteinander kombiniert. All die "word", "cardinal" etc. sind dann 
compilerspezifische Erweiterungen, und damit ist es völlig egal, was sie 
tun: aus ihrer Sicht machen sie es natürlich immer "richtig". ;-)

Ehrlich gesagt ist mir da allerdings das Verhalten von C oder C++ 
lieber, bei denen der Standard das von vornherein vorgesehen und das 
Verhalten definiert hat.