avr-libc-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [support #102994] problems using scanf and fgets, per


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] [support #102994] problems using scanf and fgets, perhaps because of malfuncton of malloc?
Date: Tue, 13 Apr 2004 12:31:45 +0200
User-agent: Mutt/1.2.5i

As Markus Floh wrote:

> What I've found out is that the function scanf and also fgets return
> values none-EOF even though no character was entered.  When calling
> ferror() it returns always value 16, since registering the device
> with fdevopen() but I don't know if this function is already
> implemented.  Even clearing the error flag with function clearerr()
> doesn't help. Does anyone know what this errorvalue of decimal 16
> means? Perhaps this may help.

See the documentation: currently, there is no notion of EOF in the
stdio input handling.  The get() function passed to fdevopen() is only
supposed to return -1 in case of an input error.

Thus, currently feof() will always return false.  ferror() will return
a non-zero value (apparently 16, as you noticed ;-) in case the most
recent call to a get() function returned -1.

This should probably be changed in the future.  I consider using
return value -2 for EOF, to remain consistent with the currently
described behaviour of returning -1 for an input error.

>  As said in Summary it could be possible that malloc has something
> to do with that, because I have recognized, that downloading a new
> software (clearing section data and bss) into the chip, doesnot
> clean the input data scanf returns, of course I know that malloc
> doesnot clean the requested data but it is some kind of suspect that
> scanf returns the same data entered before downloading, perhaps it
> is a problem between malloc and scanf.

I doubt malloc() is the problem.  Sure, if you chip erase/download new
code, the RAM contents is not affected by this, so you can still read
the old values in your next run.  That is a feature.  Anyway, since
the program is re-initialized, malloc() will start over from the
beginning, but of course, it will return you exactly the same memory
area as before under otherwise identical circumstances.

Perhaps you can send us a piece of code that illustrates your problem
more?

Alternatively, you might want to use the (German) GCC forum on
http://www.mikrocontroller.net/ for questions like this one.
-- 
J"org Wunsch                                           Unix support engineer
address@hidden        http://www.interface-systems.de/~j/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]