From mint-bounce@lists.fishpool.fi Thu Dec 16 08:21:11 2004 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: <000c01c4e33f$95301e60$124bb280@ic.intranet.epfl.ch> From: =?iso-8859-15?Q?Philipp_Donz=E9?= To: References: <1103142976.4922.229.camel@fedora> Subject: Re: [MiNT] appl_getinfo(APGI_VERSION(=96)) implementation Date: Thu, 16 Dec 2004 08:19:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: philipp.donze@epfl.ch Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=3.8 tests=BAYES_00 X-Spam-Level: Hi, I'm just adding some concerns to the latest API improvements: > so, we get a new appl_getinfo_str() function: Please don't forget to specify the minimum length the user application should provide for each string! I know, it's ugly to predefine the length of each string, but if I didn't miss a mail, no one ever talked about this issue. How does the AES know how many bytes can be written to these strings? What happens if there appears an AES replacement with a very long name? :-) > I think that AES can put in the 3rd string a free string with all the > informations that may describe the AES, for example the version number, > the alpha/beta/release status, the target architecture, the compiler used, > the date of the compilation, etc... And how assure that the AES application allocated enough bytes to hold the whole string? Philipp