tinycc-devel
[Top][All Lists]
Advanced

[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
time.

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 [,
      argument]...
);

It follows C ISO/IEC 9899:TC3

7.24.2.3 The swprintf function
Synopsis
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)
#endif
#endif

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

C.

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
lostgallifreyan
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)

>
>Anton,
>
>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
version
>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 ... */
>#else
>/* 0.9.29 or above, XXX is fixed for good */
>#endif
>#else
>/* ANSI C default behavior */
>#endif
>

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
address@hidden
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
----------------------------------------------------------------------------
-----------
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]