mikrocontroller.net

Forum: Compiler & IDEs dtostrf: maximale Buffergröße?


Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich hatte einen Bug in einem AVR-Programm, Ursache ist dtostrf() bzw. 
meine Fehlinterpretation der Parameter. Ein float-Wert wurde doch größer 
als erwartet, der Buffer für dtostrf ist übergelaufen.

Aus der Doku zur avr-libc:
The dtostrf() function converts the double value passed in val into an 
ASCII representation that will be stored under s. The caller is 
responsible for providing sufficient storage in s.

The minimum field width of the output string (including the '.' and the 
possible sign for negative values) is given in width [...]

Jetzt frag ich mich: Was ist "sufficient storage"? Wie verwendet man die 
Funktion auf "sichere" Art und Weise? Gibts eine wirklich "maximale" 
Länge des Strings? Kann ich das sonstwie begrenzen?

Oder gibts überhaupt eine wesentlich bessere Funktion als dtostrf()?

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

Bewertung
0 lesenswert
nicht lesenswert
Eine rein analytische Angabe rein vom Angucken des Codes her ist
nicht ganz einfach. So überschlagsmäßig würde ich sagen, dass da
um die 100 Zeichen maximal rauskommen können.

Die Idee hinter dtostrf() ist, dass du den Wertebereich deiner
Argumente kennst. Unter der Ausgabe

23413418934189348192439812439812431243

kann sich dein Nutzer schließlich sowieso nicht viel vorstellen. ;-)

Wenn du den Wertebereich nicht genau kennst, dann hast du zwei
Möglichkeiten: entweder nimmst du dtostre(), oder snprintf() mit
einem Gleitkommaformat.  snprintf() gibt die Anzahl der Zeichen
zurück, die konvertiert werden würden. Man lässt es also zweimal
laufen, einmal mit einem viel zu kleinen Puffer, dann alloziert man
einen genügend großen und ruft es nochmal auf. Dann kannst du deinem
Nutzer auch stolz obige Zahl präsentieren. :-)

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort!

snprintf() möchte ich bewusst vermeiden.

Den Code hab ich mir auch angesehen, ist wirklich nicht ganz einfach zu 
verstehen...

Irgendwo hab ich einen "maximallänge" von 60 entdeckt. Dürfte mit der 
Beschränkung des Exponenten von float (AVR hat ja kein double) auf +/- 
40 zusammenhängen.

und dann ist da noch die (Assembler-) Funktion __ftoa_engine. Die 
liefert den Exponenten + die signifikanten Digits, und das dürften nicht 
mehr als 8 sein, jedenfalls gibts da ein char buf[9], wobei buf[0] die 
Flags beinhaltet...

Das mit dem Wertebereich ist auch so eine Sache: Eigentlich kenn ich den 
schon, wenn aber aufgrund eines Messfehlers ein Divisor plötzlich 
ziemlich klein wird...

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

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:

> snprintf() möchte ich bewusst vermeiden.

Ist dein Flash zu knapp?

Ansonsten ist das natürlich die elegantere Lösung.  Hab' mich früher
auch mit dtostrf() rumgeschlagen, würde ich heute vermeiden, wenn's
nur irgendwie geht.

> Irgendwo hab ich einen "maximallänge" von 60 entdeckt.

Ja, da steht aber dann weiter unten noch
ndigs += exp;

> Das mit dem Wertebereich ist auch so eine Sache: Eigentlich kenn ich den
> schon, wenn aber aufgrund eines Messfehlers ein Divisor plötzlich
> ziemlich klein wird...

Dann mach einen Wertebereichstest zuvor und ruf bei unerwarteten Werten
lieber dtostre() auf.  Desse Gesamtlänge ist überschaubar.

Autor: Peter II (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> Das mit dem Wertebereich ist auch so eine Sache: Eigentlich kenn ich den
> schon, wenn aber aufgrund eines Messfehlers ein Divisor plötzlich
> ziemlich klein wird...

man könnte ihn ja vor der ausgabe zurechtstutzen.

Autor: Karl H. (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:

Das Problem, das du entdeckt hast, hängt im Prinzip mit dem Exponenten 
zusammen.
Denn im Grunde macht eine Floating Point Ausgabe ab einer gewissen 
Anzahl x an Vorkommastellen keinen Sinn mehr. Ab dann ist es dann 
einfacher und auch für den Benutzer besser auf eine 
Exponentenschreibweise zurückzugreifen, wobei ich persönlich dann auch 
die wissenschaftliche Konvention bevorzuge, bei der der Exponent in 
1000-er Schritten wächst.

Leider kann dtostrf das nicht.

> Das mit dem Wertebereich ist auch so eine Sache: Eigentlich kenn ich den
> schon, wenn aber aufgrund eines Messfehlers ein Divisor plötzlich
> ziemlich klein wird...


Du musst dich sowieso von der Idee verabschieden, dass du Floating-Point 
rechnen kannst, ohne dich um so Kleinigkeiten wie Fehlerabfragen zu 
kümmern. Floating Point Rechnereien sind normalerweise gespickt mit 
diversen Epsilon Abfragen, um genau derartige Dinge auszuschliessen und 
frühzeitig abzufangen. Wer naiv an Floating Point rangeht, hat schon 
verloren. Floating Point korrekt einzusetzen, ist wesentlich schwieriger 
als das bischen Overflow-Behandlung in der Ganzzahlrechnerei.

http://www.validlab.com/goldberg/paper.pdf

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

Bewertung
0 lesenswert
nicht lesenswert
Karl Heinz Buchegger schrieb:
> Floating Point korrekt einzusetzen, ist wesentlich schwieriger als das
> bischen Overflow-Behandlung in der Ganzzahlrechnerei.

Auch wenn ich dir nicht gern widerspreche, hier aber schon.

Autor: Karl H. (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Karl Heinz Buchegger schrieb:
>> Floating Point korrekt einzusetzen, ist wesentlich schwieriger als das
>> bischen Overflow-Behandlung in der Ganzzahlrechnerei.
>
> Auch wenn ich dir nicht gern widerspreche, hier aber schon.

Ich finde den Abschnitt nicht mehr. Ich bin aber sicher, dass er mal in 
dem Paper "What every Computer Scientist should know about Floating 
Point" drinnen war.
Es ging um ein Beispiel, welches zeigt, dass Transitiviät nicht hielt. 
Die Ausgansgzahlen waren alle korrekt und in IEEE Floating Point exakt 
darstelltbar. Trotzdem kam eine naive Implementierung, ich glaube es war 
eine Dreiecksungleichung, zu einem falschen Ergebnis.
Im verlinkten Paper ist als Beispiel die Dreicksfläche angegeben, die im 
konkreten Beispiel anstelle eines korrekten Ergebnisses von 2.34 ein 
Ergebnis von 3.04 rausbringt.

Floating Point Arithmetik hat immer damit zu tun, Espilons zu 
berücksichtigen bzw. Formeln so umzustellen, dass die Fehler klein 
bleiben. Und das ist oft schwieriger als gedacht.


(Und ja. Ich hab mich mit solchen Problemen rumgeschlagen. In der 
Geometrie bleibt sowas nicht aus. Schleifende Schnitte sind ein 
Albtraum, leider aber nicht zu vermeiden wenn man boolsche Operationen 
machen will. Sind im Solid Modelling 2 Flächen, deren Flächengleichungen 
sich um E-12 unterscheiden als gleich zu behandeln, Ja oder nein. Welche 
der beiden Flächen ist die 'äussere', welche zb. Materialeigenschaften 
gelten?
Mein erster, naiver Ansatz in der Robotik, endete damit, dass die 
Robotergeometrie nach ca 200 Matrixmultiplikationen anfing zu 
explodieren. Das war so ziemlich das erste mal, dass es mir (und dem 
mich betreuenden Mathematiker) dämmerte, dass Floating Point ein bischen 
mehr ist, als einfach nur Multiplikationen und Divisionen 
hinzuschreiben)

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dass FP komplex sein kann, ist mir klar, das ist aber nicht unbedingt 
mein Problem. Eine ungenaue/falsche Berechnung ist eine Sache, ein 
buffer overflow eine andere.

Ich wäre schon zufrieden, wenn ich erkennen könnte ob meine Angaben 
width und precision ausreichen um die zahl darzustellen, ansonsten den 
buffer mit "***.**" zu füllen, damit man sofort sieht dass der Wert 
nicht darstellbar ist; aber keinen unnötigen Buffer verschwenden.

Kurz dachte ich daran, mich selbst mit __ftoa_engine herumzuschlagen, 
aber das Zeug kommt in den "exportierten" Headern gar nicht vor, ist 
scheinbar "for internal use only".

snprintf vermeide ich, weil ich eigentlich eh mein eigenes "mini-printf" 
habe, das nur ein subset des großen printf kann, dafür aber ein paar 
andere Nettigkeiten wie Binärzahlen.

natürlich kann ich mit Bereichsprüfungen in Kombination mit width prüfen 
ob das Ergebnis darstellbar ist, aber schön ist das nicht...

@Karl Heinz: Oh mann, ja, schleifende Schnitte... ich hab einige jahre 
lang eins der ersten 3D-CAD-Systeme betreut (I-deas von SDRC) und da war 
der "boolean operation failed" der Horror...

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo nochmal,

ich habe beschlossen, das selbst unter Zuhilfenahme von ftoa_engine() zu 
implementieren.

Eine Frage dazu: Kann mir jemand erklären was der sinn des Flags 
FTOA_CARRY ist?

in der ftoa_engine.h find ich den Kommentar "Carry was to master 
position."

Aus den Funktionen in der avr-libc welche auf ftoa_engine zugreifen, 
erschließt sich mir der Sinn leider auch nicht wirklich...

Danke, Michi

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> Ich wäre schon zufrieden, wenn ich erkennen könnte ob meine Angaben
> width und precision ausreichen um die zahl darzustellen, ansonsten den
> buffer mit "***.**" zu füllen, damit man sofort sieht dass der Wert
> nicht darstellbar ist; aber keinen unnötigen Buffer verschwenden.

So kompliziert ist das jetzt aber nicht, einen Wrapper um das originale 
dtostrf zu schreiben, der die Eingabedaten abprüft, und dann entweder 
"***.**" oder eben das Ergebnis von dtostrf zurückgibt.

Oliver

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> So kompliziert ist das jetzt aber nicht, einen Wrapper um das originale
> dtostrf zu schreiben, der die Eingabedaten abprüft, und dann entweder
> "***.**" oder eben das Ergebnis von dtostrf zurückgibt.

ganz ganz trivial ist es leider auch nicht. Aufgrund der Runderei (da 
kommt wieder das Epsilon ins Spiel) ist es nicht so einfach 
vorauszusagen, wieviele Stellen dtostrf benötigen wird.

Beispiel: keine Nachkommastellen (der Einfachheit halber), und eine 
Maximale Stellenanzahl von 4

es lässt sich also von 0 bis 9999 alles darstellen (Minus lass ich auch 
mal weg)

bedingung: val < 10000

Input: 9999.999999999999999999999999999999
Ergebnis: 100000 => Buffer overflow

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> bedingung: val < 10000
>
> Input: 9999.999999999999999999999999999999
> Ergebnis: 100000 => Buffer overflow

Hm. Warum zum einen "val < 10000" wahr sein soll, in folgenden der Wert 
dann doch zu 10000 aufgerundet wird, erschliesst sich mir jetzt nicht. 
Was passieren kann, ist, daß 9999.99999999999999999 fälschlicherweise 
als "***.**" dargestellt wird, mehr aber doch nicht.

Oliver

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Im Zweifel sepndiert man dem Buffer halt ein Byte mehr (im 
Beispiel für val < 10000 also 5 Bytes). Wenn es an dem einen Byte 
Ramverbrauch scheitern sollte, dann ist das Projekt sowieso zu sehr auf 
Kante genäht.

Oliver

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Michael Reinelt schrieb:
>> bedingung: val < 10000
>>
>> Input: 9999.999999999999999999999999999999
>> Ergebnis: 100000 => Buffer overflow
>
> Hm. Warum zum einen "val < 10000" wahr sein soll, in folgenden der Wert
> dann doch zu 10000 aufgerundet wird, erschliesst sich mir jetzt nicht.
> Was passieren kann, ist, daß 9999.99999999999999999 fälschlicherweise
> als "***.**" dargestellt wird, mehr aber doch nicht.
>
> Oliver

Sorry, schlechtes Beispiel

Input: 9999.999

ist ziemlich sicher < 10000

durch die Rundung die dtorstrf() durchführen wird, wird 10000 
zurückgeliefert

Sicher, gehen würde es schon irgendwie, mit vielen if()s und dynamischen 
epsilons und diesem und jenem. Aber schön ist es nicht.

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> durch die Rundung die dtorstrf() durchführen wird, wird 10000
> zurückgeliefert

Wenn dtorstrf das tatsächlich macht (warum sollte die Funktion runden?), 
ist das 1.) blöd ;) ,
und 2.) wie ich gerade schrieb, kostet das halt ein Byte im Puffer 
zusätzlich.

Oliver

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

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> ich habe beschlossen, das selbst unter Zuhilfenahme von ftoa_engine() zu
> implementieren.

Davon würde ich dir abraten.

__ftoa_engine() fängt nicht umsonst mit zwei Unterstrichen an: es
gehört zum implementation namespace. Da die implementation (in
diesem Falle die avr-libc) diese Funktion nicht dokumentiert, kannst
du dich auf das entsprechende API nicht verlassen: es kann von heute
auf morgen begründungslos geändert werden, wenn das innerhalb der
avr-libc sinnvoll erscheint oder auch komplett entfallen. (In einer
früheren Implementierung von dtostrf() gab es diese Funktion ja auch
noch nicht.)

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

Bewertung
0 lesenswert
nicht lesenswert
Oliver schrieb:
> Wenn dtorstrf das tatsächlich macht (warum sollte die Funktion runden?)

Weil printf() auch rundet und das im Allgemeinen gewünscht ist?

Wenn du "double x = 10000.;" eingibst, dann willst du garantiert
nicht, dass da 9999.999 angezeigt werden. Da die interne
Binärdarstellung aber nicht jede x-beliebige Dezimalzahl exakt
darstellen lässt, bleibt nichts anderes sinnvolles übrig, als bei
der Ausgabe zu runden.

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Michael Reinelt schrieb:
>> ich habe beschlossen, das selbst unter Zuhilfenahme von ftoa_engine() zu
>> implementieren.
>
> Davon würde ich dir abraten.
>
> __ftoa_engine() fängt nicht umsonst mit zwei Unterstrichen an: es
> gehört zum implementation namespace. Da die implementation (in
> diesem Falle die avr-libc) diese Funktion nicht dokumentiert, kannst
> du dich auf das entsprechende API nicht verlassen: es kann von heute
> auf morgen begründungslos geändert werden, wenn das innerhalb der
> avr-libc sinnvoll erscheint oder auch komplett entfallen. (In einer
> früheren Implementierung von dtostrf() gab es diese Funktion ja auch
> noch nicht.)

Ja eh, ich weiss. Allerschlimmstenfalls nehm ich halt den Assembler-Code 
von ftoa_engine.S

Aber die Funktion schaut so verlockend aus...

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

Bewertung
0 lesenswert
nicht lesenswert
Michael Reinelt schrieb:
> Allerschlimmstenfalls nehm ich halt den Assembler-Code von ftoa_engine.S

Ja, dazu würde ich dir eher raten.

Autor: Michael R. (fisa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Manno, diese avr-libc zu verstehen kostet ganz schön Hirnschmalz!

anyway, meine private ftoa-funktion ist fertig und in mein 
Spezial-printf eingebunden. Falles das wer brauchen kann:
/* from ftoa_engine.h */
#define  FTOA_MINUS  1
#define  FTOA_ZERO  2
#define  FTOA_INF  4
#define  FTOA_NAN  8
#define  FTOA_CARRY  16

int __ftoa_engine(double val, char *buf, unsigned char prec, unsigned char maxdgs);

static char *my_ftoa(char *buffer, const uint8_t size, const double value, const uint8_t width, const uint8_t prec, const uint8_t fill0)
{
    /* width is the total (maximum) field width */
    /* if width is zero, resulting string grows as needed up to <size> */
    /* prec is limited to 12 by caller */
    /* INF => ###.##, NAN => ---.-- according to width and prec */
    /* if output does not fit into width, it will be displayed as ###.## */
    /* we DO NOT reduce precision because of rounding issues */


    char result[9];
    int8_t exp = __ftoa_engine(value, result, 7, prec + 1);
    uint8_t flag = result[0];
    uint8_t sign = flag & FTOA_MINUS ? 1 : 0;

    int8_t len = (exp > 0 ? exp + 1 : 1);
    if (sign)
  len += 1;
    if (prec)
  len += prec + 1;

    if ((width && len > width) || len > size - 1)
  flag |= FTOA_INF;

    if (flag & (FTOA_NAN | FTOA_INF)) {
  char *p = buffer + size - 1;
  *p = '\0';
  char pad = (flag & FTOA_NAN) ? '-' : '#';
  uint8_t l = width ? width : prec ? prec + 2 : 1;
  uint8_t d = prec;
  while (l--) {
      *--p = d-- ? pad : '.';
  }
  return p;
    }


    char *p = buffer;

    int8_t pad = width > len ? width - len : 0;
    if (!fill0) {
  while (pad) {
      *p++ = ' ';
      pad--;
  }
    }

    if (sign)
  *p++ = '-';

    while (pad) {
  *p++ = '0';
  pad--;
    }

    int8_t ndigs = prec + 1 + exp;
    if ((flag & FTOA_CARRY) && result[1] == '1')
  ndigs--;
    if (ndigs < 1)
  ndigs = 1;
    else if (ndigs > 8)
  ndigs = 8;

    char c;
    int8_t n = exp > 0 ? exp : 0;
    do {
  if (n == -1)
      *p++ = '.';
  c = (n <= exp && n > exp - ndigs) ? result[exp - n + 1] : '0';
  if (--n < -prec)
      break;
  *p++ = c;
    } while (1);
    if (n == exp && (result[1] > '5' || (result[1] == '5' && !(flag & FTOA_CARRY)))) {
  c = '1';
    }
    *p++ = c;
    *p = '\0';

    return buffer;
}


damit kann ich mit dem Parameter <width> die Länge des Strings 
verläßlich beschränken, kann der Wert damit nicht dargestellt werden, 
wird "###.##" ausgegeben (im Prinzip wie INF also unendlich)

Was die Funktion auch macht, weil ich das oft brauche: NAN wird als 
"---.--" (angepasst an width und prec) ausgegeben.

ich arbeite gerne mit NAN um zu kennzeichnen dass ein Wert nicht 
verfügbar ist (Sensor ausgefallen, nicht aktiv, Messwert steht nicht zur 
Verfügung etc), das schöne ist dass sich NAN dann durch alle weiteren 
Berechnungen durchzieht, alle Zwischen- und Endergebnisse sind dann auch 
NAN, und das wird am Display oder im Logfile oder wo auch immer 
"elegant" ausgegeben.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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