Displaying 3 results from an estimated 3 matches for "end_byte".
Did you mean:
send_byte
2010 Sep 02
1
Possible Bug
...elt i found a possible bug. I'm using CELT 0.7.1, frame
size 256, sample rate 32k and bitrate 64k.
Here is the scenario: decoding side, celt_decode function.
The "dec" structure is created at each function call and it's initialized
with ec_dec_init function. The attribute "end_byte" is not initialized
though. Decoding a file the behaviour is the following: decoding the first
frame the variable "shortBlocks" is true and then transient_shift == 3
hence the function ec_dec_uint is executed. In this function the
attribute "end_byte" is written first...
2010 Sep 03
0
[PATCH 1/2] btrfs: document where we use BUG_ON instead of error handling
...uct btrfs_trans_handle *trans,
u32 new_size = (bytenr - key->offset) >> blocksize_bits;
new_size *= csum_size;
ret = btrfs_truncate_item(trans, root, path, new_size, 1);
- BUG_ON(ret);
+ btrfs_fixable_bug_on(ret);
} else if (key->offset >= bytenr && csum_end > end_byte &&
end_byte > key->offset) {
/*
@@ -505,11 +505,11 @@ static noinline int truncate_one_csum(struct btrfs_trans_handle *trans,
new_size *= csum_size;
ret = btrfs_truncate_item(trans, root, path, new_size, 0);
- BUG_ON(ret);
+ btrfs_fixable_bug_on(ret);
key->o...
2011 Oct 04
68
[patch 00/65] Error handling patchset v3
Hi all -
Here''s my current error handling patchset, against 3.1-rc8. Almost all of
this patchset is preparing for actual error handling. Before we start in
on that work, I''m trying to reduce the surface we need to worry about. It
turns out that there is a ton of code that returns an error code but never
actually reports an error.
The patchset has grown to 65 patches. 46 of them