search for: cfstrings

OSX Yosemite 10.10.3 Nut version 2.6.5 Installed via Macports Device is Cyberpower CP1000AVRLCD Device is visible and is monitored in the OSX control panel Error- macosx-ups -DD -a cyberpower Network UPS Tools - Mac OS X UPS meta-driver 1.0 (2.6.5-Unversioned directory) Warning: This is an experimental driver. Some features may not function correctly. 0.000000 debug level is '2'

> On Jun 26, 2015, at 9:25 PM, Charles Lepple <clepple at gmail.com> wrote: > > On Jun 26, 2015, at 8:35 AM, Sundeep Mediratta <smedius at gmail.com> wrote: > >> OSX Yosemite 10.10.3 >> Nut version 2.6.5 >> Installed via Macports >> Device is Cyberpower CP1000AVRLCD >> Device is visible and is monitored in the OSX control panel >>

On Jun 27, 2015, at 9:17 AM, Charles Lepple <clepple at gmail.com> wrote: > On Jun 26, 2015, at 11:07 PM, Sundeep Mediratta <smedius at gmail.com> wrote: > >> 0.000233 upsdrv_initups(): Power Sources blob: >> <CFArray 0x7ffd18605480 [0x7fff7443bed0]>{type = immutable, count = 1, values = ( >> 0 : <CFBasicHash 0x7ffd18605360 [0x7fff7443bed0]>{type

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

...ng section. > > My GCC-fu isn't great. Could someone review this to see if I broke > anything? I don't see anything obvious wrong, but this is an easy area to break. I'd recommend running the gcc testsuite and checking for regressions. Are you sure the problem is limited to CFStrings? That seems like the wrong thing to be checking somehow. > Thanks! > -bw -------------- next part -------------- A non-text attachment was scrubbed... Name: cfstring.diff Type: application/octet-stream Size: 2803 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/...

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

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

Hi all, Right now the Mangler::getValueName() method will produce something like "__unnamed_1_37" for a global value that doesn't have a name. This is wrong for Objective-C where CFStrings will get these labels, thus preventing the linker from coalescing them. [/tmp]> nm -s __DATA __cfstring -m foo.o 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 ... I think that prepending the PrivateGlobalPrefix...

(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

On Fri, Jan 9, 2009 at 5:40 PM, Evan Cheng <evan.cheng at apple.com> wrote: > 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 > read / write bss section. That seems extremely weird... what sort of magic is objc using

...that solve the problem? Dan On Nov 23, 2008, at 2:15 AM, Bill Wendling wrote: > Hi all, > > Right now the Mangler::getValueName() method will produce something > like "__unnamed_1_37" for a global value that doesn't have a name. > This is wrong for Objective-C where CFStrings will get these labels, > thus preventing the linker from coalescing them. > > [/tmp]> nm -s __DATA __cfstring -m foo.o > 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 > 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 > ... > > I think tha...

...column -fsplit-ivs-in-unroller # -ftoplevel-reorder -ftree-loop-im -ftree-loop-ivcanon # -ftree-loop-optimize -ftree-vect-loop-version -funit-at-a-time # -fverbose-asm -fzero-initialized-in-bss -m128bit-long-double -m32 -m80387 # -maccumulate-outgoing-args -malign-stringops -matt-stubs # -mconstant-cfstrings -mfancy-math-387 -mfp-ret-in-387 -mieee-fp -mmmx # -mno-red-zone -mno-sse4 -mpush-args -msse -msse2 -msse3 # -mwarn-nonportable-cfstrings # Compiler executable checksum: 8b71d7bb9d5d18146938b09f1ac40213 from... touch t.cc llvm-gcc-4 -fverbose-asm t.cc -S

The source for the samba components in MacOS X Server is located at: http://www.opensource.apple.com/tools/cvs ('samba' module) The latest vendor branch is samba2.2.1a. The main branch includes the following modifications (see diffs below).. 1) DirectoryService suport (encrypted authentication) 2) CFString usage (DOS code page <-> decomposed UTF8) 3) smbstatus -r (raw dump of user

...omeone review this to see if I broke >> anything? > > I don't see anything obvious wrong, but this is an easy area to break. > I'd recommend running the gcc testsuite and checking for regressions. > Okay, that's a good plan. > Are you sure the problem is limited to CFStrings? That seems like the wrong > thing to be checking somehow. > Nick Kledzik had this to say about the initial radar (<rdar://problem/6479858>): "1/7/09 11:15 PM Nick Kledzik: The linker issues this warning when the .o file contains a literal NSString (e.g. @"hello") and t...

...; > On Nov 23, 2008, at 2:15 AM, Bill Wendling wrote: > >> Hi all, >> >> Right now the Mangler::getValueName() method will produce something >> like "__unnamed_1_37" for a global value that doesn't have a name. >> This is wrong for Objective-C where CFStrings will get these labels, >> thus preventing the linker from coalescing them. >> >> [/tmp]> nm -s __DATA __cfstring -m foo.o >> 00000000000244d0 (__DATA,__cfstring) non-external __unnamed_1_0 >> 00000000000244b0 (__DATA,__cfstring) non-external __unnamed_1_1 >> ....

On Nov 24, 2008, at 11:07 AM, Chris Lattner wrote: > > On Nov 24, 2008, at 11:01 AM, Bill Wendling wrote: > >> The symbols I'm interested in already have internal linkage (as you >> would expect). But because the mangler is in charge of assigning them >> names, they never seem to be decorated with the 'L' in front. . . . > > If you use

...ame=CFStringCreateWithCString(NULL, name, kCFStringEncodingUTF8); + if(cfStringName==NULL) Putting this initialisation: + char parentPath[MAXPATHLEN+1], name[MAXNAMLEN+1]; unsigned int index=0, nameLength; It will need another buffer, but we would need anyway. We can't replace chars on CFStrings, we would need to pass by a CFMutableString (need another buffer). Or we would need to manipulate the Unicode string at the end, but I'm not sure how to do it. You could try: + CFStringGetCharacters(cfStringName, range, unicharName); while(index<range.length) { if(unicharName[index...