search for: restrictions

tree: https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost head: 3d22d7c1190db3209b644b8a13a75a9802b4587f commit: b3a8771f409b74c42deee28aee3092fc5d2c8dab [22/23] fw_cfg: write vmcoreinfo details reproduce: # apt-get install sparse git checkout b3a8771f409b74c42deee28aee3092fc5d2c8dab make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__

Hi Daniel, On Aug 24, 2007, at 10:20 AM, Daniel Berlin wrote: > On 8/22/07, Christopher Lamb <christopher.lamb at gmail.com> wrote: >> >> >> On Aug 22, 2007, at 3:48 PM, Duncan Sands wrote: >> >> Hi Christopher, >> >> >> If A and B are function arguments then there is no "based on" >> relationship between pointer

On 8/22/07, Christopher Lamb <christopher.lamb at gmail.com> wrote: > > > On Aug 22, 2007, at 3:48 PM, Duncan Sands wrote: > > Hi Christopher, > > > If A and B are function arguments then there is no "based on" > relationship between pointer expressions A+0 and B+0. This is because > changing one of the pointers, A for example, to point to a copy of

On Aug 22, 2007, at 3:48 PM, Duncan Sands wrote: > Hi Christopher, > >> If A and B are function arguments then there is no "based on" >> relationship between pointer expressions A+0 and B+0. This is because >> changing one of the pointers, A for example, to point to a copy of >> the object it points to would change the value of the pointer >>

We recently found an issue when using the full restrict implementation developed by Jeroen; it surfaces when compiling an obscure combination of std::valarray and std::indirect_array but I don't want to bore you with all the details. What it boils down to is this basic question about restrict: Given one restrict pointer based on another, should they never alias? As far as I understand the

Thanks, Jeroen, that really helps. A follow-up question, if you don't mind. What if we have code somewhat similar to your example in assign3() but it's in C++ and the pointer derived from x is stored in a class member field: class S { public: S(int *d): data(d) {} int *getData() { return data; } private: int *__restrict__ data; }; void assign4(int *pA, long N) { int

On 08/16/2018 07:52 PM, Bekket McClane via llvm-dev wrote: > > >> On Aug 16, 2018, at 4:41 PM, Troy Johnson via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Concerning slide 16 >> of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf >>   >> Specifically “Currently, LLVM

On Mar 26, 2007, at 10:10 AM, Dan Gohman wrote: > On Mon, Mar 26, 2007 at 02:14:56AM -0500, Christopher Lamb wrote: >> >> >> On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: >> >>> On Sun, 25 Mar 2007, Christopher Lamb wrote: >>>> What about an approach not unlike how debugging information is >>>> handled? That >>>> is have

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Sunday, December 2, 2012

On Tue, 12 Sep 2017 14:41:42 -0300 Flávio Silveira via samba <samba at lists.samba.org> wrote: > > Ok, I understand now, one question though: if realm is > AD.TECNOPON.COM.BR, does domain need to be AD? No, you can use anything you like, provided it is one word, 15 characters or less, without punctuation. > If I understand > correctly, realm is "full domain with

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "Dan Gohman" > <dan433584 at gmail.com> > Sent: Sunday, December 2, 2012

On Sun, Dec 2, 2012 at 8:05 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Chandler Carruth" <chandlerc at google.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Clang Developers" <cfe-dev at cs.uiuc.edu>,

...server 0.debian.pool.ntp.org iburst server 1.debian.pool.ntp.org iburst server 2.debian.pool.ntp.org iburst server 3.debian.pool.ntp.org iburst # Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for # details. The web page <http://support.ntp.org/bin/view/Support/AccessRestrictions> # might also be helpful. # # Note that "restrict" applies to both servers and clients, so a configuration # that might be intended to block requests from certain clients could also end # up blocking replies from your own upstream servers. # By default, exchange time with everybody, b...

https://bugzilla.mindrot.org/show_bug.cgi?id=3159 Bug ID: 3159 Summary: authorized_keys: gap in port forwarding restrictions Product: Portable OpenSSH Version: 8.0p1 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: spmfox at foxw...

On Mon, Dec 3, 2012 at 6:19 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Daniel Berlin" <dberlin at dberlin.org> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "LLVM

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Chandler Carruth" <chandlerc at google.com>, "Clang Developers" <cfe-dev at cs.uiuc.edu>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu> > Sent: Monday, December 3, 2012

Hello all, Am trying to set up a guest account for employees from other offices to come in the office to login and do stuff. I want to block access to all public drives so this is what I've done: Consider the SAMBA server in Office A and I want to create a guest account so that people from Office B and C can access. There is a public drive that everyone in Office A can edit, and a drive

Concerning slide 16 of https://llvm.org/devmtg/2017-02-04/Restrict-Qualified-Pointers-in-LLVM.pdf Specifically "Currently, LLVM only supports restrict on function arguments, although we have a way to preserve that information if the function is inlined." Is that statement still accurate? It would seem that https://llvm.org/docs/LangRef.html#noalias-and-alias-scope-metadata should be

On Mar 25, 2007, at 5:22 PM, Chris Lattner wrote: > On Sun, 25 Mar 2007, Christopher Lamb wrote: >>> So far, there hasn't been a discussion. IMO, the most important >>> form is >>> for formal arguments. That could easily be added thorough the >>> use of an >>> attribute on the parameter. >> >> I assume the idea here is to

...ile???????? /var/log/ntp.log #logconfig =all ntpsigndsocket? /var/lib/samba/ntp_signd/ # Access control # Default restriction: Allow clients only to query the time #restrict default kod nomodify notrap nopeer limited mssntp restrict -4 default kod limited nomodify notrap nopeer noquery mssntp # No restrictions for "localhost" restrict 127.0.0.1 # Enable the time sources to only provide time to this host restrict 0.pool.ntp.org?? mask 255.255.255.255??? nomodify notrap nopeer noquery restrict 1.pool.ntp.org?? mask 255.255.255.255??? nomodify notrap nopeer noquery restrict 2.pool.ntp.org?? mask...