similar to: [PATCH] dash: cd fix getpwd

Commit-ID: 3722d88daf36c22e86e85b56a2aba70a0e059581 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=3722d88daf36c22e86e85b56a2aba70a0e059581 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Fri, 25 Jan 2019 00:04:40 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Fri, 25 Jan 2019 02:57:21 +0000 [klibc] dash: Fix some cosmetic

Commit-ID: da8aee4bf2577ec47037705dd09a8ab3e7d5c666 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=da8aee4bf2577ec47037705dd09a8ab3e7d5c666 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Fri, 25 Jan 2019 00:04:40 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 20:29:23 +0000 [klibc] dash: Fix some cosmetic

The getpwd() function in dash assumed than getcwd(0, 0) will allocate the buffer dynamically using malloc(); however, this glibc extension is not implemented by klibc. Make getpwd() use a temporary buffer and invoke savestr() itself instead of relying on a nonstandard extension. Signed-off-by: Sergey Vlasov <vsu at altlinux.ru> --- Alternatively, you may pull from the following git repo

Commit-ID: ff52f9cbec8aa6ef0c1fc4e07e8b947c41d643cf Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=ff52f9cbec8aa6ef0c1fc4e07e8b947c41d643cf Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Tue, 20 Nov 2018 10:09:26 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: eval: Use

Hi folks, I have been stumped on a compilation problem when I tried to build 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since the default C standard of Clang is c99 while that of gcc is c89. It reported this error: ./c-gperf.h:14:1: error: unknown type name 'inline' inline ^

Commit-ID: 166a88f4568067378ddce23b91be7b4ec9a9dfb4 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=166a88f4568067378ddce23b91be7b4ec9a9dfb4 Author: Herbert Xu <herbert at gondor.apana.org.au> AuthorDate: Sat, 19 May 2018 02:39:52 +0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Sat, 28 Mar 2020 21:42:55 +0000 [klibc] dash: eval: Add

On 01/18/2011 06:38 PM, Bin Zeng wrote: > Hi folks, > > I have been stumped on a compilation problem when I tried to build > 176.gcc of SPEC CPU2000 with clang v 2.8 (trunk 427) on Linux and intel. > First, I tried to compile with 'clang -std=c89 *.c -o gcc.clang' since > the default C standard of Clang is c99 while that of gcc is c89. It > reported this error: >

https://bugzilla.mindrot.org/show_bug.cgi?id=1235 donkishoot at wanadoo.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |donkishoot at wanadoo.fr --- Comment #5 from donkishoot at wanadoo.fr 2009-06-24 23:41:20 --- I have a bug that i think is

--------------------------------------------------------------------- Red Hat, Inc. Red Hat Security Advisory Synopsis: Updated ucd-snmp packages available Advisory ID: RHSA-2001:163-20 Issue date: 2001-12-04 Updated on: 2002-02-12 Product: Red Hat Linux Keywords: ucd-snmp protos test suite snmp Cross references: Obsoletes:

New clangs emit some warnings. The code isn't wrong, but should be updated to prevent warning creep. Bill Wendling (3): [klibc] dash: shell: Fix clang warnings [klibc] dash: shell: Fix clang warnings about format string [klibc] Kbuild: use an enum to silence a clang warning usr/dash/eval.c | 6 +++--- usr/dash/jobs.c | 2 +- usr/kinit/nfsmount/dummypmap.c

On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

When compile 403.gcc, there are link errors. 1) environment 1.1) OS Linux gnode107 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux *1.2) The default GCC compiler is * gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for

Dear all, I am using the save(moransI,file=saveString) to save a variable called moransI to a file. This works well but unfortunately I have to open R every time I want to look to the contents. Would it be also possible to have a second line that saves the contents of the moransI variable in a normal txt file? The ideal is inside the txt file to get what you see in R's console when you

This is v3 of my disk series. What were previously patches 01-06 have been applied. These are the tested and updated remainder, addressing the previous comments. 1 Preparatory work. 2-4 The new parser and its documentation. 5-6 Replace old parsers with calls to the new one. 7-8 Two features, one of them essential. 9 Basic test suite for disk string parsing, as adhoc script.

I think I posted this patch before, but it looks like it was in December 2012 (!). 1/1 libxl: introduce an option for disabling the non-O_DIRECT workaround Ideally it would go into 4.4, at least. Provided the corresponding qemu part has gone into qemu-xen, which I think it has. Can anyone confirm ?

https://bugs.freedesktop.org/show_bug.cgi?id=51809 Bug #: 51809 Summary: jReality "Export->Image" on nouveau corrupts memory / locks up X server Classification: Unclassified Product: Mesa Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW

Here is v11. Fixed comments/bugs and updated against the latest libvirt.git. Changes v10->v11: - fixed comments on each patches - fixed cgroup handling in patch 3. - fixed MODIFY_CURRENT handling in patch 4. most of diff comes from refactoring qemu/qemu_driver.c -- conf/domain_conf.c | 40 ++ conf/domain_conf.h | 5 libvirt_private.syms | 3 qemu/qemu_driver.c | 727

This is a series of patches for clang compatibility: - Using flags needed flags and removing unsupported flags. - Adding support for clang's LLD linker. - Removing a variety of warnings. Bill Wendling (3): [klibc] Kbuild: use "libc.a" with clang [klibc] Kbuild: Add "-fcommon" for clang builds [klibc] Clean up clang warnings Michael Davidson (1): [klibc] Kbuild:

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take