search for: needlessly

https://bugzilla.samba.org/show_bug.cgi?id=6788 Summary: rsync does not abort early but needlessly transfers data if destination is write protected Product: rsync Version: 3.0.5 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned...

https://bugzilla.mindrot.org/show_bug.cgi?id=3559 Bug ID: 3559 Summary: Mini memory leak and needless(?) const/static qualifier. Product: Portable OpenSSH Version: 8.5p1 Hardware: Other OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh

..., Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04 PM > Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > > > The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged al...

https://bugzilla.samba.org/show_bug.cgi?id=6422 Summary: rsync needlessly aborts when getcwd() fails Product: rsync Version: 3.0.6 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned@samba.org ReportedBy: vapier@gento...

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update th...

Hi all, I would like to ask that if you post to this list, please avoid signatures, vcards, and other unnecessary attachments. In order to keep this list virtually spam free, despite the fact that it gets sent spam literally every day, I moderate anything that comes in with text/html or multipart/*. However, it means I have to moderate these things manually, so, to make my life easier,

On Wed, 6 Jun 2001, Markus Friedl posted the following to Bugtraq: > this feature [placing the X11 cookie file in /tmp] was inherited > from ossh and the reason was: > 1) if $HOME is on NFS, then the cookie travels unencrypted > over the network, this defeats the purpose of X11-fwding > 2) $HOME/.Xauthority gets polluted with temorary cookies. > however,

Full_Name: Jelle Goeman Version: 2.4.0 OS: windows XP Submission from: (NULL) (145.88.209.33) Hi, I like to use optimize() to optimize functions whose evaluation is costly in terms of computation time. The Brent algorithm which is implemented in optimize was designed to optimize a function with as few function evaluations as possible. Therefore it bothers me that optimize() always evaluates

Hi Akira, did anything happen with this patch? Ciao, Duncan. On 09/05/13 04:04, Akira Hatanaka wrote: > The following code snippet taken from StackColoring::remapInstructions clears a > mem operand if it can't guarantee whether the memoperand's underlying value > aliases with the merged allocas: > > // Update the MachineMemOperand to use the new alloca. > 522

A bit of a perennial I'm afraid. My wife has filled up her iPhone 6 with photos, and wants them moved onto my computer. I'm running CentOS 7 patched about 30 minutes ago. Needless to say the computer can't see the data on the iPhone, though it does recognise the phone as an iPhone. Any suggestions (well any that don't involve a steam roller, sledge hammer or GBH to the whole of

Hi Duncan, No, it hasn't been reviewed yet. On Mon, May 13, 2013 at 8:50 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Akira, did anything happen with this patch? > > Ciao, Duncan. > > > On 09/05/13 04:04, Akira Hatanaka wrote: > >> The following code snippet taken from StackColoring::**remapInstructions >> clears a >> mem operand if it

Currently, you're allowed to form a constant of aggregate type using any number of other constants you like. This makes scanning the instructions of the IR needlessly complex when looking for references to constants. There is no need to support this degree of complexity in the IR. We could require that for anything but 'zeroinitializer' you cannot write a constant of aggregate (structure or array) type. You have to build it using insertvalue. Thoughts?...

No, just no. You do not use goto to skip a code block. You do not return an obvious variable from a singly-inlined function and give the function a return value. You don't put unexplained comments about kmalloc in code which doesn't do dynamic allocation. And you don't leave stray warnings around for no good reason. Also, when possible, it is better to use block scoped variables

No, just no. You do not use goto to skip a code block. You do not return an obvious variable from a singly-inlined function and give the function a return value. You don't put unexplained comments about kmalloc in code which doesn't do dynamic allocation. And you don't leave stray warnings around for no good reason. Also, when possible, it is better to use block scoped variables

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not

I have set up a kvm host and configured a standard clone prototype for generating new guests. One persistent (pun intended) annoyance when cloning is the behaviour of udev with respect to the virtual network interface. The prototype is configured with just eth0 having a dedicated IP addr. When the prototype is cloned udev creates rules for both eth0 and eth1 in the clone. Because eth1 does not

G'Day, I want to access in a function called from tapply the current factor. In my example below, all I want to do is to write the current factor on each histogram. Needless to say my example does not work. I would be grateful for pointers in the right direction. Many thanks Bernie McConnell Sea Mammal Reserach Unit cc <- 1:10 ff <- rep(c("a","b"),5) pp<-

...upgraded my Linux kernel from 2.6.17 to 2.6.18. I suggested to Jim that changes in the minor revision number of the operating system should not count as a new machine. He said he'd look into it when he has time. Its not a huge issue, I just didn't want to be incrementing the machine numbers needlessly and needed to know what it was based on. Reid.

On 29 Nov 2012, at 17:46, Eli Bendersky wrote: > I think this is a good idea, although personally I'd prefer the script > to be written in Python to allow more portability (i.e. using it on > Windows as well). If you are doing a build using the UNIX-like way of checking everything out and building it, then you will already have a shell installed via mingw or cygwin on Windows. If