request for adios_write to accept 'const void * var' about adios HOT 7 CLOSED

I would do this in a clean code. However, the adios_var_struct->data pointer is used for different things (read buffer in old adios_read, transformed variable instead of the original) and I am not able to safely separate them. This will stay open for a while...

from adios.

Thank you for looking into this.

So are there any circumstances under which it is safe to assume that the data pointed to by var will not be modified by ADIOS? I'm not familiar with what adios_var_struct->data is and how it relates to the data I am passing in to adios_write, but I don't believe I have any variable transformations (I'm just dumping raw data), and I am only concerned with adios_write, not adios_read. If it is safe under those circumstances, then it saves the expense of my code allocating and copying into a temporary buffer.

from adios.

Ah yes, ADIOS does not touch the user data in adios_write() in any
circumstances. It will actually copy data into a buffer (for buffered I/O).
If you buffer too, that is a complete waste of memory. The input arguments
should have been const void * from the beginning, it's just so much harder
to clean this up after several developers grabbing it for their own
purposes over the years :-(

On Mon, May 12, 2014 at 11:50 AM, Andrew Corrigan
[email protected]:

Thank you for looking into this.

So are there any circumstances under which it is safe to assume that the
data pointed to by var will not be modified by ADIOS? I'm not familiar with
what adios_var_struct->data is and how it relates to the data I am passing
in to adios_write, but I don't believe I have any variable transformations
(I'm just dumping raw data), and I am only concerned with adios_write, not
adios_read. If it is safe under those circumstances, then it saves the
expense of my code allocating and copying into a temporary buffer.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-42849679
.

from adios.

Just a thought, since adios_write is really just a wrapper function around
the internal "common" layer, and nowadays it is guaranteed to treat the
data buffer as if it were const, couldn't the signature of adios_write
simply be changed to const void data, and then data be cast to void
before passing to the internal layer? It's a bit ugly, but I believe this
has perfectly well-defined behavior in C, since the buffer is never
actually modified.

• Drew
  On May 12, 2014 11:55 AM, "pnorbert" [email protected] wrote:

Ah yes, ADIOS does not touch the user data in adios_write() in any
circumstances. It will actually copy data into a buffer (for buffered
I/O).
If you buffer too, that is a complete waste of memory. The input arguments
should have been const void * from the beginning, it's just so much harder
to clean this up after several developers grabbing it for their own
purposes over the years :-(

On Mon, May 12, 2014 at 11:50 AM, Andrew Corrigan
[email protected]:

Thank you for looking into this.

So are there any circumstances under which it is safe to assume that the
data pointed to by var will not be modified by ADIOS? I'm not familiar
with
what adios_var_struct->data is and how it relates to the data I am
passing
in to adios_write, but I don't believe I have any variable
transformations
(I'm just dumping raw data), and I am only concerned with adios_write,
not
adios_read. If it is safe under those circumstances, then it saves the
expense of my code allocating and copying into a temporary buffer.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42849679>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-42850390
.

from adios.

I am trying to get rid of the many compiler warnings, not to add new ones.

On Mon, May 12, 2014 at 12:49 PM, daboyuka [email protected] wrote:

Just a thought, since adios_write is really just a wrapper function around
the internal "common" layer, and nowadays it is guaranteed to treat the
data buffer as if it were const, couldn't the signature of adios_write
simply be changed to const void data, and then data be cast to void
before passing to the internal layer? It's a bit ugly, but I believe this
has perfectly well-defined behavior in C, since the buffer is never
actually modified.

• Drew
  On May 12, 2014 11:55 AM, "pnorbert" [email protected] wrote:

Ah yes, ADIOS does not touch the user data in adios_write() in any
circumstances. It will actually copy data into a buffer (for buffered
I/O).
If you buffer too, that is a complete waste of memory. The input
arguments
should have been const void * from the beginning, it's just so much
harder
to clean this up after several developers grabbing it for their own
purposes over the years :-(

On Mon, May 12, 2014 at 11:50 AM, Andrew Corrigan
[email protected]:

Thank you for looking into this.

So are there any circumstances under which it is safe to assume that
the
data pointed to by var will not be modified by ADIOS? I'm not familiar
with
what adios_var_struct->data is and how it relates to the data I am
passing
in to adios_write, but I don't believe I have any variable
transformations
(I'm just dumping raw data), and I am only concerned with adios_write,
not
adios_read. If it is safe under those circumstances, then it saves the
expense of my code allocating and copying into a temporary buffer.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42849679>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42850390>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-42857236
.

from adios.

Definitely understandable. I'm fairly sure explicit casting never triggers
warnings, though, so maybe it's still something to keep in mind as a
potential option down the road.

• Drew

On Mon, May 12, 2014 at 1:00 PM, pnorbert [email protected] wrote:

I am trying to get rid of the many compiler warnings, not to add new ones.

On Mon, May 12, 2014 at 12:49 PM, daboyuka [email protected]
wrote:

Just a thought, since adios_write is really just a wrapper function
around
the internal "common" layer, and nowadays it is guaranteed to treat the
data buffer as if it were const, couldn't the signature of adios_write
simply be changed to const void data, and then data be cast to void
before passing to the internal layer? It's a bit ugly, but I believe
this
has perfectly well-defined behavior in C, since the buffer is never
actually modified.

• Drew
  On May 12, 2014 11:55 AM, "pnorbert" [email protected] wrote:

Ah yes, ADIOS does not touch the user data in adios_write() in any
circumstances. It will actually copy data into a buffer (for buffered
I/O).
If you buffer too, that is a complete waste of memory. The input
arguments
should have been const void * from the beginning, it's just so much
harder
to clean this up after several developers grabbing it for their own
purposes over the years :-(

On Mon, May 12, 2014 at 11:50 AM, Andrew Corrigan
[email protected]:

Thank you for looking into this.

So are there any circumstances under which it is safe to assume that
the
data pointed to by var will not be modified by ADIOS? I'm not
familiar
with
what adios_var_struct->data is and how it relates to the data I am
passing
in to adios_write, but I don't believe I have any variable
transformations
(I'm just dumping raw data), and I am only concerned with
adios_write,
not
adios_read. If it is safe under those circumstances, then it saves
the
expense of my code allocating and copying into a temporary buffer.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42849679>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42850390>
.

—
Reply to this email directly or view it on GitHub<
https://github.com/ornladios/ADIOS/issues/9#issuecomment-42857236>
.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-42858503
.

from adios.

This has been fixed in 1.9.0

from adios.