similar to: Is sshd supposed to interpret "{a,b}" brace expansions?

Damien, Reading the various articles about https://sintonen.fi/advisories/scp-client-multiple-vulnerabilities.txt have caused me to question the wisdom of using scp. Your observation: > Date: Tue, 22 Jan 2019 13:48:34 +1100 (AEDT) > From: Damien Miller <djm at mindrot.org> > Subject: Re: Status of SCP vulnerability > > "Don't use scp with untrusted

Commit-ID: 16419c03328ad90171240ed5f6ec0127117d43cd Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=16419c03328ad90171240ed5f6ec0127117d43cd Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Mon, 19 Nov 2018 18:41:20 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: expand: Eat

Hey everyone, Might it be possible for future versions of PC-R to highlight the opening brace in a pair, a la emacs? Programs that do that are infinitely friendlier than those that don't. Thanks, Steve Stephen R. Laniel | "I've got a match: Carnegie Mellon University | Your embrace and my collapse." laniel at cmu.edu | --They Might Be

Hi paulr: Thanks for your kindly response. Maybe I don't describe my question cleanly, let me show more information. From my side, I notice that whether we are in the continue keyword mode or we are in the right brace mode, the target of br instruction is the same, i.e. for loop Continue Keyword Mode: ; <label>:6: ; preds = %3 br label

Let me show you the following simple C code: int main() { int i; for (i = 0; i < 256; i++) { i++; } } In this simple C code, if we use Clang to compile it and debug it: We will get something like this: (gdb) b main Breakpoint 1 at 0x100000f7b: file a.c, line 5. (gdb) r Starting program: a.out [New Thread 0x1403 of process 23435] warning: unhandled dyld version (15) Thread 2

If we had a very naïve way of generating IR, in the 'continue' case you would actually see TWO branch instructions: one to implement the 'continue' statement, and one as part of the control flow of the 'for' loop. The branch for the 'continue' statement would have the source location of the 'continue' and the branch for the control-flow of the 'for'

Hi all, Does anyone know a solution for this error ? > tkwidget(dlg, "iwidgets::spinint", range="{0 23}") Error in structure(.External("dotTclObjv", objv, PACKAGE = "tcltk"), class = "tclObj") : [tcl] wrong # args: should be ".31.1.19 configure -range {begin end}". Thanks, Matthew [[alternative HTML version

I'll note that reading along I haven't found any of the proposed changes particularly worthwhile.  I'm also not strongly opposed to any of them - I just don't care - but I certainly haven't been convinced there's any clear benefit to be had by changing our current policy. Philip On 6/22/20 1:44 PM, Chris Lattner via llvm-dev wrote: > For those who don’t like it, is

On Tue, 23 Jun 2020 at 03:30, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Mon, Jun 22, 2020 at 2:38 PM Steve Scalpone via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Me? I would modify the first sentence from: >> >> > When writing the body of an if, else, or loop statement, >> > omit the braces to avoid unnecessary

My 2 pennies is braces add unnecessary clutter and impair readability when used on a *single-line* statement. I count comments, that are on their own line as statement(s). For example: BAD: if (cond) // Comment foo(); GOOD: if (cond) { // Comment foo(); } BAD: if (cond) { foo(); // Comment } GOOD: if (cond) foo(); // Comment BAD: if (cond) for(;;) foo() GOOD: if (cond)

Did this conversation reach a conclusion? My ad hoc tally says that a slight majority of the responders preferred to fully brace statements and no one wanted to totally eliminate braces. The technical arguments for fully braced statements were 1) it's considered a slightly safer coding style and 2) commit diffs with fully braced statements may be slightly more to the point. I didn't

I'm with Matt on this one. I much prefer the approach of ALWAYS use braces for ifs and for loops, even if they're not needed, for basically the same reasons as he put. The number of times I've added a statement inside an if without braces and forget to add them is annoyingly high, especially as it's not always an obvious error upfront. Similarly, being involved in a downstream

Me? I would modify the first sentence from: > When writing the body of an if, else, or loop statement, > omit the braces to avoid unnecessary line noise. However, > braces should be used in cases where the omission of braces > harm the readability and maintainability of the code. To be: > Braces are optional around the body of an if, else, or loop statement, > except in cases

Hello, I would like to request an update of the progress regarding fixes for the recently disclosed SCP vulnerability (CVE-2018-20685, CVE-2019-6111, CVE-2019-6109, CVE-2019-6110) It has been stated that CVE-2018-20685 has been patched in november but there are currently no information available on the progress of patches regarding the other CVEs. Will there be a patched release any time soon?

On 6/23/20 9:39 AM, Robinson, Paul via llvm-dev wrote: > >> -----Original Message----- >> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Jay Foad via >> llvm-dev >> Sent: Tuesday, June 23, 2020 4:47 AM >> To: Mehdi AMINI <joker.eph at gmail.com> >> Cc: llvm-dev at lists.llvm.org; Matt Arsenault <arsenm2 at gmail.com>

On Wed, Jun 24, 2020 at 2:37 AM Chris Lattner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Jun 23, 2020, at 11:02 AM, Philip Reames <listmail at philipreames.com> > wrote: > > I'll note that reading along I haven't found any of the proposed changes > particularly worthwhile. I'm also not strongly opposed to any of them - I > just don't care

Fixed a coding style issue. Else should follow brace. Signed-off-by: David Archuleta Jr. <darchuletajr at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_display.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index afbf557..0d39e17 100644 ---

On Fri, Mar 09, 2018 at 08:26:03AM +0530, Vaibhav Murkute wrote: > Fixed a coding style issue. > > Signed-off-by: Vaibhav Murkute <vaibhavmurkute88 at gmail.com> > --- > drivers/vhost/vsock.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Stefan Hajnoczi <stefanha at redhat.com> -------------- next part -------------- A non-text attachment

From: Vaibhav Murkute <vaibhavmurkute88 at gmail.com> Date: Fri, 9 Mar 2018 08:26:03 +0530 > Fixed a coding style issue. > > Signed-off-by: Vaibhav Murkute <vaibhavmurkute88 at gmail.com> Applied to net-next, thanks.

R CMD build does not actually run any R code, it just puts the files together into a .tar.gz archive. R CMD INSTALL will run the R code, and fail. Gabor On Sat, Jan 25, 2020 at 4:59 PM Andy Manka <andy.manka at gmail.com> wrote: > > > If you start a function in one file but don't close it, the package > will still build if you manage to close it in a later file. Like so: