search for: get_states

All accesses to the h->state field are redirected through these macros (except when we create the handle). This is simple refactoring. --- generator/generator | 18 +++++++++--------- lib/connect.c | 10 +++++----- lib/disconnect.c | 8 ++++---- lib/internal.h | 3 +++ lib/is-state.c | 12 ++++++------ lib/rw.c | 4 ++-- 6 files changed, 29 insertions(+), 26

Split h->state into: - h->state = the state on entry to the locked region - h->next_state = the current state and what the "publicly visible" state will become when we leave the locked region Some calls to get_state become calls to get_next_state depending on which of these they are trying to read. Calls to set_state become set_next_state because that is what gets

Split h->state into: - h->public_state = the state on entry to the locked region This is also the atomicly, publicly visible state. - h->state = the real current state of the handle When we leave the locked region we update h->public_state with h->state, so that from outside the lock the handle appears to move atomically from its previous state to the final state without

Split h->state into: - h->public_state = the state on entry to the locked region This is also the atomically, publicly visible state. - h->state = the real current state of the handle When we leave the locked region we update h->public_state with h->state, so that from outside the lock the handle appears to move atomically from its previous state to the final state without

I need to think about this patch series a bit more, but it does at least pass the tests. Rich.

v1 was here: https://www.redhat.com/archives/libguestfs/2019-June/thread.html#00055 v2 was here: https://www.redhat.com/archives/libguestfs/2019-June/thread.html#00067 v3: - Fix atomicly -> atomically in commit message. - Fix a comment. - Fix TOCTTOU: There is now an inline function generated called <name>_is_permitted_state, and this is called twice, first outside the

It seems pretty typical that compilation warnings can be essentially ignored. Be that as it may, if I can't find evidence that a warning can be ignored in the archives, I am compelled to ask about it. A nod that these are OK or a fix for them if they are not OK would be appreciated. I am getting several warnings with winbind_nss.c : Compiling nsswitch/winbind_nss.c with -fPIC

On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: > -#define set_state(h,next_state) ((h)->state) = (next_state) > +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) > +#define get_next_state(h) ((h)->next_state) > #define get_state(h) ((h)->state) So I wonder if it's better to rename get_state as get_last_state or

On 6/5/19 8:03 AM, Richard W.M. Jones wrote: > On Wed, Jun 05, 2019 at 01:35:32PM +0100, Richard W.M. Jones wrote: >> On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: >>> -#define set_state(h,next_state) ((h)->state) = (next_state) >>> +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) >>> +#define get_next_state(h)

Hi All, Well, i've managed to enable some debugging in syslog, I had to put in /etc/syslog.conf ;*.debug on the syslog line. So at least I have an error which is being returned into syslog from winbind. This is what I get from winbind Feb 4 21:13:17 coastdr pam_winbind[20753]: Verify user `lonnie' Feb 4 21:13:18 coastdr pam_winbind[20753]: user 'lonnie' granted acces Feb 4

I'm using libFLACC++ and libFLAC and I think that I'm using the calls in the typical order (see code below). But every monoe or stereo file that I send thru I get files that are the same sze as the orginal wave files. Doing a flac -a on the flac files I see that I get: frame=9 blocksize=4608 sample_rate=8000 channels=1 channel_assignment=INDEPENDENT subframe=0

On Wed, Jun 05, 2019 at 01:35:32PM +0100, Richard W.M. Jones wrote: > On Wed, Jun 05, 2019 at 12:15:37PM +0100, Richard W.M. Jones wrote: > > -#define set_state(h,next_state) ((h)->state) = (next_state) > > +#define set_next_state(h,_next_state) ((h)->next_state) = (_next_state) > > +#define get_next_state(h) ((h)->next_state) > > #define get_state(h)

I have been running R CMD check for the first time on of our own packages, which otherwise builds, installs and runs just fine. The package depends on package akima and suggests package multtest; suggesting multtest is indicated because a) it loads a lot of other Bioconductor packages, very slowly, and b) it is only needed for one specific subroutine, which executes require(multtest)

looks fine, I would suspect how the PCM sample are formatted and sent to process(), could you show that part of the code? Josh --- James Smith <jsmith@landmarkdigital.com> wrote: > > I'm using libFLACC++ and libFLAC and I think that I'm using the calls > in the > typical order (see code below). But every monoe or stereo file that > I send > thru I get files

I'm using flac-1.2.1 and visual studio 2010 on windows xp sp3 and I want to compress raw CDDA with the stream encoder to a file. But I just can't get the flac encoder to work, the encoder always returns an error enc.get_state() == "FLAC__STREAM_ENCODER_VERIFY_MISMATCH_IN_AUDIO_DATA" get_verify_decoder_state() == "FLAC__STREAM_DECODER_READ_FRAME" this is the code I

On 6/5/19 6:15 AM, Richard W.M. Jones wrote: > Split h->state into: > > - h->state = the state on entry to the locked region > > - h->next_state = the current state and what the "publicly visible" > state will become when we leave the locked region The rest of this thread discusses potential other names, such as h->public_state for the state visible

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am trying to create a FLAC plugin for the K3b CD burning program. To do this I have subclassed the FLAC::Decoder::SeekableStream class. I can obtain the vorbiscomment data using set_metadata_respond, process_until_end_of_metadata and the metadata_callback, however I cannot decode the audio data. It seems to me as though the write_callback

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----

Use the newly added u64_to_user_pointer a bit more frequently. Signed-off-by: Joe Perches <joe at perches.com> --- drivers/gpu/drm/armada/armada_gem.c | 2 +- drivers/gpu/drm/nouveau/nouveau_gem.c | 7 ++++--- drivers/gpu/drm/tegra/drm.c | 15 ++++++++------- drivers/gpu/drm/vc4/vc4_bo.c | 4 ++-- drivers/gpu/drm/vc4/vc4_gem.c | 10 +++++-----