similar to: [LLVMdev] Some fixes for the GetMainExecutable function

On Sep 2, 2010, at 10:03 AM, Kees van Reeuwijk wrote: > - snprintf(buf, PATH_MAX, "%s//%s", dir, bin); There's no comment, and no mention in the commit message. It seems pretty safe to fix. > Also, the if-all-else-fails return value of GetMainExecutable is an empty path, but since the users of this function don't test for that, this choice leads to rather obscure

On 09/02/2010 07:51 PM, Dan Gohman wrote: > > On Sep 2, 2010, at 10:03 AM, Kees van Reeuwijk wrote: > >> - snprintf(buf, PATH_MAX, "%s//%s", dir, bin); > > There's no comment, and no mention in the commit message. > It seems pretty safe to fix. > >> Also, the if-all-else-fails return value of GetMainExecutable is an empty path, but since the users of

Hello, I think I have come across an inconsistency between gcc and clang/llvm with respect to returning small structs. Given the following code: > struct s { > int a; > int b; > }; > > struct s3 { > int a; > int b; > int c; > }; > > struct s new_s(int v){ > struct s res; > res.a = v; > res.b = -v; > return res;

Hi Kees, You added some support for Minix to LLVM's copy of googletest: http://llvm.org/viewvc/llvm-project?view=rev&revision=100895 Is it still being used? If so, would you mind pushing these patches upstream to the googletest project: http://code.google.com/p/googletest/ Otherwise we may drop them, because it makes it harder to import new releases of googletest into the LLVM

On 27 July 2011 11:20, dr. ir. Kees van Reeuwijk <reeuwijk at few.vu.nl> wrote: > At the time I submitted  those patches I also submitted them to googletest. As far as I know they got accepted, although I didn't verify that. OK, I see from this thread: http://groups.google.com/group/googletestframework/browse_thread/thread/3081a14965764366/332ce9869f4bbe31 ... that rather than add

Hello, First of all, happy new year! I am interested in the hot plugging facilities of libvirt, in particular in what qemu calls 'hot add' of network interface cards. (And also the reverse: hot unplugging/removing of NICs.) I think I am overlooking something, but so far the best I have been able to find is: http://libvirt.org/sources/virshcmdref/html/ and it is not entirely clear

Full_Name: Murray Stokely Version: 2.10.1 OS: Linux Submission from: (NULL) (216.239.45.4) The Defn.h header includes limits.h for PATH_MAX and then checks if it hasn't been defined and if not sets something manually. Some of the R code uses PATH_MAX but a lot of other functions in unix/sys-unix.c and main/startup.c just hardcodes a limit of 256 characters. In my environment this is not

hello, asteriskers: I compiled asterisk under arm-linux. i am using asterisk 1.4.2. i can run ./configure and menuselect with embedded modules. but running make comes out errors: ranlib libmxml.a make[3]: Leaving directory `/usr/src/asterisk-1.4.2/menuselect/mxml' cc -Wall -o menuselect.o -g -c -D_GNU_SOURCE menuselect.c cc -Wall -o menuselect_curses.o -g -c -D_GNU_SOURCE

This is needed as the basis for the readlink -f option. Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- --- a/usr/include/stdlib.h +++ b/usr/include/stdlib.h @@ -92,4 +92,6 @@ static __inline__ int grantpt(int __fd) return 0; /* devpts does this all for us! */ } +__extern char *realpath(const char *, char *); + #endif /* _STDLIB_H */ --- a/usr/klibc/Kbuild +++

I was sent this from Mark Miller. Should we be using MAXPATHLEN instead of PATH_MAX in the upstream tree? Not all systems define PATH_MAX. - Ben --- sftp-int.c.orig Sat Feb 10 13:56:08 2001 +++ sftp-int.c Sun Feb 11 23:33:26 2001 @@ -435,5 +435,5 @@ unsigned long n_arg; Attrib a, *aa; - char path_buf[PATH_MAX]; + char path_buf[MAXPATHLEN]; path1 =

Hello, Using PATH_MAX is not a good idea: POSIX says that that definition is facultative, in case the system does not impose any limit on path length. Some systems may also set PATH_MAX to a quite high value, and we would hence consume a lot of stack. Samuel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel

Hi, I recently downloaded and built dovecot-2.2.2 and dovecot-2.2-pigeonhole-0.4.0 on GNU/Linux and GNU/Hurd. The changes needed will be sent to the Debian maintainer shortly. Latest Debian release is 2.1.7-7 and dovecot-2.1-pigeonhole-0.3.1. When building dovecot-2.2.2 there were no PATH_MAX problems on GNU/Hurd, thank you for that. However, pigeonhole 0.4.0 had one remaining PATH_MAX construct.

blkid_probe_get_wholedisk_devno() isn''t available in some older versions of libblkid. It was used to work around an old bug in blkid_devno_to_wholedisk(), but that has been fixed since 5cd0823 libblkid: fix blkid_devno_to_wholedisk(), present in util-linux 2.17 and beyond. If we happen to be missing that fix, the worst that happens is that we''d fail to detect that a device is

Not sure if this is me or not, because this is the first time I've built LLVM on Cygwin, but I can't get a working compile. I've configured with the following options: $ ./configure --with-llvmgccdir=/cygdrive/i/Projects/llvm-gcc4.2-2.2 --enable-debug-runtime --enable-jit --enable-targets=x86 Configure doesn't suggest there's anything wrong, but when I try make, I almost

On Tuesday 23 September 2014 17:20:35 Hu Tao wrote: > Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> > --- > daemon/inotify.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) While I'd personally get rid of PATH_MAX at all, I understand the Linux inotify implementation relies on it... > > diff --git a/daemon/inotify.c b/daemon/inotify.c > index

I get the following problem building LLVM 2.7 on AIX 6: gmake[1]: Entering directory `/home/home/ac/psimmons/llvm/llvm-2.7/lib/System' llvm[1]: Compiling Path.cpp for Release build In file included from Path.cpp:262: Unix/Path.inc: In static member function 'static llvm::sys::Path llvm::sys::Path::GetTemporaryDirectory(std::string*)': Unix/Path.inc:142: error: 'mkdtemp' was

On Wed, March 12, 2008 11:23 pm, Chris Lattner wrote: > Please attach patches as attachments (and name the file ".patch" just > in case). Mail readers commonly munge them (e.g. by removing trailing > whitespace) if not, which prevents the patch from applying. Hmm... What you got was the result of me telling Thunderbird to attach a file called

Hi Sanjiv, On Wed, Jul 1, 2009 at 7:02 PM, Sanjiv Gupta<sanjiv.gupta at microchip.com> wrote: > I found out the problem. Looks like I can not rely on argv[0] to contain the > full path of the executable always. Yeah, that's what I was thinking. > Can I rely on: > static Path GetMainExecutable(const char *argv0, void *MainAddr); Clang relies on it. According to

Hello folks, Is it possible to extend log message as large as PATH_MAX? Current length of message format including file path is small against linux PATH_MAX, 4096. diff --git a/log.c b/log.c index ad12930..95df4a9 100644 --- a/log.c +++ b/log.c @@ -359,7 +359,7 @@ log_redirect_stderr_to(const char *logfile) log_stderr_fd = fd; } -#define MSGBUFSIZ 1024 +#define MSGBUFSIZ 5192 void

I found out the problem. Looks like I can not rely on argv[0] to contain the full path of the executable always. Can I rely on: static Path GetMainExecutable(const char *argv0, void *MainAddr); is it Cross-platform? What to pass for second parameter here. C++ forbids taking address of "main", and the "Main" of CompilerDriver is in a shared object here. - Sanjiv Sanjiv