On Tue, Aug 2, 2016 at 10:43 PM, Warren Young wrote:
> For example, VC++2013 lacked snprintf(), but VC++ has had _snprintf()
> since at least 2003. Much harder to work around are missing format
> specifiers, which were much improved by VC++2013 relative to prior versions.
>
On Aug 2, 2016, at 2:31 PM, Warren Young wrote:
>
> On Aug 2, 2016, at 9:06 AM, Ron W wrote:
>>
>> This makes me wonder what the benefit of staying with the C89 specification
>> instead of the C99 specification. Are there really still compilers in use
On Aug 2, 2016, at 9:06 AM, Ron W wrote:
>
> This makes me wonder what the benefit of staying with the C89 specification
> instead of the C99 specification. Are there really still compilers in use
> that don't implement C99?
Visual C++ didn’t get full C99 support until
On Aug 2, 2016 9:12 AM, "Richard Hipp" wrote:
>
> On 8/2/16, Ron W wrote:
> >
> > Are there really still compilers in use
> > that don't implement C99?
> >
>
> I still build Fossil on a circa-2002 iBook. (See section 4 of
>
On Tue, Aug 2, 2016 at 5:06 PM, Richard Hipp wrote:
> On 8/2/16, Johan Kuuse wrote:
> >
> > I would suggest adding the -Wextra flag
> > anyway, to trap a lot of other existing warnings, and more important,
> > future warnings.
> >
>
> I care more about bugs than
On 8/2/16, Ron W wrote:
>
> Are there really still compilers in use
> that don't implement C99?
>
I still build Fossil on a circa-2002 iBook. (See section 4 of
http://fossil-scm.org/fossil/doc/trunk/www/build.wiki). I do not know
if it implements C99 or not, but if I had
On Tue, Aug 2, 2016 at 8:00 AM, Stephan Beal wrote:
>
> As i rememeber it, sqlite3 won't compile with strict C89 mode because of
> its use of (long long), which is C99 (but is apparently implemented in all
> C compilers when not running in strict C89 mode).
>
This makes me
On 8/2/16, Johan Kuuse wrote:
>
> I would suggest adding the -Wextra flag
> anyway, to trap a lot of other existing warnings, and more important,
> future warnings.
>
I care more about bugs than warnigns. Has -Wextra ever found a bug in Fossil?
--
D. Richard Hipp
On Tue, Aug 2, 2016 at 2:00 PM, Stephan Beal wrote:
>
>
> On Tue, Aug 2, 2016 at 1:46 PM, Johan Kuuse wrote:
>
>> Thanks, now it works for both clang and gcc, with the added flags to
>> Makefile:
>>
>> TCCFLAGS =-DFOSSIL_DYNAMIC_BUILD=1
On Tue, Aug 2, 2016 at 1:46 PM, Johan Kuuse wrote:
> Thanks, now it works for both clang and gcc, with the added flags to
> Makefile:
>
> TCCFLAGS =-DFOSSIL_DYNAMIC_BUILD=1 -I/usr/local/include *-std=c89
> -Wall* -g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H
>
> Is there
Thanks, now it works for both clang and gcc, with the added flags to
Makefile:
TCCFLAGS =-DFOSSIL_DYNAMIC_BUILD=1 -I/usr/local/include *-std=c89 -Wall*
-g -O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H
Is there any special reason for *not* using the -Wextra and -Werror flags,
like this?
Please try again with the latest code from trunk.
On 8/2/16, Johan Kuuse wrote:
> Hi,
>
> In trunk (f475b943eb), I get a compiler warning when I use clang with the
> default Makefile:
>
>
> cc -I. -I./src -Ibld -DFOSSIL_DYNAMIC_BUILD=1 -I/usr/local/include-g
> -O2
Hi,
In trunk (f475b943eb), I get a compiler warning when I use clang with the
default Makefile:
cc -I. -I./src -Ibld -DFOSSIL_DYNAMIC_BUILD=1 -I/usr/local/include-g
-O2 -DHAVE_AUTOCONFIG_H -D_HAVE_SQLITE_CONFIG_H -O2 -pipe -o bld/fshell.o
-c bld/fshell_.c
./src/fshell.c:109:7: warning:
Cross-compiling for Windows using mingw32 gcc 4.8.2 ( -O3 -Wall ) I get:
./src/sqlite3.c: In function 'balance':
./src/sqlite3.c:57557:22: warning: array subscript is above array bounds
[-Warray-bounds]
pOld = apCopy[++j];
and
./src/th.c: In function 'Th_ListAppend':
./src/th.c:194:5:
14 matches
Mail list logo