[sqlite] Compile warnings

of SQLite Database ; davidb at pfxcorp.com Subject: Re: [sqlite] Compile warnings On Aug 24, 2015 6:29 AM, "David Bennett" mailto:davidb at pfxcorp.com> > wrote: > > I think we've beaten the philosophy to death and we're largely in agreement. > > I'm not sure we

[sqlite] Compile warnings

t; sqlite-users at mailinglists.sqlite.org>; davidb at pfxcorp.com > > > *Subject:* Re: [sqlite] Compile warnings > > > > On Aug 24, 2015 6:29 AM, "David Bennett" wrote: > > > > I think we've beaten the philosophy to death and we're largely in > agreement. >

[sqlite] Compile warnings

] On Behalf Of Scott Robison Sent: Monday, 24 August 2015 8:25 AM To: davidb at pfxcorp.com; General Discussion of SQLite Database Subject: Re: [sqlite] Compile warnings On Sat, Aug 22, 2015 at 8:07 PM, David Bennett wrote: > Of course that is the aim, as always. > > > > In this

[sqlite] Compile warnings

ers-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott > Robison > Sent: Monday, 24 August 2015 8:25 AM > To: davidb at pfxcorp.com; General Discussion of SQLite Database > > Subject: Re: [sqlite] Compile warn

[sqlite] Compile warnings

On Sat, Aug 22, 2015 at 8:07 PM, David Bennett wrote: > Of course that is the aim, as always. > > > > In this particular case, maximally portable code (that will compile and > execute correctly on all conforming compilers) must (a) ensure that the > pointer argument is valid (b) ensure that the

[sqlite] Compile warnings

Robison [mailto:sc...@casaderobison.com] Sent: Sunday, 23 August 2015 2:22 AM To: General Discussion of SQLite Database ; davidb at pfxcorp.com Subject: Re: [sqlite] Compile warnings Unless of course your objective is to write maximally portable code. It's not perfect, and certainly things have

[sqlite] Compile warnings

On 8/22/15, Scott Robison wrote: > I don't object to a change to accommodate C99 null > pointer requirements Please note that the warning in question has nothing to do with NULL pointers. The pointer parameter (0) is non-null. The issue is that the last parameter (2) which is a size_t might

[sqlite] Compile warnings

On Sat, Aug 22, 2015 at 10:31 AM, Richard Hipp wrote: > On 8/22/15, Scott Robison wrote: > > I don't object to a change to accommodate C99 null > > pointer requirements > > Please note that the warning in question has nothing to do with NULL > pointers. The pointer parameter (0) is non-null.

[sqlite] Compile warnings

andl.org > > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org > [mailto:sqlite-users-bounces at mailinglists.sqlite.org] On Behalf Of Scott > Robison > Sent: Saturday, 22 August 2015 2:05 AM > To: General Discussion of SQLite Database > ; davi

[sqlite] Compile warnings

-bounces at mailinglists.sqlite.org] On Behalf Of Scott Robison Sent: Saturday, 22 August 2015 2:05 AM To: General Discussion of SQLite Database ; davidb at pfxcorp.com Subject: Re: [sqlite] Compile warnings And C89 doesn't have the valid pointer requirement On Aug 21, 2015 7:03 AM, "David Be

[sqlite] Compile warnings

You are right that the warning is wrong in the case that both are zero, I'm not sure if this is still the case in newer gcc versions since I only tried 4.8.*. I'm okay with keeping my local patch to disable the warning in my case and I can fully understand that adding a not necessary test to

[sqlite] Compile warnings

-bounces at mailinglists.sqlite.org] On Behalf Of Scott Robison Sent: Friday, 21 August 2015 3:05 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] Compile warnings On Thu, Aug 20, 2015 at 10:46 AM, Scott Doctor wrote: > My opinion is to keep it portable. The warn

[sqlite] Compile warnings

at mailinglists.sqlite.org] On Behalf Of Scott > Robison > Sent: Friday, 21 August 2015 3:05 AM > To: General Discussion of SQLite Database > > Subject: Re: [sqlite] Compile warnings > > On Thu, Aug 20, 2015 at 10:46 AM, Scott Doctor > wrote: > > > My opinio

[sqlite] Compile warnings

Hi, I fully understand that removing warnings and still staying portable is hard. I recently had my problems with removing warnings for C code from the Visual Studio which is a nightmare since the C support of the Visual Studio is really bad (mixed declarations only with MSVC >= 2013). However in

[sqlite] Compile warnings

On 20 Aug 2015 at 17:46, Scott Doctor wrote: > My opinion is to keep it portable. The warning is there for a reason. > you are worried about performance yet are calling a function that does > nothing, which will take more memory cycles than a simple check for zero. > > Trying to memset a zero

[sqlite] Compile warnings

It's not a bug. It actually comes from the warning -Wmemset-transposed-args which is active with -Wall and I had a short look that it seems to be that there were several bugs with false positives for this warning and as far as I can understand the gcc developers did not rule out to issue the

[sqlite] Compile warnings

Hi, the problem is that this is a warning generated by the linker to warn the user that he potential swapped the arguments which it does since 0 occurs more often on the value side and memset(*,0,0) actually does nothing. Cheers, -Bernhard 2015-08-20 16:17 GMT+02:00 Scott Robison : > I suspect

[sqlite] Compile warnings

Hi, the warning which is mentioned in the ticket f51d9501800de5a0fb69d5048ce6662981b461ec still occurs also with newer gcc versions. The ticket was closed after a gcc bug report was opened. The gcc bug was closed due to a missing testcase. I had a quick look at the problem and it seems that the

[sqlite] Compile warnings

On 8/20/15, Bernhard Schommer wrote: > Hi, > > the problem is that this is a warning generated by the linker to warn the > user that > he potential swapped the arguments which it does since 0 occurs more often > on > the value side and memset(*,0,0) actually does nothing. > My contention remains

[sqlite] Compile warnings

On Thu, Aug 20, 2015 at 10:46 AM, Scott Doctor wrote: > My opinion is to keep it portable. The warning is there for a reason. you > are worried about performance yet are calling a function that does nothing, > which will take more memory cycles than a simple check for zero. > I didn't say don't

[sqlite] Compile warnings

But does the simple solution of an if statement negatively impact performance? It may or may not, I really don't know. On the one hand, there is the overhead of the check for the condition. On the other, it avoids making a function call if the condition is false. On a third hand (I've run out,

[sqlite] Compile warnings

On 8/20/15, Bernhard Schommer wrote: > Hi, > > the warning which is mentioned in the ticket > f51d9501800de5a0fb69d5048ce6662981b461ec still occurs also with newer gcc > versions. The ticket was closed after a gcc bug report was opened. The gcc > bug was closed due to a missing testcase. > I had

[sqlite] Compile warnings

On Thu, Aug 20, 2015 at 9:35 AM, Bernhard Schommer < bernhardschommer at gmail.com> wrote: > It's not a bug. It actually comes from the warning -Wmemset-transposed-args > which is active with -Wall and I had a short look that it seems to be that > there were several bugs with false positives for

[sqlite] Compile warnings

My opinion is to keep it portable. The warning is there for a reason. you are worried about performance yet are calling a function that does nothing, which will take more memory cycles than a simple check for zero. Trying to memset a zero length is a bug, not the warning. Add an if statement

[sqlite] Compile warnings

Yeah, we saw this with Chromium, too. The patch we use is below. I'm with Dr Hipp that this is really more of a GCC issue. If it was literally a 0 constant, it would make sense to warn so that the code can be removed. But it's only a 0 if you optimize a certain way. -scott diff --git

[sqlite] Compile warnings

I suspect this is similar to another "recent" discussion about passing null pointers to mem* library functions. C89 allowed zero or null. C99 seems to forbid it. I'm going from memory here, can look at standards later if desired On Aug 20, 2015 8:08 AM, "Richard Hipp" wrote: > On 8/20/15,

Re: [sqlite] Compile warnings

D. Richard Hipp writes: ...snip > > Many of the warnings you mention could be suppressed by initializing > some variables. But those initializations are technically unnecessary > and thus slow things down. (Most will probably make no measureable > difference in speed, but an