[sqlite] Article about pointer abuse in SQLite

On Thu, Mar 24, 2016 at 5:59 PM, Keith Medcalf wrote: > On Thursday, 24 March, 2016 08:27, Tim Streater > said, > > > On 24 Mar 2016 at 13:41, Jim Callahan > > wrote: > > > > Assuming one did not get a cryptic compiler message (and in those days > > all compiler messages were cryptic,

[sqlite] Article about pointer abuse in SQLite

On Thursday, 24 March, 2016 08:27, Tim Streater said, > On 24 Mar 2016 at 13:41, Jim Callahan > wrote: > > Assuming one did not get a cryptic compiler message (and in those days > all compiler messages were cryptic, "Probable user error:") ... > Not always: If you used JAIL as a variable in a

[sqlite] Article about pointer abuse in SQLite

On 24 Mar 2016, at 2:49pm, Richard Hipp wrote: > On 3/24/16, Simon Slavin wrote: >> >> I want the next generation of compilers to require >> that the programmer specify an initial value (a constant, not a calculated >> value) for every variable they define, including every array element when

[sqlite] Article about pointer abuse in SQLite

I've been leaving this thread alone because I've been very interested in various people's contributions. But I'm a security professional so I know stuff most programmers don't know, and I've seen enough wrong information here that I'm concerned someone will use it to design something badly.

[sqlite] Article about pointer abuse in SQLite

On 24 Mar 2016 at 13:41, Jim Callahan wrote: > Assuming one did not get a cryptic compiler message (and in those days all > compiler messages were cryptic, "Probable user error:") ... Not always: If you used JAIL as a variable in a computed GOTO, the XDS FORTRAN compiler for the Sigma 7 would,

[sqlite] Article about pointer abuse in SQLite

On 3/24/16, Marc L. Allen wrote: > With everything that routine does, the extra initialization negatively > impacts operation? > It did when I put in that comment in 2009. At that point in time, the routine was very hot. Subsequent optimizations have enabled us to completely bypass that

[sqlite] Article about pointer abuse in SQLite

On 3/24/16, Simon Slavin wrote: > > I want the next generation of compilers to require > that the programmer specify an initial value (a constant, not a calculated > value) for every variable they define, including every array element when > they define an array. At

[sqlite] Article about pointer abuse in SQLite

On 3/23/2016 1:23 PM, Doug Nebeker wrote: >> For obvious security reasons all allocations from the Operating System are >> pre-initialized to 0x00. > > Time to bash Windows, but according to the docs for HeapAlloc, memory is not > automatically initialized to 0 > >

[sqlite] Article about pointer abuse in SQLite

To: SQLite mailing list Subject: Re: [sqlite] Article about pointer abuse in SQLite On 3/24/16, Simon Slavin wrote: > > I want the next generation of compilers to require that the programmer > specify an initial value (a constant, not a calculated > value) for every variable they defin

[sqlite] Article about pointer abuse in SQLite

rg] On Behalf Of Keith Medcalf > Sent: Tuesday, March 22, 2016 8:41 PM > To: SQLite mailing list > Subject: Re: [sqlite] Article about pointer abuse in SQLite > > > > This discussion on the nature of undefined behaviour code is > > interesting. I don't know the reasoni

[sqlite] Article about pointer abuse in SQLite

sdn.microsoft.com/en-us/library/windows/desktop/aa366597(v=vs.85).aspx > > This fits with my experience as well. > > Doug > > > > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto: > sqlite-users-bounces at mailinglists.sqlite.org] On

[sqlite] Article about pointer abuse in SQLite

sqlite] Article about pointer abuse in SQLite > This discussion on the nature of undefined behaviour code is > interesting. I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied i

[sqlite] Article about pointer abuse in SQLite

On Wed, 23 Mar 2016 12:59 am Adam Devita wrote: > > This discussion on the nature of undefined behaviour code is > interesting. I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in

[sqlite] Article about pointer abuse in SQLite

On Tue, 22 Mar 2016 11:00:24 -0500 "Marc L. Allen" wrote: > I don't think compilers "run" your code. Provided we're talking about a C compiler, you're right. Optimizers don't run the code, they reason about it. > The fact that the code never actually allows that path to occur is > beyond

[sqlite] Article about pointer abuse in SQLite

On Tue, 22 Mar 2016 09:58:52 -0400 Adam Devita wrote: > I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > happens to be what was on the stack or heap).

[sqlite] Article about pointer abuse in SQLite

On Tue, 22 Mar 2016 09:56:57 +0100 "Cezary H. Noweta" wrote: > On 2016-03-22 00:35, James K. Lowden wrote: > >[...] An example from Clang's discussion is > > > > int i = 10 << 31; > > Could you provide a link for that discussion? (Or google's phrase to > retrieve such link?) I'm sorry,

[sqlite] Article about pointer abuse in SQLite

> This discussion on the nature of undefined behaviour code is > interesting. I don't know the reasoning, but it seems that VS6 often > initialized things to 0xcd in debug mode and (usually) had memory > uninitialized to 0x00 when complied in Release (perhaps 0x00 just > happens to be what was

[sqlite] Article about pointer abuse in SQLite

compilers, isn't it? -Original Message- From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of J Decker Sent: Tuesday, March 22, 2016 11:43 AM To: SQLite mailing list Subject: Re: [sqlite] Article about pointer abuse in SQLi

[sqlite] Article about pointer abuse in SQLite

It may be pedantic, but VS2016 will stop complaining if you edit your definition of s to large_struct s=new large_struct(); //set s to an actual instance of large_struct. c people can think of s as a pointer, and in c# the members are set to their default values. J Decker's point could also have

[sqlite] Article about pointer abuse in SQLite

Hello, On 2016-03-22 00:35, James K. Lowden wrote: >[...] An example from Clang's discussion is > > int i = 10 << 31; Could you provide a link for that discussion? (Or google's phrase to retrieve such link?) -- best regards Cezary H. Noweta

[sqlite] Article about pointer abuse in SQLite

On Tue, Mar 22, 2016 at 6:58 AM, Adam Devita wrote: > It may be pedantic, but VS2016 will stop complaining if you edit your > definition of s to > large_struct s=new large_struct(); //set s to an actual instance of > large_struct. c people can think of s as a pointer, and in c# the > members are

[sqlite] Article about pointer abuse in SQLite

On Tue, Mar 22, 2016 at 4:27 AM, Scott Doctor wrote: > > It is uninitialized. you are setting an initial value within an if > statement. For the compiler, the code has NOT actually executed. so it does > not use the value of the variable arbitrary_true_false. If it was a #define > then it would

[sqlite] Article about pointer abuse in SQLite

It is uninitialized. you are setting an initial value within an if statement. For the compiler, the code has NOT actually executed. so it does not use the value of the variable arbitrary_true_false. If it was a #define then it would use the value but still give an error because it is not a

[sqlite] Article about pointer abuse in SQLite

On Mon, Mar 21, 2016 at 8:40 PM, Scott Doctor wrote: > you are missing > > using System; whatever. It still fails because it says the variable is uninitilalized. THe only thing that doesn't is actually running it. That same pattern not matter what the language triggers warning/error checkers

[sqlite] Article about pointer abuse in SQLite

you are missing using System; Scott Doctor scott at scottdoctor.com -- On 3/21/2016 5:21 PM, J Decker wrote: > So far I just see analysis tools fail for the same sorts of valid code... > > this is a bit of C# but the same idea causes the same warnings and > there's

[sqlite] Article about pointer abuse in SQLite

On Mon, 21 Mar 2016 13:48:06 -0700 Scott Perry wrote: > Compilers allow you to choose your standard; --std=c11 means > something very specific (and unchanging) They do. And that covers what the standard covers. The standard also has limits. It includes constructs that are syntactically

[sqlite] Article about pointer abuse in SQLite

So far I just see analysis tools fail for the same sorts of valid code... this is a bit of C# but the same idea causes the same warnings and there's nothign tecniclally wrong with this. class test { struct large_struct { public int x; } bool arbitrary_true_false = true; void method()

[sqlite] Article about pointer abuse in SQLite

On Mar 21, 2016 2:48 PM, "Scott Perry" wrote: > > On Mar 21, 2016, at 3:17 AM, Klaas Van B. wrote: > > > >>> On 3/19/16, James K. Lowden wrote: > > > >>> ... If the correctness of the code is > >>> subject to change by the compiler's interpretation of the language, how > >>> is the programmer

[sqlite] Article about pointer abuse in SQLite

On Mar 21, 2016, at 1:48 PM, Scott Perry wrote: > > On Mar 21, 2016, at 3:17 AM, Klaas Van B. wrote: >> On 3/19/16, James K. Lowden wrote: >> ... If the correctness of the code is subject to change by the compiler's interpretation of the language, how is the programmer to

[sqlite] Article about pointer abuse in SQLite

On Mar 21, 2016, at 3:17 AM, Klaas Van B. wrote: > >>> On 3/19/16, James K. Lowden wrote: > >>> ... If the correctness of the code is >>> subject to change by the compiler's interpretation of the language, how >>> is the programmer to prevent it? > >> On Sat, 19 Mar 2016 15:50:43 -0400

[sqlite] Article about pointer abuse in SQLite

>> On 3/19/16, James K. Lowden wrote: >> ... If the correctness of the code is >> subject to change by the compiler's interpretation of the language, how >> is the programmer to prevent it? > On Sat, 19 Mar 2016 15:50:43 -0400 Richard Hipp wrote: > ... But subsequent revisions of the >

[sqlite] Article about pointer abuse in SQLite

On Mar 19, 2016 1:19 PM, "James K. Lowden" wrote: > > On Sat, 19 Mar 2016 02:04:35 -0600 > Scott Robison wrote: > > > As he says, there's not real choice between fast and > > > correct > > > > Except that testing can verify something is correct for a given > > environment. > > That's actually

[sqlite] Article about pointer abuse in SQLite

On 3/19/16, James K. Lowden wrote: > > Second, you can't test the future. If the correctness of the code is > subject to change by the compiler's interpretation of the language, how > is the programmer to prevent it? > Indeed. Every bit of the code examined by Prof. Regehr was well-defined

[sqlite] Article about pointer abuse in SQLite

On Sat, 19 Mar 2016 02:04:35 -0600 Scott Robison wrote: > As he says, there's not real choice between fast and > > correct > > Except that testing can verify something is correct for a given > environment. That's actually not true, on a couple of levels. "[T]esting can be used

[sqlite] Article about pointer abuse in SQLite

On Mar 18, 2016 11:12 PM, "James K. Lowden" wrote: > > On Fri, 18 Mar 2016 16:33:56 -0600 > Scott Robison wrote: > > > I'd rather have code that might use some "undefined behavior" and > > generates the right answer than code that always conformed to defined > > behavior yet was logically

[sqlite] Article about pointer abuse in SQLite

On Fri, 18 Mar 2016 16:33:56 -0600 Scott Robison wrote: > I'd rather have code that might use some "undefined behavior" and > generates the right answer than code that always conformed to defined > behavior yet was logically flawed. Code that falls under undefined behavior *is* logically

[sqlite] Article about pointer abuse in SQLite

On 18 Mar 2016, at 10:33pm, Scott Robison wrote: > I'd rather have code that might use some "undefined behavior" and generates > the right answer than code that always conformed to defined behavior yet > was logically flawed. Mind you, I don't often have to worry about my code > being compiled

[sqlite] Article about pointer abuse in SQLite

Scott Robison wrote... > Also, it seems a lot of people today are critical of programs that utilize > defined behavior in the context of the standard to which they were > written, > but not to a later standard (such as ANSI C / C89 / C90 vs C99 or C11 or > whatever). It's great to conform to

[sqlite] Article about pointer abuse in SQLite

"SQLite is a carefully engineered and thoroughly tested piece of software. Even so, it contains undefined behaviors because, until recently, no good checker for these behaviors existed. If anything is going to save us from UB hell, it?s tools combined

[sqlite] Article about pointer abuse in SQLite

On 3/18/16, Igor Tandetnik wrote: > On 3/18/2016 4:40 PM, Keith Medcalf wrote: >> There is no such thing as "undefined behaviour". The machine code does >> exactly what it is told to do > > But SQLite is not written in machine code. It is (largely) written in C. SQLite is written in C, but the

[sqlite] Article about pointer abuse in SQLite

On 3/18/2016 4:40 PM, Keith Medcalf wrote: > There is no such thing as "undefined behaviour". The machine code does > exactly what it is told to do But SQLite is not written in machine code. It is (largely) written in C. And C language most certainly has the concept of undefined behavior -

[sqlite] Article about pointer abuse in SQLite

On Fri, Mar 18, 2016 at 4:03 PM, Richard Hipp wrote: > On 3/18/16, Igor Tandetnik wrote: > > On 3/18/2016 4:40 PM, Keith Medcalf wrote: > >> There is no such thing as "undefined behaviour". The machine code does > >> exactly what it is told to do > > > > But SQLite is not written in machine

[sqlite] Article about pointer abuse in SQLite

4:41 PM To: SQLite mailing list Subject: Re: [sqlite] Article about pointer abuse in SQLite There is no such thing as "undefined behaviour". The machine code does exactly what it is told to do in exactly the manner in which it has been told to do it and obtains exactly the corr

[sqlite] Article about pointer abuse in SQLite

There is no such thing as "undefined behaviour". The machine code does exactly what it is told to do in exactly the manner in which it has been told to do it and obtains exactly the correct answer every time. That the computation is "advanced beyond the realm of understanding of the

[sqlite] Article about pointer abuse in SQLite

Not sure where you're going with this. "Undefined behavior" in this case is obviously referring to things defined by the C standard. Things not defined by the standard can (and do) change over time as compilers advance, and also often differ between compilers from different vendors. -scott On