Re: [avr-gcc-list] Re: [avr-libc-dev] Please have a look at avr-libc patch #3750

[Joerg Wunsch]

As Bernard Fouche wrote:

> >Errm, you'd still need to supply a dummy implementation for malloc()
> >anyway when using the floating-point versions.  ...

> Now why not have an alloca(3) in libc? Sure it is not the best way
> to manage dynamic memory but vfprintf/scanf are typicall
> applications where it is acceptable. And a functionning alloca() is
> always handy.

I was going to tell the same remark about alloca() as Björn did.

Anyway, that won't help much here.  Instead of using alloca(), I could
use an automatic variable then as well, as the size of the buffer is
fixed.  The only point in using malloc() was that it has minimal
protection against stack-heap collisions, and 40 bytes seemed to be
too heavy for me to allocate them off stack immediately.  If the
malloc() failes, the floating-point format in question is simply
skipped, but the application would not crash.

As malloc() was `in' there (from fdevopen()) anyway, it came in handy.

Of course, if there's consensus among the users that this is not
needed, and an additional 40 bytes on the stack are no big deal for
the floating-point versions, we could easily drop that completely, and
always allocate the buffer on the stack.


As Björn Haase wrote:

> We *are* already having a working alloca. It's within gcc. Only
> thing that you need is an appropriate function declaration.

That sounds like a good idea.


As Bernard Fouche wrote:

> >   . The get backend function can now return -2 to indicate an
> >     end-of-file condition, in addition to -1 for an error condition.
> >     This will affect the internal state that can be queried using
> >     the standard feof() and ferror() functions.

> The documentation says "#define EOF (-1)" which is more
> usual I think.

Nope, EOF is the user-visible EOF/error indication.

The above is talking about the internal backend function.  Their -1 or
-2 return code will subsequently translated into the __SERR or __SEOF
flags inside struct __file, which can then be queried using the
standardn feof() or ferror() functions.

I agree there'd better be macros for this, but how to name them?

#define _FDEV_ERR (-1)
#define _FDEV_EOF (-2)

Sounds OK?

> >   . A new macro fdev_setup_stream() is provided to setup a
> >     user-supplied stream without the need to call fdevopen(), ...

> In the example code using fdev_setup_stream(), I would put the macro
> call outside of a body function.

fdev_setup_stream() works like a function, so it needs to be called
inside a function body.  But you're right, the initializer macro
you've been been proposing also has some merit, so I'll add that one,
too.


As Dmitry K. wrote:

> > I disagree.  I don't want to poison our interface spec with
> > non-protoype function declarations.  After all, this is the year
> > of 2005, and non-prototype function decl's have been deprecated in
> > 1989.

> I agree with your remark. Nevertheless, it is possible to avoid an
> old C-code rewriting. It is needed to place into 'stdio.h' 2
> definitions, old:

extern FILE *fdevopen(int (*__put)(char), int (*__get)(void),
                      int __opts);

> and new:

extern FILE * new_fdevopen (int (*__put)(char, FILE*),
                            int (*__get)(FILE*), int __opts);

That gets me an idea.  How about the following:

#ifdef __STDIO_FDEVOPEN_COMPAT_12
/* discontinued version */
extern FILE *fdevopen(int (*__put)(char), int (*__get)(void),
                      int __opts);
#else
/* version of avr-libc 1.4 and above */
extern FILE *fdevopen(int (*__put)(char, FILE*),
                            int (*__get)(FILE*));
#endif

As you can see, I'd also dropped the unused __opts.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)