bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: restrict


From: Bruno Haible
Subject: Re: restrict
Date: Mon, 17 Feb 2020 01:14:58 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-171-generic; KDE/5.18.0; x86_64; ; )

Addendum:
> > >    - 'restrict' should NOT be used for multiple output parameters of the
> > >      same type, when only a single word is written through each parameter.
> > >      Example: ssize_t copy_file_range (int ifd, off_t *ipos, int ofd, 
> > > off_t *opos,
> > >                                        size_t len, unsigned flags);
> > >      Rationale: It is OK to have ipos and opos point to different elements
> > >      of the same off_t[] array.
> > 
> > Ouch, this is exactly the opposite of what I would have wanted, since I 
> > want 
> > 'restrict' to tell the caller "these should not be aliases" and I want that 
> > to 
> > be true for *IPOS and *OPOS.  (I'm not sure what is meant by 'single word' 
> > here; 
> > surely it shouldn't matter whether the type is a struct....) Could you 
> > explain 
> > more where the 'same array' rule comes from?
> 
> The "same array" rule comes from what I understood from various explanations
> of 'restrict' on the web [1], and from what I see in the glibc headers for
> functions that have multiple output parameters of the same type

Also, I thought that passing pointers to different elements of the same array
would produce warnings. But I was mistaken: This code does NOT produce warnings.

================================================================================
#include <stddef.h>
extern int copy_file_range (int, long *restrict, int, long *restrict, size_t, 
unsigned int);

int infd;
int outfd;
long offsets[2];

int copy_block (void)
{
  return copy_file_range (infd, &offsets[0], outfd, &offsets[1], 4096, 0);
}
================================================================================

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]