search for: cstrings

Hi all, I would like to combine elements of a vector: vec <- c("astring", "b", "cstring", "d", "e") > vec [1] "astring" "b" "cstring" "d" "e" such that for every element that contains "string" at the end, it is combined with the next element, so that I get this:

(forgot to CC llvmdev) On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <glider at google.com> wrote: > Hey Anna, Nick, Ted, > > We've the following problem with string literals under ASan on Mac. > Some global string constants end up being put into the .cstring > section, for which the following rules apply: > - the strings can't contain zeroes in their

Alexander, On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const). But, CF/NSString literals will be problematic. The compiler emits a static

On Sat, 3 Jul 2004, Chris wrote: > >That should work fine. I'm not familiar at all with internix, but it >appears to have a buggy header or something. From what I understand, >internix is a posix layer for windows. Have you tried compiling under >cygwin? No, not yet. >If you grab the latest CVS sources, they should work fine with >cygwin, and will probably work

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- generator/rust.ml | 137 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) diff --git a/generator/rust.ml b/generator/rust.ml index a229d5eac..aa8b249ff 100644 --- a/generator/rust.ml +++ b/generator/rust.ml @@ -59,8 +59,10 @@ let generate_rust () = generate_header CStyle LGPLv2plus; pr

--- generator/rust.ml | 461 +++++++++++++++++++++++++++++++--------------- 1 file changed, 311 insertions(+), 150 deletions(-) diff --git a/generator/rust.ml b/generator/rust.ml index 79e16dfc6..ee65b1073 100644 --- a/generator/rust.ml +++ b/generator/rust.ml @@ -61,14 +61,16 @@ let generate_rust () = pr " use std::collections; use std::convert; +use std::convert::TryFrom; use

Hi Guys I'm trying to port and build LLVM to the Interix environment. I've succeded until the Interix version of gcc program executes: Before the patch: gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' gmake[1]: Leaving directory `/usr/local/src/llvm/lib/Support' gmake[1]: Entering directory `/usr/local/src/llvm/lib/Support' Compiling CommandLine.cpp

Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 55101) +++ include/llvm/ADT/APInt.h (working copy) @@ -20,6 +20,7 @@ #include <cassert> #include <iosfwd> #include <string> +#include <cstring> namespace llvm { class Serializer; -------------- next part -------------- An

>From: Misha Brukman <brukman at uiuc.edu> >Date: Sat, 3 Jul 2004 19:33:12 -0500 >Well, the patch adds #include <cstring> to CommandLine.cpp, so you >should try the patch first. If it does not work, then the Interix SDK ><cstring> is not a fully complete substitue for <string.h>, which it >should be, then you may have to manually try changing the

Hi, On Fedora 9 GCC 4.3, LLVMCConfigurationEmitter.cpp needs #include <typeinfo>. ValueTracking.cpp needs #include <cstring>. Thanks. --Zhongxing Xu -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080603/38f917f4/attachment.html>

The Constants.cpp file returns a ConstantAggregateZero object when you pass it a c"\000" string. Here is the code: Constant *ConstantArray::get(const ArrayType *Ty, const std::vector<Constant*> &V) { // If this is an all-zero array, return a ConstantAggregateZero object if (!V.empty()) { Constant *C = V[0]; if (!C->isNullValue())

There is a problem with Objective-C code where a null string is placed in the wrong section. If we have this code: #include <Foundation/Foundation.h> void foo() { NSLog(@""); } The null string is defined like this: .const .lcomm LC,1,0 ## LC Causing our linker to go nuts, because it expects anonymous strings to be in the __cstring section. I came up with the attached

Hi all, int main() { t(""); return 0; } On Mac OS X, llvm-gcc compiles the zero-sized string to: .lcomm LC,1,0 gcc: .cstring LC0: .ascii "\0" The difference seems innocent enough. However, in objc if the zero- sized string is part of a cfstring, it causes a problem. The linker expects it in the readonly __cstring section, but llvm puts it in the

Patch 9 is a kind of dumping ground of all kinds of stuff. It may be better to spend some time with git rebase -i trying to work this into more coherent patches. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live

On Jan 26, 2009, at 4:07 PMPST, Bill Wendling wrote: > There is a problem with Objective-C code where a null string is placed > in the wrong section. If we have this code: > > #include <Foundation/Foundation.h> > void foo() { > NSLog(@""); > } > > The null string is defined like this: > > .const > .lcomm LC,1,0 ## LC > > Causing our

This is compiling the Trunk revision from last Friday: reference out of range from _llvm_regerror (1000437F0) in ../../lib/libLLVMSupport.a(regerror.c.o) to cstring=0 (0) in ../../lib/libLLVMSupport.a(regerror.c.o) ld: rel32 out of range in _llvm_regerror from ../../lib/libLLVMSupport.a(regerror.c.o) clang-3: error: linker command failed with exit code 1 (use -v to see invocation) OS X 10.6,

On Jun 3, 2008, at 6:48 AM, Zhongxing Xu wrote: > Hi, > > On Fedora 9 GCC 4.3, > > LLVMCConfigurationEmitter.cpp needs #include <typeinfo>. > ValueTracking.cpp needs #include <cstring>. Fixed, thanks: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080602/063303.html -Chris

On 24 November 2016 at 15:04, Hal Finkel <hfinkel at anl.gov> wrote: >> Creating constexpr StringRefs isn't trivial as strlen isn't portably >> constexpr and std::char_traits<char>::length is only constexpr in >> C++17. > > Why don't we just create our own traits class that has a constexpr length, and then we can switch over to the standard one when

From: Hiroyuki_Katsura <hiroyuki.katsura.0513@gmail.com> --- configure.ac | 2 + generator/bindtests.ml | 63 +++++ generator/main.ml | 2 +- generator/rust.ml | 423 +++++++++++++++++----------- generator/rust.mli | 5 +- rust/.gitignore | 2 + rust/Makefile.am

On Wed, Mar 8, 2017 at 2:28 PM Tim Shen <timshen at google.com> wrote: > On Wed, Mar 8, 2017 at 1:49 PM David Blaikie <dblaikie at gmail.com> wrote: > > So I stumbled across an issue that I think is a bit fundamental: > > The xray runtime uses the C++ standard library. > > This seems like a problem because whatever C++ standard library is used to > compile the