Kleine Byte-Buffer Lib

Schnitzel Gast 21.03.2014 18:28 #3584647

Lesenswert?

•

Hi,

hab hier ne kleine Lib geschrieben die einen Byte-Buffer verwaltet mit 
bis zu
255 Zeichen. Bei einem Bufferoverflow wird der Buffer auf null gesetzt.
Das war für meine Anwendung ausreichend. Es ging darum Nachrichten an 
den
UART mit Hilfe eines absolut minimalen Protokolls zu übertragen aka:
START + PARAM1 + PARAM2 + DATA + STOP
  1        1        1      ...     1

Vielleicht hilfts, vielleicht hat jmd. Verbesserungen. Danke

Gruß das Schnitzel

Angehängte Dateien:

buffer.c (3,16 KB) | Codeansicht
buffer.h (3,87 KB) | Codeansicht

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Schnitzel Gast 21.03.2014 18:30 #3584651

Lesenswert?

•

▲
▼

P.S.: Funktionen sind alle als Inline implementiert. Speicher spielte 
bei mir keine Rolle.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Marc P. (marcvonwindscooting) 21.03.2014 19:52 #3584761

Lesenswert?

•

▲
▼

Schnitzel schrieb:
> P.S.: Funktionen sind alle als Inline implementiert. Speicher spielte
> bei mir keine Rolle.

Warum dann nicht gleich noch der Schritt zu 'inline static'? Dann bist 
Du das *.c vollends los. Die Funktionen sind ja ganz handlich in der 
Groesse.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 21.03.2014 23:06 #3584986

Lesenswert?

•

▲
▼

Man kann es natürlich auch weg lassen. Der Compiler entscheidet ja 
mitlerweile selbstständig ob das inlining Sinn macht.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 21.03.2014 23:07 #3584987

Lesenswert?

•

▲
▼

Marc P. schrieb:
> Warum dann nicht gleich noch der Schritt zu 'inline static'? Dann bist
> Du das *.c vollends los. Die Funktionen sind ja ganz handlich in der
> Groesse
Auch eine Möglichkeit

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 22.03.2014 08:22 #3585141

Lesenswert?

•

▲
▼

Wenn er allerdings inlined, die Funktion jedoch NICHT static ist, dann 
behält er immer noch die "aufrufbare" (nicht-inline) Funktion im 
Speicher vor.

Deswegen macht es eigentlich nur Sinn, wenn man tatsächlich davon 
ausgehen will, dass sowas ge-inlined wird, "static inline" zu verwenden.

Dazu zwinge ich den Compiler noch gern zu inlinen, weil er das (wegen Os 
Optimierung beispielsweise) nicht selbst tun will:
__attribute__((always_inline)) für bspw. GCC

Das ganze noch in ein Makro

#define BYTE_BUFFER_INLINE static inline __attribute__((always_inline))

;-)

Übrigens, wenn sich nicht großartig was geändert hat am GCC 
(vorausgesetzt, der wird hier benutzt), dann ist Inlining NICHT möglich, 
wenn der Quellcode NICHT in der Header Datei steht.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 22.03.2014 09:40 #3585176

Lesenswert?

•

▲
▼

Okay. Vielen Dank. Wieder was gelernt.
Werde das so anpassen und alles in eine Headerdatei packen.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

nux Gast 22.03.2014 09:50 #3585190

Lesenswert?

•

▲
▼

Hi Schnitzel,

ich finde die Aufteilung in Header- und C-File gut. Das macht es schön 
übersichtlich.

Auch die Kapselung in einem Modul, welches nun universell eingesetzt 
werden kann, ist topp.

Was mich auf den ersten Blick stört ist die Verwendung von malloc() und 
free(). Ich habe mal gelernt, das malloc() und free() in (kleinen) 
Embedded Systems nix verloren haben.

Der Grund liegt einmal
- in Programmabläufen, welche zwar ein malloc() ausführen, den 
allokierten Speicher aber nicht mehr freigeben (Anwenderfehler, 
Sonderbehandlung, ...)
- und zweitens in der möglichen Fragmentierung des Speichers über die 
Laufzeit

Selbst getestet habe ich es aber nie.

Kann jmd. die Aussage bestätigen / widerlegen?

Gruß nux

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 22.03.2014 09:59 #3585197

Lesenswert?

•

▲
▼

So habs angepasst.

Angehängte Dateien:

buffer.h (5,53 KB) | Codeansicht
main.c (1,32 KB) | Codeansicht

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 22.03.2014 10:09 #3585209

Lesenswert?

•

▲
▼

nux schrieb:
> Was mich auf den ersten Blick stört ist die Verwendung von malloc() und
> free(). Ich habe mal gelernt, das malloc() und free() in (kleinen)
> Embedded Systems nix verloren haben.

Komme nicht aus dem Embedded Bereich, hab daher keine Erfahrung in der 
Hinsicht. Das grundlegende Problem von malloc() etc. pp. sind ja die 
Gefahren von möglichen Speicherlecks. Das ist zum. das was ich so 
mitbekommen habe.

Man kann natürlich die Funktion buffer_get und buffer_free entfernen 
bzw. belassen und eine buffer_init Funktion hinzufügen die den Puffer 
initialisiert.
Das war auch der Grund weshalb ich auf malloc und free zurückgegriffen 
hatte, um klar zu machen das der Puffer initialisiert werden muss in der 
buffer_get Funktion.

BUFFER_INLINE void_buffer_init(buffer_t *buffer)
{
    buffer->size    = 0;
    buffer->current = buffer->data;
}

Das hätte es mit Sicherheit auch getan. Vielleicht hat ja jmd. noch eine 
andere Idee.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 22.03.2014 10:15 #3585221

Lesenswert?

•

▲
▼

Angepasst

- malloc und free entfernt
- buffer_init() hinzugefügt
- Fehler in buffer_truncate behoben

Angehängte Dateien:

buffer.h (5,08 KB) | Codeansicht
main.c (1,33 KB) | Codeansicht

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Marc P. (marcvonwindscooting) 22.03.2014 12:45 #3585407

Lesenswert?

•

▲
▼

Oh Mannomann, jetzt werde ich kleinlich - verzeiht mir das...

Also in der struct gef"allt mir dein alignment nicht. Erstes Feld uint8, 
zweites Feld ein pointer (>1 byte! auf 'vielen' Architekturen).
Das packt kein Compiler vern"unftig :(
Geschickter w"are der Pointer als erstes.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 22.03.2014 13:03 #3585433

Lesenswert?

•

▲
▼

Marc P. schrieb:
> Oh Mannomann, jetzt werde ich kleinlich - verzeiht mir das...
>
> Also in der struct gef"allt mir dein alignment nicht. Erstes Feld uint8,
> zweites Feld ein pointer (>1 byte! auf 'vielen' Architekturen).
Seit wann ist sowas ein Problem?

> Das packt kein Compiler vern"unftig :(
Wieso das denn nicht? Ist doch völlig legitimes C. Dann ist der Compiler 
kaputt, wenn er das nicht automatisch alignen kann.

> Geschickter w"are der Pointer als erstes.
Und wieso?

PS: Jetzt werde ich kleinlich: Diese Missbrauchten Gänsefüßchen sind 
sehr schlecht zu lesen

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Dr. Sommer Gast 22.03.2014 13:09 #3585443

Lesenswert?

•

▲
▼

Simon K. schrieb:
>> Also in der struct gef"allt mir dein alignment nicht. Erstes Feld uint8,
>> zweites Feld ein pointer (>1 byte! auf 'vielen' Architekturen).
> Seit wann ist sowas ein Problem?
Seit es Architekturen mit Alignment-Requirements gibt. Also schon lange.
>> Das packt kein Compiler vern"unftig :(
> Wieso das denn nicht? Ist doch völlig legitimes C. Dann ist der Compiler
> kaputt, wenn er das nicht automatisch alignen kann.
Compiler können. Und verschwenden dabei unnötig ein paar bytes RAM.
>> Geschickter w"are der Pointer als erstes.
> Und wieso?
Damit man sich die Padding-Bytes spart.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Schnitzel Gast 22.03.2014 14:27 #3585547

Lesenswert?

•

▲
▼

Hi,

Habe das o.g korrigiert und eine Möglichkeit hinzugefügt mehr als 255 
Zeichen
zu puffern, wenn dies denn nötig ist. Man kann den Spass ja auch auf 
größeren
Systemen verwenden.

korrigiert.

- Pointer an den Anfang der Struktur verschoben
- Möglichkeit hinzugefügt mehr als 255 zeichen zu puffern
- Inline definition angepasst für externe configuration

Angehängte Dateien:

buffer.h (5,43 KB) | Codeansicht
main.c (1,42 KB) | Codeansicht

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 22.03.2014 15:29 #3585625

Lesenswert?

•

▲
▼

Dr. Sommer schrieb:
> Simon K. schrieb:
>>> Also in der struct gef"allt mir dein alignment nicht. Erstes Feld uint8,
>>> zweites Feld ein pointer (>1 byte! auf 'vielen' Architekturen).
>> Seit wann ist sowas ein Problem?
> Seit es Architekturen mit Alignment-Requirements gibt. Also schon lange.

Bitte? Der Compiler "packt es nicht vernünftig" (Zitat), wenn Padding 
bytes notwendig sind. Ist klar. Das es in bestimmten Fällen Speicher 
verschwenden kann ist klar.

>>> Das packt kein Compiler vern"unftig :(
>> Wieso das denn nicht? Ist doch völlig legitimes C. Dann ist der Compiler
>> kaputt, wenn er das nicht automatisch alignen kann.
> Compiler können. Und verschwenden dabei unnötig ein paar bytes RAM.

Ja also.

>>> Geschickter w"are der Pointer als erstes.
>> Und wieso?
> Damit man sich die Padding-Bytes spart.

Also geht es nur darum das eine oder andere Byte zu sparen. Das ist kein 
Grund einen Post mit "Mannomann" nach dem Motto: Was ist das denn für 
ein Müll, mit so vielen offensichtlichen Fehlern...

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Marc P. (marcvonwindscooting) 22.03.2014 16:24 #3585671

Lesenswert?

•

▲
▼

Simon K. schrieb:
> Grund einen Post mit "Mannomann" nach dem Motto: Was ist das denn für
> ein Müll, mit so vielen offensichtlichen Fehlern...

Okay ganz langsam. Ich war nicht deutlich genug. Das Mannomann bezog 
sich auf mich selbst, da ich gesehen hab, dass der Autor auf Vorschlaege 
eingeht und ich dann auch noch mit dem alignment komme.

packt war eine schlechte Wahl, wenn ich damit das englische 'pack' 
meine.
Sorry. Ich wollte nicht sagen, dass der Compiler davon abstuerzt sondern 
dass er viel Luft ins struct 'packt'.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Simon K. (simon) 22.03.2014 16:58 #3585718

Lesenswert?

•

▲
▼

Marc P. schrieb:
> Simon K. schrieb:
>> Grund einen Post mit "Mannomann" nach dem Motto: Was ist das denn für
>> ein Müll, mit so vielen offensichtlichen Fehlern...
>
> Okay ganz langsam. Ich war nicht deutlich genug. Das Mannomann bezog
> sich auf mich selbst, da ich gesehen hab, dass der Autor auf Vorschlaege
> eingeht und ich dann auch noch mit dem alignment komme.
>
> packt war eine schlechte Wahl, wenn ich damit das englische 'pack'
> meine.
> Sorry. Ich wollte nicht sagen, dass der Compiler davon abstuerzt sondern
> dass er viel Luft ins struct 'packt'.

Ah. Entschuldige bitte für das monströse Missverständnis :-)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Kleine Byte-Buffer Lib

Antwort schreiben