[Top][All Lists]

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

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

From: Bernard Fouché
Subject: Re: [avr-libc-dev] Please have a look at avr-libc patch #3750
Date: Mon, 05 Sep 2005 15:26:20 +0200
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Mudiaga Obada wrote:

I would rather have this "extra cost" of checking __opts than have
frustrated users fustrating you developers. So I would not even
deprecate fdevopen. If this "extra cost" is too expensive for someone
for whatever reasons, "they" could add a compile time option (configure
--without-fdevopen || configure --without-fdevopen2 ) that would remove
support for one or the other.
Backward compatibility is also, in embedded applications at least , a matter of size and speed. If a function is backward-compatible but takes more space or is slower, one may prefer the old one. Also I don't like the idea of spending time and size performing unnecessary tests all the day in applications because of BC confort for the programmer. I prefer to have conditionnal compilation then, and specify what kind of interface I want when installing avr-libc.

What about having arguments passed to put/get in such a way that an 'old' put would pop only 'c' and an uptodate one would pop 'c' & 'stream'? (this will fail with -mint8 I suppose..)

This way one will get a warning at compile time if using the old scheme, and if one wants a clean compile then it's time to look at what changed from a version of avr-libc to the other.


reply via email to

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