Discussion:
"Funktionsdefinitions-Block" ?
(zu alt für eine Antwort)
ha
2015-01-25 17:27:12 UTC
Permalink
Raw Message
Hallo

Mit fiel kein besserer Thread-Titel ein ;-)

Ich habe in einem Linux-Sourcecode ein Fragment gesehen, das
ich so noch nicht kannte:

Beispiel aus Linux/kernel/sched/idle.c:

void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
void __weak arch_cpu_idle_dead(void) { }
void __weak arch_cpu_idle(void)
{
cpu_idle_force_poll = 1;
local_irq_enable();
}


Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Thomas Rachel
2015-01-26 09:04:08 UTC
Permalink
Raw Message
Post by ha
Hallo
Mit fiel kein besserer Thread-Titel ein ;-)
Ich habe in einem Linux-Sourcecode ein Fragment gesehen, das
void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
void __weak arch_cpu_idle_dead(void) { }
void __weak arch_cpu_idle(void)
{
cpu_idle_force_poll = 1;
local_irq_enable();
}
Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Beim kernel kenne ich mich nicht aus, aber ich könnte mir vorstellen,
daß es z. B. bei Modulen oder anderen Pluginsystemen eine Mindestmenge
an Funktionen gibt, die vorhanden sein müssen und ohne die das Laden des
Plugins schlicht fehlschlägt.

Das __weak könnte zudem darauf hindeuten, daß das so eine Art
Default-Implementierung ist, die anderweitig überschrieben werden kann,
aber nicht muß.


Thomas
Helmut Schellong
2015-01-26 10:53:23 UTC
Permalink
Raw Message
Post by ha
Hallo
[...]
Post by ha
void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
void __weak arch_cpu_idle_dead(void) { }
void __weak arch_cpu_idle(void)
{
cpu_idle_force_poll = 1;
local_irq_enable();
}
Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Generell sind die ersten vier Dummy-Funktionen.

Ich habe auch schon sowas programmiert.
#if RELEASE == 1
int xiprintf(char const *f, ...) { ; }
#else //DEBUG
int xiprintf(char const *f, ...) { return iprintf(f); }
#endif

Es sind aber auch 'unsaubere' Tricks denkbar, die Ähnlichkeit
mit einem Array[1] am Ende einer Struktur haben.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Bonita Montero
2015-01-26 15:08:45 UTC
Permalink
Raw Message
Post by Helmut Schellong
Ich habe auch schon sowas programmiert.
#if RELEASE == 1
Das heißt richtigeweise
#if defined(NDEBUG)
Rainer Weikusat
2015-01-26 15:13:29 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Helmut Schellong
Ich habe auch schon sowas programmiert.
#if RELEASE == 1
Das heißt richtigeweise
#if defined(NDEBUG)
NDEBUG hat eine bestimmte Bedeutung im Zusammenhang mit assert und es
fuer andere Zwecke zu kapern ist eher ungeschickt.
Bonita Montero
2015-01-26 16:14:48 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Post by Bonita Montero
Post by Helmut Schellong
Ich habe auch schon sowas programmiert.
#if RELEASE == 1
Das heißt richtigeweise
#if defined(NDEBUG)
NDEBUG hat eine bestimmte Bedeutung im Zusammenhang mit assert und es
fuer andere Zwecke zu kapern ist eher ungeschickt.
Es ist aber üblich Debug/Release-Code davon abhängig zu machen,
auch wenn die C-Bibliothek das nur an der Stelle von assert nutzt.
Rainer Weikusat
2015-01-26 16:48:06 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Rainer Weikusat
Post by Bonita Montero
Post by Helmut Schellong
Ich habe auch schon sowas programmiert.
#if RELEASE == 1
Das heißt richtigeweise
#if defined(NDEBUG)
NDEBUG hat eine bestimmte Bedeutung im Zusammenhang mit assert und es
fuer andere Zwecke zu kapern ist eher ungeschickt.
Es ist aber üblich Debug/Release-Code davon abhängig zu machen,
auch wenn die C-Bibliothek das nur an der Stelle von assert nutzt.
Habe ich bis jetzt noch nirgends gesehen und selbst wenn man es unter
irgendwelchen Umstaenden fuer 'ueblich' ansehen koennte, halte ich es
immer noch fuer eine dumme Idee: assert ueberprueft (insofern man es
ueberhaupt benutzt) 'invariante Bedingungen' die so kritisch fuer den
Code, der es benutzt sind, dass im Falle von Nicht-Gegebenheit nur noch
ein Programm-Abbruch sinnvoll ist ('abort'). Das ist etwas vollkommen
anderes als ein Programm so zu uebersetzen, dass es zur Laufzeit mehr
Informationen ueber seine Taetigkeiten ausgibt.
Bonita Montero
2015-01-26 17:30:37 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Habe ich bis jetzt noch nirgends gesehen und selbst wenn man es unter
irgendwelchen Umstaenden fuer 'ueblich' ansehen koennte, halte ich es
immer noch fuer eine dumme Idee: assert ueberprueft (insofern man es
ueberhaupt benutzt) 'invariante Bedingungen' die so kritisch fuer den
Code, der es benutzt sind, dass im Falle von Nicht-Gegebenheit nur noch
ein Programm-Abbruch sinnvoll ist ('abort'). Das ist etwas vollkommen
anderes als ein Programm so zu uebersetzen, dass es zur Laufzeit mehr
Informationen ueber seine Taetigkeiten ausgibt.
assert wird aber unter Debug-Bedingungen einkompiliert - genauso wie
Debug-Ausgaben. Da macht es sinn beides vom selben Symbol abhängig
zu machen.
Helmut Schellong
2015-01-26 17:49:26 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Rainer Weikusat
Habe ich bis jetzt noch nirgends gesehen und selbst wenn man es unter
irgendwelchen Umstaenden fuer 'ueblich' ansehen koennte, halte ich es
immer noch fuer eine dumme Idee: assert ueberprueft (insofern man es
ueberhaupt benutzt) 'invariante Bedingungen' die so kritisch fuer den
Code, der es benutzt sind, dass im Falle von Nicht-Gegebenheit nur noch
ein Programm-Abbruch sinnvoll ist ('abort'). Das ist etwas vollkommen
anderes als ein Programm so zu uebersetzen, dass es zur Laufzeit mehr
Informationen ueber seine Taetigkeiten ausgibt.
assert wird aber unter Debug-Bedingungen einkompiliert - genauso wie
Debug-Ausgaben. Da macht es sinn beides vom selben Symbol abhängig
zu machen.
Nein, nein, nein.

assert() tut entweder nichts oder führt zwingend zum Abbruch des Programmes.
Das kann man oft nicht gebrauchen, zum Beispiel bei Mikrokontrollern.

Optionales definieren des Makros NDEBUG verhindert das Einkompilieren
aller assert().

Diese Funktionalität kann oft nicht genutzt werden.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Bonita Montero
2015-01-26 17:58:40 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Bonita Montero
assert wird aber unter Debug-Bedingungen einkompiliert - genauso wie
Debug-Ausgaben. Da macht es sinn beides vom selben Symbol abhängig
zu machen.
Nein, nein, nein.
assert() tut entweder nichts oder führt zwingend zum Abbruch des
Programmes. Das kann man oft nicht gebrauchen, zum Beispiel bei
Mikrokontrollern.
assert dient dem _Debuggen_ - daher heißt das Symbol ja auch NDEBUG.
Es unterbricht für gewöhnlich das Programm im Debugger (auf x86-PCs
normalerweise mit INT3). Daher ergibt es Sinn auch Debug-Code von
dem Symbol NDEBUG abhängig zu machen.
Rainer Weikusat
2015-01-26 18:32:41 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Helmut Schellong
Post by Bonita Montero
assert wird aber unter Debug-Bedingungen einkompiliert - genauso wie
Debug-Ausgaben. Da macht es sinn beides vom selben Symbol abhängig
zu machen.
Nein, nein, nein.
assert() tut entweder nichts oder führt zwingend zum Abbruch des
Programmes. Das kann man oft nicht gebrauchen, zum Beispiel bei
Mikrokontrollern.
assert dient dem _Debuggen_ - daher heißt das Symbol ja auch NDEBUG.
assert garantiert Invarianten. Insofern "dient" es (wenn es ueberhaupt
zu etwas dient) jemandem, der ein Programm benutzt, denn es erzwingt
einen Programm-Abbruch falls die korrekte Weiterausfuehrung desselben
nicht mehr moeglich ist. Zu dem Zeitpunkt als es erfunden wurde
(irgendwann zwischen UNIX(*) 6th ed und 7th ed) hielt es jemand fuer
sinnvoll, asserts via Compileroption global deaktvieren zu koennen,
mutmasslich 'aus Peformance-Gruenden'. Dafuer fuehrte er ein spezielles
Makro NDEBUG ein, das man via

cc -DNDEBUG ....

benutzten koennen sollte, um asserts zu deaktivieren. In dieser Form
existiert es seit 1979 und ist ausserdem auch set Anno Tobak
'Standard-C'. NDEBUG andere Bedeutungen unterszuschieben, koennte man
insofern berechtigt "mutwillige Programmierverwirrung" nennen, zumal
vollkommen unzusammenhaengende.
Post by Bonita Montero
Es unterbricht für gewöhnlich das Programm im Debugger (auf x86-PCs
normalerweise mit INT3).
Es ist (mittlerweile) so definiert, dass es abort aufruft. Das loest
'gewoehnlich' (lediglich fuer eine Gewohnheit, die Dir nicht also solche
erscheint) ein SIGABRT (6) aus, was einen Programm-Abbruch sogar dann
erzwingt, wenn ein signal handler fuer dieses Signal definiert war.

ZB findet man sowas immer mal wieder in iOS Logausgaben und da
'debuggert' garantiert niemand ...
David Seppi
2015-01-26 18:40:09 UTC
Permalink
Raw Message
Post by Rainer Weikusat
Es ist (mittlerweile) so definiert, dass es abort aufruft. Das loest
'gewoehnlich' (lediglich fuer eine Gewohnheit, die Dir nicht also solche
erscheint) ein SIGABRT (6) aus, was einen Programm-Abbruch sogar dann
erzwingt, wenn ein signal handler fuer dieses Signal definiert war.
man 3 abort liest sich so als ob das an abort() und nicht am Signal
liegt (das wird von abort() ein zweites Mal geschickt, um den Prozeß
nach Beenden des signal handlers zu terminieren).
--
David Seppi
1220 Wien
Rainer Weikusat
2015-01-26 19:26:01 UTC
Permalink
Raw Message
Post by David Seppi
Post by Rainer Weikusat
Es ist (mittlerweile) so definiert, dass es abort aufruft. Das loest
'gewoehnlich' (lediglich fuer eine Gewohnheit, die Dir nicht also solche
erscheint) ein SIGABRT (6) aus, was einen Programm-Abbruch sogar dann
erzwingt, wenn ein signal handler fuer dieses Signal definiert war.
man 3 abort liest sich so als ob das an abort() und nicht am Signal
liegt (das wird von abort() ein zweites Mal geschickt, um den Prozeß
nach Beenden des signal handlers zu terminieren).
Ich hatte das so falsch in Erinnerung, dass SIGABRT vom Kernel speziell
gehandhabt wuerde. Dem ist allerdings nicht so, vgl

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdlib/abort.c;h=ffde8145dbeaf3a289a75f73f806fdfafa8bb633;hb=HEAD

Unter anderem impliziert das, dass assert speziell fuer 'Debugging'
nicht wirklich zu gebrauchen ist, weil es den Zustand eines Prozesses
recht kraeftig veraendert. Deswegen benutze ich in C-Programmen
normalerweise

*(int *)-1 = 0;

um ein "Stirb!" zu erzwingen.
Stefan Reuther
2015-01-26 18:21:28 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Rainer Weikusat
Habe ich bis jetzt noch nirgends gesehen und selbst wenn man es unter
irgendwelchen Umstaenden fuer 'ueblich' ansehen koennte, halte ich es
immer noch fuer eine dumme Idee: assert ueberprueft (insofern man es
ueberhaupt benutzt) 'invariante Bedingungen' die so kritisch fuer den
Code, der es benutzt sind, dass im Falle von Nicht-Gegebenheit nur noch
ein Programm-Abbruch sinnvoll ist ('abort'). Das ist etwas vollkommen
anderes als ein Programm so zu uebersetzen, dass es zur Laufzeit mehr
Informationen ueber seine Taetigkeiten ausgibt.
assert wird aber unter Debug-Bedingungen einkompiliert - genauso wie
Debug-Ausgaben. Da macht es sinn beides vom selben Symbol abhängig
zu machen.
In den Systemen, an denen ich beteiligt bin, gibt es kaum Korrelation
zwischen "asserts" und "Debug-Ausgaben".

Insbesondere haben wir noch nie Code mit deaktivierten Asserts
ausgeliefert, sehr wohl aber Code mit deaktivierten Debug-Ausgaben.

Es mag sinnvoll sein, ein Build-Profil zu haben (gerne "Release"
genannt), das mittels NDEBUG die Asserts totlegt und mittels einer
Handvoll weiterer #defines andere Debugfunktionalität, aber das alles
direkt bei der Entwicklung direkt untrennbar zu koppeln ("alles oder
nichts") erscheint mir nicht sinnvoll.


Stefan
Helmut Schellong
2015-01-26 15:40:50 UTC
Permalink
Raw Message
Post by Bonita Montero
Post by Helmut Schellong
Ich habe auch schon sowas programmiert.
#if RELEASE == 1
Das heißt richtigeweise
#if defined(NDEBUG)
Rainer Weikusat hat Deinen Irrtum bereits erklärt.

Ansonsten darf man in C jede beliebige Zeile #if XYZ == 1
schreiben, solange XYZ keine reservierte Zeichenkette einsetzt.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Rainer Weikusat
2015-01-26 13:46:46 UTC
Permalink
Raw Message
Thomas Rachel
Post by Thomas Rachel
Post by ha
Hallo
Mit fiel kein besserer Thread-Titel ein ;-)
Ich habe in einem Linux-Sourcecode ein Fragment gesehen, das
void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
void __weak arch_cpu_idle_dead(void) { }
void __weak arch_cpu_idle(void)
{
cpu_idle_force_poll = 1;
local_irq_enable();
}
Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Was soll er sein?

void do_nothing(void) { }

ist eine Funktion, die nichts tut, weil der zugehoerige Code-Block keine
Anweisungen enthaelt.
Post by Thomas Rachel
Beim kernel kenne ich mich nicht aus, aber ich könnte mir vorstellen,
daß es z. B. bei Modulen oder anderen Pluginsystemen eine Mindestmenge
an Funktionen gibt, die vorhanden sein müssen und ohne die das Laden
des Plugins schlicht fehlschlägt.
Das duerfte fuer Code, der Bestandteil des Schedulers ist, eher nicht
zutreffen.
Post by Thomas Rachel
Das __weak könnte zudem darauf hindeuten, daß das so eine Art
Default-Implementierung ist, die anderweitig überschrieben werden
kann, aber nicht muß.
Das ist sogar ganz sicher der Fall: Das arch_ steht fuer
'architecture'. Wie man den restlichen Namen entnehmen kann, handelt es
sich um einen generellen Satz von Operationen, die von
Architekturspezifischem Code fuer unbenutzte CPUs definiert werden
koennen, zB umschalten in einen 'Stromspar-Modus'.
G.B.
2015-01-26 15:28:38 UTC
Permalink
Raw Message
Post by Thomas Rachel
Beim kernel kenne ich mich nicht aus, aber ich könnte mir vorstellen,
daß es z. B. bei Modulen oder anderen Pluginsystemen eine Mindestmenge
an Funktionen gibt, die vorhanden sein müssen und ohne die das Laden des
Plugins schlicht fehlschlägt.
Das __weak könnte zudem darauf hindeuten, daß das so eine Art
Default-Implementierung ist, die anderweitig überschrieben werden kann,
aber nicht muß.
Der folgende Artikel scheint mir bzgl. __weak und leeren
Definitionen im gegebenen Zusammenhang recht hilfreich.
Der Linker spielt dabei eine größere Rolle als Erweiterungen
von C:
http://en.wikipedia.org/wiki/Weak_symbol
Helmut Schellong
2015-01-26 15:48:37 UTC
Permalink
Raw Message
[...]
Post by G.B.
Der folgende Artikel scheint mir bzgl. __weak und leeren
Definitionen im gegebenen Zusammenhang recht hilfreich.
Der Linker spielt dabei eine größere Rolle als Erweiterungen
http://en.wikipedia.org/wiki/Weak_symbol
Verwendungen #pragma weak und __attribute__((weak))
sind allerdings etwas ganz Anderes als der reservierte
Makroname (oder die compiler-spezifische Zeichenfolge) __weak.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Georg Bauhaus
2015-01-27 12:03:28 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by G.B.
http://en.wikipedia.org/wiki/Weak_symbol
Verwendungen #pragma weak und __attribute__((weak))
sind allerdings etwas ganz Anderes als der reservierte
Makroname (oder die compiler-spezifische Zeichenfolge) __weak.
Was denn?


Mehr auch hier:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14171.html

(Ich bin fast sicher, die Wikipedia könnte zum allgemeinen Nutzen
durch einen sachkundigen Hinweis ergänzt werden. Vorsorglich:
ohne den Buchmarkt zu schädigen.)
Helmut Schellong
2015-01-27 12:23:17 UTC
Permalink
Raw Message
Post by Georg Bauhaus
Post by Helmut Schellong
Post by G.B.
http://en.wikipedia.org/wiki/Weak_symbol
Verwendungen #pragma weak und __attribute__((weak))
sind allerdings etwas ganz Anderes als der reservierte
Makroname (oder die compiler-spezifische Zeichenfolge) __weak.
Was denn?
void __weak arch_cpu_idle_exit(void)

Vorstehendes kann C sein, falls __weak ein Makro ist.
(Man weiß es nicht, wenn nur diese Zeile Code bekannt ist.)

Einen Qualifizierer __weak jedoch kennt C nicht.
Das ist eine plattformspezifische Erweiterung.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Peter J. Holzer
2015-01-29 21:04:01 UTC
Permalink
Raw Message
Post by ha
Post by Georg Bauhaus
Post by Helmut Schellong
Post by G.B.
http://en.wikipedia.org/wiki/Weak_symbol
Verwendungen #pragma weak und __attribute__((weak))
sind allerdings etwas ganz Anderes als der reservierte
Makroname (oder die compiler-spezifische Zeichenfolge) __weak.
Was denn?
Die Frage habe ich mir auch gestellt.
Post by ha
void __weak arch_cpu_idle_exit(void)
Vorstehendes kann C sein, falls __weak ein Makro ist.
(Man weiß es nicht, wenn nur diese Zeile Code bekannt ist.)
Einen Qualifizierer __weak jedoch kennt C nicht.
Das ist eine plattformspezifische Erweiterung.
__attribute__ auch.

Und #pragma ist zwar als Mechanismus definiert, aber alle Pragmas, die
nicht mit STDC anfangen, sind implementation-defined, also auch #pragma
weak.

Somit gibt es auf dieser Ebene keine Unterschied: Alle drei sind
plattformspezifische Erweiterungen.

Es kann natürlich sein, dass diese Erweiterungen eine andere Semantik
haben - in diesem Fall wäre es aber nett, wenn Du sie erklärst (oder
Links zur relevanten Doku lieferst), statt mit einem lockeren "das ist
etwas ganz anderes" zu implizieren, dass jeder C-Programmierer diese
Erweiterungen kennen müsse.

hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | ***@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
Helmut Schellong
2015-01-30 12:04:20 UTC
Permalink
Raw Message
Post by Peter J. Holzer
Post by ha
void __weak arch_cpu_idle_exit(void)
Vorstehendes kann C sein, falls __weak ein Makro ist.
(Man weiß es nicht, wenn nur diese Zeile Code bekannt ist.)
[...]
Post by Peter J. Holzer
Somit gibt es auf dieser Ebene keine Unterschied: Alle drei sind
plattformspezifische Erweiterungen.
Es kann natürlich sein, dass diese Erweiterungen eine andere Semantik
haben - in diesem Fall wäre es aber nett, wenn Du sie erklärst (oder
Links zur relevanten Doku lieferst), statt mit einem lockeren "das ist
etwas ganz anderes" zu implizieren, dass jeder C-Programmierer diese
Erweiterungen kennen müsse.
Nur __weak könnte prinzipiell ein Makro sein, alle anderen Formen nicht.
Das meinte ich als Unterschied.
--
Mit freundlichen Grüßen
Helmut Schellong ***@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm
Stefan Reuther
2015-01-30 17:26:51 UTC
Permalink
Raw Message
Post by Helmut Schellong
Post by Peter J. Holzer
Post by ha
void __weak arch_cpu_idle_exit(void)
[...]
Post by Helmut Schellong
Post by Peter J. Holzer
Es kann natürlich sein, dass diese Erweiterungen eine andere Semantik
haben - in diesem Fall wäre es aber nett, wenn Du sie erklärst (oder
Links zur relevanten Doku lieferst), statt mit einem lockeren "das ist
etwas ganz anderes" zu implizieren, dass jeder C-Programmierer diese
Erweiterungen kennen müsse.
Nur __weak könnte prinzipiell ein Makro sein, alle anderen Formen nicht.
Das meinte ich als Unterschied.
Auch __attribute__ könnte prinzipiell ein Makro sein. Gerüchten zufolge
fordert der gcc bei __attribute__ zwei Klammerpaare, damit man die
Attribute mit '#define __attribute__(x)' totlegen kann.

Allerdings ist sowohl __attribute__ als auch __weak ein Bezeichner aus
dem für den Compiler reservierten Namensraum und ein konformes Programm
sollte daran nicht rumfummeln, ohne den Compiler genau zu kennen.


Stefan

ha
2015-01-26 18:16:08 UTC
Permalink
Raw Message
Danke für eure Antworten. Da bin ich also nicht
ganz allein damit, so ein Konstrukt noch nicht
gesehen zu haben ;-)
Claus Reibenstein
2015-01-26 21:28:05 UTC
Permalink
Raw Message
Wer ist "ha", und wo schrieb er das? Hier offensichtlich nicht.
Post by ha
Ich habe in einem Linux-Sourcecode ein Fragment gesehen, das
void __weak arch_cpu_idle_prepare(void) { }
void __weak arch_cpu_idle_enter(void) { }
void __weak arch_cpu_idle_exit(void) { }
void __weak arch_cpu_idle_dead(void) { }
void __weak arch_cpu_idle(void)
{
cpu_idle_force_poll = 1;
local_irq_enable();
}
Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Also ich sehe mindestens zwei Semikolons.

Leere Blockklammern heißt einfach: Diese Funktionen tun nix.

Gruß
Claus
ha
2015-01-27 15:36:16 UTC
Permalink
Raw Message
Post by Claus Reibenstein
Wer ist "ha", und wo schrieb er das? Hier offensichtlich nicht.
Hier isser
Post by Claus Reibenstein
Post by ha
Keine Semikolons und leere Blockklammern. Was
ist der Sinn?
Also ich sehe mindestens zwei Semikolons.
Das ungewohnte Konstrukt brachte mich auf eine falsche Spur.
Die sinnlose Bemerkung mit den Semikolons fiel mir auf als ich
den Beitrag schon abgesendet hatte. Da habe ich ihn kurzerhand
zurückgezogen und war gespannt, wie das mit der Auslieferung
(Verbreitung) sein würde. Denn zwischen Absenden und Zurückziehen
lag nicht einmal eine Minute.
Post by Claus Reibenstein
Leere Blockklammern heißt einfach: Diese Funktionen tun nix.
Ja. Aber das Konstrukt ist, zumindest für mich und einige andere hier,
ungewöhnlich.
Rainer Weikusat
2015-01-27 17:38:44 UTC
Permalink
Raw Message
[...]
Post by ha
Post by Claus Reibenstein
Leere Blockklammern heißt einfach: Diese Funktionen tun nix.
Ja. Aber das Konstrukt ist, zumindest für mich und einige andere hier,
ungewöhnlich.
Es ist insofern 'ungewoehnlich' als das Funktionen normalerweise etwas
tun sollen, allerdings ist der ungewoehnliche Teil Bestandteil von Linux
(das ist ein C-Programm fuer eine bestimmte Umgebung) und nicht von
C. Syntaktisch ist { } ein Anweisungsblock ('compound statement'). Das
ist syntaktisch definiert (6.8.2) als

{ block-item-list[opt] }

wobei [opt] (im Original ein Subscript) fuer 'optional' steht. Ein
leerer Block ist also ueberhaupt nicht 'ungewoehnlich'.
Loading...