Probleme mit atof

Hast du mal 1.0 probiert?
Ist aber nur geraten.

Danke für die Idee, aber das Ergebnis ist das selbe.
Egal welchen Wert ich eingebe mit Punkt oder ohne der Wert liegt immer
in der Nähe von diesen Wert.
1 -> 1.626e+4
2 -> 1.638e+4
3 -> 1.645e+4
4 -> 1.651e+4
5 -> 1.654e+4

1.4241 -> 1.631e+4

Ich vermute das das eine Eigenart des Prozessor ist und mit der
Speicherverwaltung zusammen hängt.
Aber ich weiß es nicht.
Gruß Try

Welche avr-libc Version?

Die avr Version ist

avr-gcc (GCC) 3.3.2

Gruß
Try

Das ist die Compiler-Version, aber ich denke, Du hast die gleiche
avr-libc, die ich auch hier grad vor mir habe. Und bei der finde ich in
der stdlib.h (Version 1.14.2.3 vom 2004/03/08) folgenden Hinweis:

#if 0  /* not yet implemented */
[..]
extern double atof(const char *);
[..]
#endif

Damit wirst Du wohl wenig Erfolg haben. Du wirst Dir atof leider selber
bauen müssen.

Danke für den Hinweis und die Hilfe.
Dan muss ich die Vor und Nachkommastelle doch getrennt verarbeiten.

Gruß Try

Hoppla, Oldbug, schreibe mal bitte einen Bugreport dafür auf der
avr-libc Homepage.

Nein, atof() gibt's, sonst hätte es ja auch einen Linkerfehler
gegeben.  Ist am Ende ein Kurzschluß auf die Standardfunktion strtod()
(da es nur drei Assemblerbefehle sind, ist das sogar im gleichen
Sourcefile implementiert, d. h. wenn man strtod() benutzt, bekommt man
immer auch gleich atof() mit).

Wenn's unbedingt atof() sein soll, einfach vorerst mal im eigenen
Sourcecode entsprechend deklarieren.  Das Problem entsteht nur daraus,
daß in der Quelle atof() nicht deklariert ist, so daß der Compiler es
implizit als einen `int' zurückgebend annimmt.  (Darüber sollte er
eigentlich auch 'ne Warnung von sich geben...)

Danke für den Hinweis und die Hilfe.
Ich werde strtod() benutzen.
Ich habe nicht an diese Funktion gedacht.

Gruß Try

Der Bug ist im CVS repariert (sowohl im HEAD als auch im
avr-libc-1_0-branch).

Danke!

Gruß Try