C-Funktion verstehen

(unsigned long)(~1);

ist in binärer Schreibweise 11111111111111111111111111111110, also 
4294967294 dezimal. Mit

ulNewPosition &= (unsigned long)(~1);

wird also das niedrigste Bit in ulNewPosition gelöscht.

Stefan

Wie Dussel sagt: diese Funktion bewirkt rein gar nichts.

Ralf schrieb:
>

1

> 

2

> void stepper_set_soll_position (unsigned long ulNewPosition, unsigned 

3

> char ucMotor)

4

> {

5

>   ulNewPosition &= (unsigned long)(~1);

6

> 

7

>   ucMotor &= 1;

8

> }

9

> 

10

>

So wie die Funktion implementiert ist, macht sie vom Ergebnis her genau 
gar nichts.

Es gibt drei sinnvolle Möglichkeiten:

1.) Entweder die Variablen ulNewPosition und ucMotor sind global 
deklariert. Dann ergibt es keinen Sinn, sie der Funktion auch noch zu 
übergeben.

2.) Oder man übergibt der Funktion die Adressen der Variablen, die 
anderswo deklariert sind. Dann brauchen sie nicht global zu sein und man 
kann per Derefenzierung auf sie zugreifen.

3.) Oder man übergibt die Variablen an die Funktion, so wie hier, so 
dass sie auf dem Stack liegen. Dann sollte die Funktion aber auch etwas 
zurückgeben und nicht als void deklariert sein.

Die übergebenen Variablen landen auf dem Stack, werden dann wie auch 
immer verändert und dann weggeschmissen. Ein guter Compiler optimiert 
die gesamte Funktion einfach weg.

Joe F. schrieb:
> Wie Dussel sagt: diese Funktion bewirkt rein gar nichts.

Mit etwas Grips könnte man sich leicht denken, daß er nur die ihm 
unverständlichen Zeilen gepostet hat.
Vollständige Funktionen sieht man hier nur sehr selten.

Das Optimum wäre gewesen, die fraglichen Zeilen im Beitrag zu zitieren 
und den kompletten, echten Code als Anhang.

Peter D. schrieb:
> Joe F. schrieb:
>> Wie Dussel sagt: diese Funktion bewirkt rein gar nichts.
>
> Mit etwas Grips könnte man sich leicht denken, daß er nur die ihm
> unverständlichen Zeilen gepostet hat.

Das ändert doch aber nichts daran, dass die Funktion so nicht 
funktioniert.

S. S. schrieb:
> (unsigned long)(~1);
>
> ist in binärer Schreibweise 11111111111111111111111111111110, also
> 4294967294 dezimal. Mit
>
Bist du dir sicher ?

Die Ziffer 1 ist erst einmal ein integer der bitweise negiert wird und 
wenn du den auf einen long castest wird er mit mit 0 und nicht mit 1 
vorne aufgefüllt.

Hans-Georg L. schrieb:
> Die Ziffer 1 ist erst einmal ein integer der bitweise negiert wird und
> wenn du den auf einen long castest wird er mit mit 0 und nicht mit 1
> vorne aufgefüllt.

"sign expansion", anyone?

Hans-Georg L. schrieb:
> Die Ziffer 1 ist erst einmal ein integer der negiert wird und wenn du
> den auf einen long castest wird er mit mit 0 und nicht mit 1 vorne
> aufgefüllt.

Guter Einwand, so ists richtig:

1

~(unsigned long)1

oder

1

~1UL

Hans-Georg L. schrieb:
> Die Ziffer 1 ist erst einmal ein integer der negiert wird und wenn du
> den auf einen long castest wird er mit mit 0 und nicht mit 1 vorne
> aufgefüllt.

Das klingt erstmal logisch, ein Versuch belehrt mich aber eines 
besseren:

1

#include <stdio.h>

2

#include <stdint.h>

3

4

int main()

5

{

6

    printf ("sizeof(int):  %ld\n", sizeof(int));

7

    printf ("sizeof(long): %ld\n", sizeof(long));

8

9

    printf ("%x\n", ~1);

10

    printf ("%lx\n", ~1L);

11

    printf ("%lx\n", (unsigned long)(~1));

12

    printf ("%lx\n", (unsigned long)(~1U));

13

    return 0;

14

}

1

$ cc a.c && ./a.out

2

sizeof(int):  4

3

sizeof(long): 8

4

fffffffe

5

fffffffffffffffe

6

fffffffffffffffe

7

fffffffe

Es liegt an der Sign-Extension, dass "(unsigned long)(~1)" trotzdem 
funktioniert. Rufus hatte den richtigen Riecher.

Ich finde es interessant, wie hier so gerne auf Details der 
Implementierung herumgeritten wird, wenn das ganze Code-Beispiel an sich 
Müll ist und entsorgt gehört. ;-)

Mark B. schrieb:
> Ich finde es interessant, wie hier so gerne auf Details der
> Implementierung herumgeritten wird, wenn das ganze Code-Beispiel an sich
> Müll ist und entsorgt gehört. ;-)

Ich finde es eher interessant, dass Du einen Auszug aus einer Funktion 
nicht akzeptierst und darauf herumreitest. Es ging darum, was eine 
einzelne Zeile bewirkt und nicht darum, was eine ganze Funktion bewirkt.

Der Korinther bist Du, nicht die anderen.

Hans-Georg L. schrieb:
> S. S. schrieb:
>> (unsigned long)(~1);
>>
>> ist in binärer Schreibweise 11111111111111111111111111111110, also
>> 4294967294 dezimal. Mit
>>
> Bist du dir sicher ?
>
> Die Ziffer 1 ist erst einmal ein integer der bitweise negiert wird und
> wenn du den auf einen long castest wird er mit mit 0 und nicht mit 1
> vorne aufgefüllt.

C99 § 6.3.1.1:
> 1 When a value with integer type is converted to another integer type
>   other than _Bool, if the value can be represented by the new type,
>   it is unchanged.

"1" ist vom Typ "int", also signed, und deshalb auch "~1", also ist "~1" 
negativ (-2), also kann dieser Wert in "unsigned long" nicht 
repräsentiert werden.

> 2 Otherwise, if the new type is unsigned, the value is converted by
>   repeatedly adding or subtracting one more than the maximum value
>   that can be represented in the new type until the value is in the
>   range of the new type.

Dieses Verfahren impliziert, dass ein kleinerer Typ mit dem 
Vorzeichen-Bit aufgefüllt wird, d.h., das Ergebnis ist das selbe wie bei 
"(unsigned long)-2".

Frank M. schrieb:
> Mark B. schrieb:
>> Ich finde es interessant, wie hier so gerne auf Details der
>> Implementierung herumgeritten wird, wenn das ganze Code-Beispiel an sich
>> Müll ist und entsorgt gehört. ;-)
>
> Ich finde es eher interessant, dass Du einen Auszug aus einer Funktion
> nicht akzeptierst und darauf herumreitest. Es ging darum, was eine
> einzelne Zeile bewirkt und nicht darum, was eine ganze Funktion bewirkt.
>
> Der Korinther bist Du, nicht die anderen.

Man muss schon ziemlich blind sein oder ein völlig unfähiger 
Programmier, um den hier gezeigten Code in irgend einer Weise als 
sinnvoll zu bezeichnen.

Mark B. schrieb:
> Man muss schon ziemlich blind sein oder ein völlig unfähiger
> Programmier, um den hier gezeigten Code in irgend einer Weise als
> sinnvoll zu bezeichnen.

Es ging nicht um die Sinnigkeit/Unsinnigkeit. Aber wenn Du das so mit 
dem "unfähigen Programmierer" so siehst, akzeptiere ich das ;-)

Rufus Τ. F. schrieb:
> Hans-Georg L. schrieb:
>> Die Ziffer 1 ist erst einmal ein integer der bitweise negiert wird und
>> wenn du den auf einen long castest wird er mit mit 0 und nicht mit 1
>> vorne aufgefüllt.
>
> "sign expansion", anyone?

Du hast recht es wird eine negativer integer daraus. Aber solche 
Konstruktionen mit Mischmasch aus Artithmetik und Logig sind äusserst 
unübersichtlich ... Ein ~1UL hätte es auch getan.

Und wir wissen ja auch nicht was der Verfasser wirklich gewollt hat.

Frank M. schrieb:
> Mark B. schrieb:
>> Man muss schon ziemlich blind sein oder ein völlig unfähiger
>> Programmier, um den hier gezeigten Code in irgend einer Weise als
>> sinnvoll zu bezeichnen.
>
> Es ging nicht um die Sinnigkeit/Unsinnigkeit.

Wer sagt das?

Wenn Du in einem Code Review sitzt und eine völlig unsinnige Funktion 
entdeckst, sprichst Du dann über die Details der Implementierung? Oder 
sagst Du: "Diese Funktion ergibt so keinen Sinn. Bitte wegschmeißen und 
neu schreiben."

Hans-Georg L. schrieb:
> Und wir wissen ja auch nicht was der Verfasser wirklich gewollt hat.

Das ist richtig. Wenn es ihm aber nur um die bitweise Negation gegangen 
wäre, wäre es freilich intelligent gewesen auch nur diese Codezeile 
hinzuschreiben.

Mark B. schrieb:
> Wenn Du in einem Code Review sitzt und eine völlig unsinnige Funktion
> entdeckst, sprichst Du dann über die Details der Implementierung?

Es war offensichtlich, dass die Funktion nur in Auszügen abgebildet 
wurde. Das kann man unter Einsatz des Verstandes leicht erkennen.

Mark B. schrieb:
> Das ist richtig. Wenn es ihm aber nur um die bitweise Negation gegangen
> wäre, wäre es freilich intelligent gewesen auch nur diese Codezeile
> hinzuschreiben.

Er hat den Funktionskopf hingeschrieben, um die Typen der verwendeten 
Variablen anzuzeigen. Ohne diese Typdefinitionen wäre eine einzelne 
Zeile ziemlich unsinnig, oder?

Frank M. schrieb:
> Mark B. schrieb:
>> Wenn Du in einem Code Review sitzt und eine völlig unsinnige Funktion
>> entdeckst, sprichst Du dann über die Details der Implementierung?
>
> Es war offensichtlich, dass die Funktion nur in Auszügen abgebildet
> wurde.

Woraus schließt Du das? Der Themenersteller macht hierzu keine weiteren 
Angaben.

Mark B. schrieb:
> Woraus schließt Du das?

Kleinhirn an Großhirn:

 "Was soll diese Funktion? Diese ist unsinnig"

Großhirn an Kleinhirn:

 "Möglichkeit 1: Der User ist dumm und kann kein C"
 "Möglichkeit 2: Der User ist intelligient und reduziert den Code
  auf das Wesentliche"

Kleinhirn an Großhirn:

 "Dann hätte auch eine einzelne Zeile gereicht"

Großhirn an Kleinhirn:

 "Dann wären die Typen der Variablen (long oder int) nicht klar gewesen"

Ich habe mich für die Intelligenz des Users entschieden, Du für die 
Dummheit desselben.

Frank M. schrieb:
> Mark B. schrieb:
>> Woraus schließt Du das?
>
> Kleinhirn an Großhirn:
>
>  "Was soll diese Funktion? Diese ist unsinnig"
>
> Großhirn an Kleinhirn:
>
>  "Möglichkeit 1: Der User ist dumm und kann kein C"

Er hast selbst gesagt, dass seine C-Kenntnisse eingerostet sind. Und 
Dinge wie Bits setzen, Bits löschen und Bits negieren sind jetzt nicht 
unbedingt das, was ich als fortgeschrittene Themen in der 
C-Programmierung ansehen würde.

Edit:
Um diese Frage hier zu beantworten:

> und wofür könnte es gut sein in der Funktion?

sollte man dann schon die komplette Funktion vorliegen haben. Nicht 
anwesende Code-Teile zu raten ist immer schwierig ;-)

Frank M. schrieb:
> Mark B. schrieb:
>> Wenn Du in einem Code Review sitzt und eine völlig unsinnige Funktion
>> entdeckst, sprichst Du dann über die Details der Implementierung?
>
> Es war offensichtlich, dass die Funktion nur in Auszügen abgebildet
> wurde. Das kann man unter Einsatz des Verstandes leicht erkennen.

Die Überschrift heißt "C-Funktion verstehen", und dann wird eine 
C-Funktion hingeschrieben, die in ihrer so hingeschriebenen Gesamtheit 
keinen Sinn ergibt. Da finde ich nicht so offensichtlich, dass die 
Funktion an sich gar keine Relevanz haben soll.

Frank M. schrieb:
> Ich habe mich für die Intelligenz des Users entschieden, Du für die
> Dummheit desselben.

Intelligent ist, echten Code hinzuschreiben oder wenigstens Änderungen 
gegenüber diesem als solche zu markieren. Dann kann man sich viel 
Diskussion sparen.