[Top][All Lists]

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

RE: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)

From: Christian Jullien
Subject: RE: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)
Date: Fri, 22 May 2009 13:36:38 +0200

I fully disagree with you because we often *must* make decision at compile

Let's take an example with Tiny C.

swprintf takes sometimes (depending on compiler) the buffer size as second
parameter to prevent buffer overflow.

Currently, in Tiny C the prototype is:
swprintf (wchar_t*, const wchar_t*, ...);

While (for example) recent versions of MSC use

int swprintf(
   wchar_t *buffer,
   size_t count,
   const wchar_t *format [,

It follows C ISO/IEC 9899:TC3 The swprintf function
1 #include <wchar.h>
int swprintf(wchar_t * restrict s,
size_t n,
const wchar_t * restrict format, ...);

I'm not saying that tcc is wrong (it is not the topic) I say that, if a
future Tiny C version changes and add count argument you'll have to support
two different calls *AT COMPILE TIME*

#define WBUF_SIZE 256
wchar_t buf[WBUF_SIZE];

#if defined(__TINYC__)
#if (__TINYC__ == 1)
  /* no buffer size */
  swprintf(buf, L"test %d", 100)
#elif (__TINYC__ >= 926)
  /* prevent buffer overflow with buf count.
     It conforms to ISO/IEC 9899:TC3 */
  swprintf(buf, WBUF_SIZE, L"test %d", 100)

One *bad* solution is to add -D_TCC_V926 on user's makefile, if user changes
tcc version, he must edit its Makefile.


-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Sent: Friday, May 22, 2009 13:05
To: address@hidden
Subject: Re: Versioning (was Re: [Tinycc-devel] TCC 0.9.25 is out)

"Christian Jullien" <address@hidden> wrote:
(22/05/2009 11:16)

>It's ok to have a TCC_VERSION human readable but it's also *very* important
>to have computer readable cste to adapt code depending on a specific
>if you (or someone else) have to support different versions.
>#if defined(__TINYC__)
>#if (__TINYC__ == 1)
>/* 0.9.25 or below, XXX feature was missing, use YYY instead but with a
>lower precision */
>#elif (__TINYC__ >= 926 || __TINYC__ <= 928)
>/* XXX was implemented but hangs if argument is negative ... */
>/* 0.9.29 or above, XXX is fixed for good */
>/* ANSI C default behavior */

If an arithmetical comparison is to be made, why not first treat the value
as a string then strip out all but the digits and convert to number? It's
presumably not something that must be done often in fast loops so it won't
ask a lot to do that. It depends strongly on human conventions either way,
so I back Anton's point that the more humanly readable it is, the better. We
make machines to help us, no? The other way (along a rather far-fetched
continuum) lies the Borg, or the Matrix. :) More to the point, keeping
things as humanly readable as possible is the best way to avoid errors, and
to reduce over-familiar questions from newcomers.

Tinycc-devel mailing list
Orange vous informe que cet  e-mail a ete controle par l'anti-virus mail. 
Aucun virus connu a ce jour par nos services n'a ete detecte.

reply via email to

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