Re: [sqlite] Using sqlite3_file in shims.
Renji Panicker wrote to this fine list: > >- As per the sqlite3PagerOpen function, the size of the memory allocated to >this pointer is ROUND8(pVfs->szOsFile). What configuration you're using, Renji? On some OS/browser/SupportSoftware etc. combinations this function may crash https://crash-stats.mozilla.com/report/list?signature=sqlite3PagerOpen There seem to be version differences as well. Kind regards | Cordiali saluti | Vriendelijke groeten | Freundliche Grüsse, Klaas `Z4us` V - OrcID -0001-7190-2544 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Using sqlite3_file in shims.
That cleared it up, thank you for the quick response.
-/renji
On Mon, Jun 30, 2014 at 12:17 AM, Richard Hipp wrote:
> On Sun, Jun 29, 2014 at 11:57 AM, Renji Panicker
> wrote:
>
> If some variable "p" is a pointer to the vfstrace object, then the
> underlying sqlite3_file object immediately follows it in memory. In other
> words, the underlying sqlite3_file is at (sqlite3_file*)p[1].
>
>
>
> >
> > - When I receive a call to my xOpen function, the 3rd parameter is a
> > sqlite3_file* type.
> >
> > - As per the sqlite3PagerOpen function, the size of the memory allocated
> to
> > this pointer is ROUND8(pVfs->szOsFile).
> >
> > - On Windows, the value of szOsFile is sizeof(winFile) + sizeof(myFile).
> >
> > - As per the sample shims, in my xOpen handler, I must typecast the
> > sqlite3_file* value to myFile*
> >
> > Does this mean that winFile and myFile are now overlapping at the same
> > memory location?
> >
> > For example: if sqlite3_file is defined as:
> >
> > struct sqlite3_file {
> >
> > const struct sqlite3_io_methods *pMethods; /* Methods for an open file
> */
> >
> > };
> > and winFile is defined as:
> >
> > struct winFile {
> >
> > const sqlite3_io_methods *pMethod; /*** Must be first ***/
> >
> > sqlite3_vfs *pVfs; /* The VFS used to open this file */
> >
> > };
> >
> > and myFile is defined as (taken from multiplex sample shim):
> >
> > struct myFile {
> > sqlite3_file base; /* Base class - must be first */
> > multiplexGroup *pGroup; /* The underlying group of files */
> >
> > };
> >
> > Wouldn't winFile::pVfs and myFile::pGroup be at the same location in
> > memory?
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Using sqlite3_file in shims.
On Sun, Jun 29, 2014 at 11:57 AM, Renji Panicker
wrote:
> I am developing a shim, and am facing a problem (or it might be a defect in
> the sample shims I have seen so far):
>
(1) test_vfstrace.c is probably a better example of a shim than
test_multiplex.c, at least for use as a basis for some new shim.
The subclass of sqlite3_file used by test_vfstrace.c is defined here:
http://www.sqlite.org/src/artifact/bab9594adc?ln=130-136
If some variable "p" is a pointer to the vfstrace object, then the
underlying sqlite3_file object immediately follows it in memory. In other
words, the underlying sqlite3_file is at (sqlite3_file*)p[1].
>
> - When I receive a call to my xOpen function, the 3rd parameter is a
> sqlite3_file* type.
>
> - As per the sqlite3PagerOpen function, the size of the memory allocated to
> this pointer is ROUND8(pVfs->szOsFile).
>
> - On Windows, the value of szOsFile is sizeof(winFile) + sizeof(myFile).
>
> - As per the sample shims, in my xOpen handler, I must typecast the
> sqlite3_file* value to myFile*
>
> Does this mean that winFile and myFile are now overlapping at the same
> memory location?
>
> For example: if sqlite3_file is defined as:
>
> struct sqlite3_file {
>
> const struct sqlite3_io_methods *pMethods; /* Methods for an open file */
>
> };
> and winFile is defined as:
>
> struct winFile {
>
> const sqlite3_io_methods *pMethod; /*** Must be first ***/
>
> sqlite3_vfs *pVfs; /* The VFS used to open this file */
>
> };
>
> and myFile is defined as (taken from multiplex sample shim):
>
> struct myFile {
> sqlite3_file base; /* Base class - must be first */
> multiplexGroup *pGroup; /* The underlying group of files */
>
> };
>
> Wouldn't winFile::pVfs and myFile::pGroup be at the same location in
> memory?
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Using sqlite3_file in shims.
I am developing a shim, and am facing a problem (or it might be a defect in
the sample shims I have seen so far):
- When I receive a call to my xOpen function, the 3rd parameter is a
sqlite3_file* type.
- As per the sqlite3PagerOpen function, the size of the memory allocated to
this pointer is ROUND8(pVfs->szOsFile).
- On Windows, the value of szOsFile is sizeof(winFile) + sizeof(myFile).
- As per the sample shims, in my xOpen handler, I must typecast the
sqlite3_file* value to myFile*
Does this mean that winFile and myFile are now overlapping at the same
memory location?
For example: if sqlite3_file is defined as:
struct sqlite3_file {
const struct sqlite3_io_methods *pMethods; /* Methods for an open file */
};
and winFile is defined as:
struct winFile {
const sqlite3_io_methods *pMethod; /*** Must be first ***/
sqlite3_vfs *pVfs; /* The VFS used to open this file */
};
and myFile is defined as (taken from multiplex sample shim):
struct myFile {
sqlite3_file base; /* Base class - must be first */
multiplexGroup *pGroup; /* The underlying group of files */
};
Wouldn't winFile::pVfs and myFile::pGroup be at the same location in memory?
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
