Displaying 4 results from an estimated 4 matches for "num_ops".
Did you mean:
num_aps
2009 Nov 10
12
[RFC] big fat transaction ioctl
...l_usertrans *ut,
+ u64 *ops_completed)
+{
+ int i;
+ int *fds;
+ int err;
+ struct file *file;
+ struct btrfs_ioctl_usertrans_op *ops = (void *)ut->ops_ptr;
+ int fd1, fd2;
+
+ fds = kcalloc(sizeof(int), ut->num_fds, GFP_KERNEL);
+ if (!fds)
+ return -ENOMEM;
+
+ for (i = 0; i < ut->num_ops; i++) {
+ struct btrfs_ioctl_usertrans_op op;
+ int ret;
+
+ err = -EFAULT;
+ if (copy_from_user(&op, &ops[i], sizeof(op)))
+ goto out;
+
+ /* lookup fd args? */
+ err = -EINVAL;
+ switch (op.op) {
+ case BTRFS_IOC_UT_OP_CLONERANGE:
+ if (op.args[1] < 0 || op.args[1] >= ut...
2016 Mar 23
1
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
...with the ubiquitous
practice of having 0- or 1-length array at the end of a struct and then
allocating additional elements for it using malloc, or the so-called
"struct hack":
http://c-faq.com/struct/structhack.html
For example:
typedef struct {
enum inst_type type;
unsigned num_ops;
struct operand ops[1];
} inst;
// allocate an instruction with specified number of operands
int *allocate_inst(unsigned num_operands) {
char *mem = malloc(sizeof(inst) + sizeof(struct operand) *
(num_operands-1));
return (inst *) mem;
}
Or maybe the reasoning is that computin...
2016 Mar 22
0
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
Reply from Michael:
&x points to the start of object x, and &x - something (something != 0)
points outside object x. 'c' was a complete object, so &c-8 points
outside any object, hence the formation of that pointer is already
invalid (as is its dereference).
https://gcc.gnu.org/ml/gcc/2016-03/msg00185.html
>>On Fri, Mar 18, 2016 at 8:46 AM, Daniel Berlin <dberlin
2016 Mar 19
2
Redundant load in llvm's codegen compares to gcc when accessing escaped pointer?
Agree, and I did : )
Please refer to this mailing list:
https://gcc.gnu.org/ml/gcc/2016-03/msg00179.html
On Sat, Mar 19, 2016 at 1:25 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
> I suspect you should just go ask #1 on the gcc mailing list and see what
> the answer is.
> We are basically trying to figure out their reasoning, but we should
> instead just go ask what it is