How to recognize mutability?
I am trying to build my own version of NSKeyed(Un)Archiver. But I do not know how to recognise mutability. 1. use isKindOfClass: [NSMutableString class] disadvantage: all strings turn out to be mutable 2. use respondsToSelector: @selector(appendString:) disadvantage: all strings turn out to be mutable 3. mutate the string (in a @try block) if exception, then immutable, else mutate the string back. disadvantage: very inelegant and probably quite slow 4. use some undocumented (which?) method disadvantage: might break with next OS release 5. anything else? Gerriet. P.S. I want my own archiver for 2 reasons: 1. NSKeyedArchiver can store only certain strings 2. It creates files, which are 10 times bigger than my version (and 5 times bigger than NSArchiver) ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 20 Feb, 2013, at 9:10, Gerriet M. Denkmann wrote: > I am trying to build my own version of NSKeyed(Un)Archiver. > > But I do not know how to recognise mutability. Use "classForKeyedArchiver" (or one of the other variants) to detect as which class an object wants to be archived. This will return [NSMutableString class] for mutable strings and [NSString class] for immutable ones. Ronald > > 1. use isKindOfClass: [NSMutableString class] > disadvantage: all strings turn out to be mutable > > 2. use respondsToSelector: @selector(appendString:) > disadvantage: all strings turn out to be mutable > > 3. mutate the string (in a @try block) if exception, then immutable, else > mutate the string back. > disadvantage: very inelegant and probably quite slow > > 4. use some undocumented (which?) method > disadvantage: might break with next OS release > > 5. anything else? > > Gerriet. > > P.S. > I want my own archiver for 2 reasons: > 1. NSKeyedArchiver can store only certain strings > 2. It creates files, which are 10 times bigger than my version (and 5 times > bigger than NSArchiver) > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/ronaldoussoren%40mac.com > > This email sent to ronaldousso...@mac.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 2/20/13 9:10 AM, Gerriet M. Denkmann wrote: P.S. I want my own archiver for 2 reasons: 1. NSKeyedArchiver can store only certain strings I find that very hard to believe. Markus -- __ Markus Spoettl ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Issue with Custom View Drag and Drop
Hello,
I'm implementing the Drag and Drop functionality over the same Custom View. My6
Custom is acting as source and Destination. I've implemented it according to
Apple's Guideline for Drag and Drop wit Custom Views. I've started the Drag and
Drop from mouseDown: event.
Normally it works fine, no issues. But sometimes performDragDropOperation:
doesn't get called, instead mouseUp event gets called.
In successful scenario(When drag and drop works fine) I never get call to
mouseUp: but when performDragDropOperation: doesn't get called I get the call
to mouseUp event.
I also observed that when mouseUp gets called after that call gets stuck in
draggingUpdated: - means draggingUpdated gets called repeatedly(I verified it
using console print messages) even if I hover over my Custom View. To finish
the drag and drop I have to click twice or thrice on view.
Following is the code for the same.
-(void)mouseDown:(NSEvent *)pTheEvent {
lastPoint = [pTheEvent locationInWindow];
NSPoint tvarMouseInWindow = [pTheEvent locationInWindow];
NSPoint tvarMouseInView = [self convertPoint:tvarMouseInWindow
fromView:nil];
NSSize zDragOffset = NSMakeSize(0.0, 0.0);
NSPasteboard *zPasteBoard;
zPasteBoard = [NSPasteboard pasteboardWithName:NSDragPboard];
[zPasteBoard declareTypes:[NSArray arrayWithObject:NSTIFFPboardType]
owner:self];
[zPasteBoard setData:[self.nsImageObj TIFFRepresentation]
forType:NSTIFFPboardType];
dragImage = [NSImage imageNamed:@"dragimage1"];
[self dragImage:dragImage
at:tvarMouseInView
offset:zDragOffset
event:pTheEvent
pasteboard:zPasteBoard
source:self
slideBack:YES];
return;
}
- (NSDragOperation)draggingEntered:(id )sender
{
return NSDragOperationMove;
}
- (BOOL)prepareForDragOperation:(id )sender {
return YES;
}
- (BOOL)performDragOperation:(id )sender {
NSPasteboard *zPasteboard = [sender draggingPasteboard];
self.nsImageObj = [[NSImage alloc] initWithPasteboard: zPasteboard];
return YES;
}
- (void)concludeDragOperation:(id )sender {
[self setNeedsDisplay:YES];
}
- (void)draggedImage:(NSImage *)image movedTo:(NSPoint)screenPoint
{
NSPoint pt = [[self window] convertScreenToBase:screenPoint];
lastPoint = [self convertPoint:pt fromView: nil];
dragImage = image;
[self setNeedsDisplay:YES];
}
-(void)mouseDragged:(NSEvent *)pTheEvent {
lastPoint = [pTheEvent locationInWindow];
[self setNeedsDisplay:YES];
} // end mouseDragged
-(void) mouseUp:(NSEvent *)theEvent
{
lastPoint = [theEvent locationInWindow];
[self setNeedsDisplay:YES];
}
- (BOOL)becomeFirstResponder
{
return YES;
}
Regards
Omkar
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Ltd. does not accept any liability for virus infected mails.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: No mouseExited when switching windows
On Feb 19, 2013, at 17:37:26, Shane Stanley wrote: > Don't you mean: > > [center addObserver:self selector:@selector(windowDidResignKey:) Doh! Thanks. First time I've used @selector since the early days of Cocoa. So now I have that working, and am handling mouseEntered, mouseMoved, mouseExited, and cursorUpdate for my control. The only thing that's not yet right is what to do after this series of events: 1. Move the mouse into my control. I hilite a specific area with the "hover" image. 2. Command-` to switch to another window that may or may not intersect with the first window (doesn't matter). I have *not* moved the mouse. I get a windowDidResignKey message, so I remove the hilite. 3. Command-` back to the first window, still without moving the mouse, which is still inside my tracking area. At this point, I should hilite that same area with the "hover" image. Yet I can't because the only thing I can think of doing the "right" way would be to receive a NSWindowDidBecomeKeyNotification notification. But this doesn't give me the current mouse location. I could ask NSEvent for its global mouse location, but that doesn't sound very Cocoa-y. And I can't save and restore the state because the mouse *could* have moved while the 2nd window was active. I just wish NSTrackingArea would send mouseExited with the window loses its mainness or keyness (choosable by the owner) and a mouseEntered when becoming main/key. That makes the most logical sense. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No mouseExited when switching windows
On Feb 20, 2013, at 7:55 AM, Steve Mills wrote: > At this point, I should hilite that same area with the "hover" image. Yet I > can't because the only thing I can think of doing the "right" way would be to > receive a NSWindowDidBecomeKeyNotification notification. But this doesn't > give me the current mouse location. I could ask NSEvent for its global mouse > location, but that doesn't sound very Cocoa-y. Why not? It's the best information you have on hand. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No mouseExited when switching windows
On Feb 20, 2013, at 10:02:37, Kyle Sluder wrote: > On Feb 20, 2013, at 7:55 AM, Steve Mills wrote: > >> At this point, I should hilite that same area with the "hover" image. Yet I >> can't because the only thing I can think of doing the "right" way would be >> to receive a NSWindowDidBecomeKeyNotification notification. But this doesn't >> give me the current mouse location. I could ask NSEvent for its global mouse >> location, but that doesn't sound very Cocoa-y. > > Why not? It's the best information you have on hand. Because with proper Cocoa event, you're given everything you need rather than having to get it via brute force (get global point, convert to window coords, and convert to view coords). I was hoping someone might point out something that would do it the right way that I'm not aware of. If not, I'll go with brute force. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
LLVM 4.2 bug: crash on 10.6.8 in loop iteration
If you upgraded to Xcode 4.6 and suddenly you've been seeing crashes when
deploying to Snow Leopard, you might want to go back to Xcode 4.5.2.
In a nutshell, the following crashes on 10.6.8 when compiled with Apple LLVM
4.2 with a deployment target of 10.6.
NSArray *array = [[NSArray alloc] init];
for (NSString *string in array)
{
return;
}
I just filed rdar://13253340 and copied it to Open Radar:
--Andy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: LLVM 4.2 bug: crash on 10.6.8 in loop iteration
Is it the empty array that's causing the crash? Does it still crash if
the array has at least one object?
--
Gary L. Wade
http://www.garywade.com/
On 2/20/2013 8:33 AM, "Andy Lee" wrote:
>If you upgraded to Xcode 4.6 and suddenly you've been seeing crashes when
>deploying to Snow Leopard, you might want to go back to Xcode 4.5.2.
>
>In a nutshell, the following crashes on 10.6.8 when compiled with Apple
>LLVM 4.2 with a deployment target of 10.6.
>
>NSArray *array = [[NSArray alloc] init];
>for (NSString *string in array)
>{
>return;
>}
>
>I just filed rdar://13253340 and copied it to Open Radar:
>
>
>
>--Andy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: LLVM 4.2 bug: crash on 10.6.8 in loop iteration
On Wed, 20 Feb 2013 11:33:46 -0500, Andy Lee said: >If you upgraded to Xcode 4.6 and suddenly you've been seeing crashes >when deploying to Snow Leopard, you might want to go back to Xcode 4.5.2. > >In a nutshell, the following crashes on 10.6.8 when compiled with Apple >LLVM 4.2 with a deployment target of 10.6. Does Xcode 4.6 even claim to support deploying to 10.6? IIRC, all recent releases' release notes say its for developing for 10.7 and 10.8. Cheers, -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: No mouseExited when switching windows
On Wed, Feb 20, 2013, at 08:21 AM, Steve Mills wrote: > Because with proper Cocoa event, you're given everything you need rather > than having to get it via brute force (get global point, convert to > window coords, and convert to view coords). I was hoping someone might > point out something that would do it the right way that I'm not aware of. This isn't true. Events come in different flavors. You can't ask for the mouse position for a flags-changed event, for example. Since the mouse is decoupled from any individual application, it makes sense to sometimes ask for its current position outside of the event stream. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: LLVM 4.2 bug: crash on 10.6.8 in loop iteration
On Feb 20, 2013, at 8:33 AM, Andy Lee wrote:
> If you upgraded to Xcode 4.6 and suddenly you've been seeing crashes when
> deploying to Snow Leopard, you might want to go back to Xcode 4.5.2.
>
> In a nutshell, the following crashes on 10.6.8 when compiled with Apple LLVM
> 4.2 with a deployment target of 10.6.
>
>NSArray *array = [[NSArray alloc] init];
>for (NSString *string in array)
>{
>return;
>}
>
> I just filed rdar://13253340 and copied it to Open Radar:
>
>
Are you using ARC? There's a known bug wherein Xcode 4.6 is unable to compile
ARC code for deployment on 10.6.
--
Greg Parker gpar...@apple.com Runtime Wrangler
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: LLVM 4.2 bug: crash on 10.6.8 in loop iteration
On Feb 20, 2013, at 9:23 AM, Sean McBride wrote: > Does Xcode 4.6 even claim to support deploying to 10.6? IIRC, all recent > releases' release notes say its for developing for 10.7 and 10.8. Xcode 4.6 itself only runs on 10.7 and 10.8, but it should be able to build for older deployment targets. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: LLVM 4.2 bug: crash on 10.6.8 in loop iteration
On Feb 20, 2013, at 12:43 PM, Greg Parker wrote:
> On Feb 20, 2013, at 8:33 AM, Andy Lee wrote:
>> If you upgraded to Xcode 4.6 and suddenly you've been seeing crashes when
>> deploying to Snow Leopard, you might want to go back to Xcode 4.5.2.
>>
>> In a nutshell, the following crashes on 10.6.8 when compiled with Apple LLVM
>> 4.2 with a deployment target of 10.6.
>>
>> NSArray *array = [[NSArray alloc] init];
>> for (NSString *string in array)
>> {
>> return;
>> }
>>
>> I just filed rdar://13253340 and copied it to Open Radar:
>>
>>
>
> Are you using ARC?
Yes.
> There's a known bug wherein Xcode 4.6 is unable to compile ARC code for
> deployment on 10.6.
Ah, okay -- thanks for the concrete info.
--Andy
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: No mouseExited when switching windows
On Feb 20, 2013, at 11:42:24, Kyle Sluder wrote: > This isn't true. Events come in different flavors. You can't ask for the > mouse position for a flags-changed event, for example. Since the mouse > is decoupled from any individual application, it makes sense to > sometimes ask for its current position outside of the event stream. Well, OK, I'll just have to do it that way. It's still wrong in this modern age of being given everything you need for the task at hand. The fact that flagsChanged doesn't send the mouse loc is IMO a design flaw. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSPipe eating up all available pipes on system.
I have written a daemon that listens for an incoming connection, runs a process using NSTask, and sends the output to the connection. After a couple of hours of receiving connections at varying lengths of time… The system has all of it's pipes taken, and the process stops sending responses to the connections. I know that the pipes are all taken because... If I was to run something in terminal such as "cat Makefile | less", less will not output anything. If I was to run git log, I would not get anything (git log outputs the history of a repository to less via a pipe). I made a test which shows the issue with an exception… Can someone help me find out how to close the pipes or something of the sort? https://dl.dropbox.com/u/610721/Eat%20Pipes.zip Thank you. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer's backgrounds filters having effect only on immediate parent?
Not exactly. Here is what the documentation says: backgroundFilters An array of Core Image filters to apply to the content immediately behind the layer. Animatable. @property(copy) NSArray *backgroundFilters Discussion Background filters affect the content behind the layer that shows through into the layer itself. Typically this content belongs to the superlayer that acts as the parent of the layer. These filters do not affect the content of the layer itself, including the layer’s background color and border. They also do not affect content outside of the layer’s bounds. So basically it can blur/filter other layers. So my question remains - why doesn't it filter all layers below it, but only the immediate parent layer? What seems suspicious about it is that the internets are not full of bitching about this gaping shortcoming, the search yields nothing, which makes me think that it must be working perfectly for everyone else, and I'm just missing something obvious. Any help please? On Wed, Feb 20, 2013 at 1:51 AM, Graham Cox wrote: > > On 20/02/2013, at 5:42 AM, Oleg Krupnov wrote: > > In my understanding, if I apply, say, a blur filter to layer's > background (CALayer->backgroundFilters), all layers that are behind > that layer - that is, immediate parent, grand parent, etc. and all > children and siblings of those parent and grandparents that are lower > in the tree of layers - should appear blurred. > > An experiment however shows that it's not the case. The background > blur filter only blurs the direct parent of the target layer, but not > its grandparent and other layers. > > The same applies for compositingFilter. > > Am I doing something wrong? > > Or, if this is the way it should work as documented, how do achieve > the effect I want? > > > > I think your understanding is incorrect. My interpretation of the docs is > simply that the background - that is to say, the background colour of the > layer - is filtered. If you think about how layers are composited, this is > the only interpretation that makes sense - how could a layer retroactively > apply a bunch of filters to things that have already been rendered? > > Setting the filters on the root layer or on some layer further up the tree > should achieve the effect you want, though most likely you'll want the > compositingFilters rather than the background filters property. > > > --Graham > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPipe eating up all available pipes on system.
On Feb 20, 2013, at 4:10 PM, Mr. Gecko wrote: > I have written a daemon that listens for an incoming connection, runs a > process using NSTask, and sends the output to the connection. After a couple > of hours of receiving connections at varying lengths of time… The system has > all of it's pipes taken, and the process stops sending responses to the > connections. I know that the pipes are all taken because... If I was to run > something in terminal such as "cat Makefile | less", less will not output > anything. If I was to run git log, I would not get anything (git log outputs > the history of a repository to less via a pipe). > > I made a test which shows the issue with an exception… Can someone help me > find out how to close the pipes or something of the sort? Run your program under the Object Allocations and Leaks instruments and see if it can identify NSPipe objects that are still alive after you think they shouldn't be. Then use the object retain/release history to try to figure out why. I didn't immediately see any memory management bugs. Can't hurt to have the static analyzer check, too. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: CALayer's backgrounds filters having effect only on immediate parent?
On Feb 20, 2013, at 2:12 PM, Oleg Krupnov wrote: > Not exactly. Here is what the documentation says: > > backgroundFilters > > An array of Core Image filters to apply to the content immediately > behind the layer. Animatable. > > @property(copy) NSArray *backgroundFilters > > Discussion > Background filters affect the content behind the layer that shows > through into the layer itself. Typically this content belongs to the > superlayer that acts as the parent of the layer. These filters do not > affect the content of the layer itself, including the layer’s > background color and border. They also do not affect content outside > of the layer’s bounds. > > So basically it can blur/filter other layers. So my question remains - > why doesn't it filter all layers below it, but only the immediate > parent layer? Because thats exactly what it said in the description you just posted. The Core Animation render model is that you start from the leaves, projecting and flattening those layers into its parent recursively. As such when you place a background filter on a layer, that filter affects the area in the parent that is under that layer. At that point, from a rendering perspective at least, the layer and its effects cease to exist, having been flattened into the parent. All the ways around flattening also disable filters (and other select properties of the layer) because getting them correct is reliant upon the flattening rendering model described above. > > What seems suspicious about it is that the internets are not full of > bitching about this gaping shortcoming, the search yields nothing, > which makes me think that it must be working perfectly for everyone > else, and I'm just missing something obvious. > > Any help please? > > On Wed, Feb 20, 2013 at 1:51 AM, Graham Cox wrote: >> >> On 20/02/2013, at 5:42 AM, Oleg Krupnov wrote: >> >> In my understanding, if I apply, say, a blur filter to layer's >> background (CALayer->backgroundFilters), all layers that are behind >> that layer - that is, immediate parent, grand parent, etc. and all >> children and siblings of those parent and grandparents that are lower >> in the tree of layers - should appear blurred. >> >> An experiment however shows that it's not the case. The background >> blur filter only blurs the direct parent of the target layer, but not >> its grandparent and other layers. >> >> The same applies for compositingFilter. >> >> Am I doing something wrong? >> >> Or, if this is the way it should work as documented, how do achieve >> the effect I want? >> >> >> >> I think your understanding is incorrect. My interpretation of the docs is >> simply that the background - that is to say, the background colour of the >> layer - is filtered. If you think about how layers are composited, this is >> the only interpretation that makes sense - how could a layer retroactively >> apply a bunch of filters to things that have already been rendered? >> >> Setting the filters on the root layer or on some layer further up the tree >> should achieve the effect you want, though most likely you'll want the >> compositingFilters rather than the background filters property. >> >> >> --Graham >> >> > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPipe eating up all available pipes on system.
Looks like every pipe is leaking. I cannot see a way to prevent the leak myself as I know the NSPipes are being released. It doesn't seem to crash with Auto Reference Counting… But boy, it eats memory and still leaks. So I would think this is an Apple bug. On Feb 20, 2013, at 4:31 PM, Ken Thomases wrote: > On Feb 20, 2013, at 4:10 PM, Mr. Gecko wrote: > >> I have written a daemon that listens for an incoming connection, runs a >> process using NSTask, and sends the output to the connection. After a couple >> of hours of receiving connections at varying lengths of time… The system has >> all of it's pipes taken, and the process stops sending responses to the >> connections. I know that the pipes are all taken because... If I was to run >> something in terminal such as "cat Makefile | less", less will not output >> anything. If I was to run git log, I would not get anything (git log outputs >> the history of a repository to less via a pipe). >> >> I made a test which shows the issue with an exception… Can someone help me >> find out how to close the pipes or something of the sort? > > Run your program under the Object Allocations and Leaks instruments and see > if it can identify NSPipe objects that are still alive after you think they > shouldn't be. Then use the object retain/release history to try to figure > out why. > > I didn't immediately see any memory management bugs. Can't hurt to have the > static analyzer check, too. > > Regards, > Ken > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSPipe eating up all available pipes on system.
I take that back, it still crashes with ARC… It crashes at run 4720. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTask arguments
Hi all Is there a way to feed an NSTask argument data when the command line tool in the task expects a file path argument? I would like to not actually create a file to use as the argument, but rather send data that would be in said file. Can this be done via NSFileHandle or NSPipe from NSData? ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 4:18 PM, dangerwillrobinsondan...@gmail.com wrote: > Is there a way to feed an NSTask argument data when the command line tool in > the task expects a file path argument? > I would like to not actually create a file to use as the argument, but rather > send data that would be in said file. > Can this be done via NSFileHandle or NSPipe from NSData? It is possible to send data to a task. For example, you can send data to the task's standard input file descriptor by using -[NSTask setStandardInput:]. However, this only works if the command line tool is expecting to read from standard input. There are conventions to ask a command line tool to read standard input instead of a file (for example, setting the file name argument to "-"), but you can't force the tool to do so. Check the tool's documentation. One alternative is to use a Unix named pipe. A named pipe is a pipe - one end writes, the other end reads - but it looks like a file in the filesystem and can be opened and read or written as if it were a file, as long as the reader or writer makes a single pass straight through the file. That means in some cases you can create a named pipe and pass that name to the command line tool. You would probably have to drop down to the C mkfifo() function to create the named pipe; I don't know if any Cocoa classes can create them. There are some other complications like preventing security holes (don't use /tmp) and cleaning up orphaned pipes if your app crashes or is killed while the pipe is open. The internet has examples of those problems and how to solve them. -- Greg Parker gpar...@apple.com Runtime Wrangler ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 21, 2013, at 9:46 AM, Greg Parker wrote: > On Feb 20, 2013, at 4:18 PM, dangerwillrobinsondan...@gmail.com wrote: >> Is there a way to feed an NSTask argument data when the command line tool in >> the task expects a file path argument? >> I would like to not actually create a file to use as the argument, but >> rather send data that would be in said file. >> Can this be done via NSFileHandle or NSPipe from NSData? > > It is possible to send data to a task. For example, you can send data to the > task's standard input file descriptor by using -[NSTask setStandardInput:]. > However, this only works if the command line tool is expecting to read from > standard input. There are conventions to ask a command line tool to read > standard input instead of a file (for example, setting the file name argument > to "-"), but you can't force the tool to do so. Check the tool's > documentation. > > One alternative is to use a Unix named pipe. A named pipe is a pipe - one end > writes, the other end reads - but it looks like a file in the filesystem and > can be opened and read or written as if it were a file, as long as the reader > or writer makes a single pass straight through the file. That means in some > cases you can create a named pipe and pass that name to the command line > tool. > > You would probably have to drop down to the C mkfifo() function to create the > named pipe; I don't know if any Cocoa classes can create them. There are some > other complications like preventing security holes (don't use /tmp) and > cleaning up orphaned pipes if your app crashes or is killed while the pipe is > open. The internet has examples of those problems and how to solve them. > > > -- > Greg Parker gpar...@apple.com Runtime Wrangler > > Thanks Greg. That pretty much answers it the way I thought it would be. The argument for the tool in question does not read standard in (though some of the other args do…) and that is why I asked this. I will look into the C level approaches available. At issue is precisely security because this arg expects a file path to a password file (very dumb, but no other option). It would be great if there were some Cocoa class that could handle this sort of thing with relative safety. My other option is to create a silly temp file somewhere with precise permissions, but that has its own obvious risk. This would not be a tool shipped to anyone so I'm not terribly worried, but I prefer to do this as right as possible. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 21 Feb 2013, at 00:42, Markus Spoettl wrote: > On 2/20/13 9:10 AM, Gerriet M. Denkmann wrote: >> P.S. >> I want my own archiver for 2 reasons: >> 1. NSKeyedArchiver can store only certain strings > > I find that very hard to believe. I find that very easy to proof: NSArray *a = @[ @"$nill", @"$null", @"$nall" ]; NSLog(@"%s NSKeyedArchiver archiving %@", __FUNCTION__, a); NSData *e = [ NSKeyedArchiver archivedDataWithRootObject: a ]; NSArray *b = [ NSKeyedUnarchiver unarchiveObjectWithData: e ]; NSLog(@"%s NSKeyedUnarchiver got %@", __FUNCTION__, b); /* NSKeyedArchiver archiving ( "$nill", "$null", "$nall" ) NSKeyedUnarchiver got () **/ Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 4:18 PM, dangerwillrobinsondan...@gmail.com wrote: > Is there a way to feed an NSTask argument data when the command line tool in > the task expects a file path argument? > I would like to not actually create a file to use as the argument, but rather > send data that would be in said file. > Can this be done via NSFileHandle or NSPipe from NSData? This isn’t really feasible, for reasons that have nothing to do with NSTask. The tool’s argument list is just an array of strings. The tool is going to interpret one of those strings as a filesystem path and do something that will end up asking the filesystem to open the file at that path (e.g. the open() system call.) The system call has no idea where that path string came from. You could conceivably create a fake volume in the filesystem that didn’t correspond to any real file but just returned your data when read (something like what the disk images driver does) … but the moment you did this, your data would exist in the filesystem and would be accessible to any other process that tried to open and read the same path. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On Feb 20, 2013, at 12:10 AM, Gerriet M. Denkmann wrote: > But I do not know how to recognise mutability. > > 1. use isKindOfClass: [NSMutableString class] > disadvantage: all strings turn out to be mutable This is somewhat of an FAQ. There is no way to do this (without groping inside private data structures.) In practice, all NSStrings are instances of a few CF-implemented string classes that support both mutable and immutable strings. These internal classes implement the API of both NSString and NSMutableString. I think you’ve posted about this stuff before? It really sounds like you’re on a wild goose chase down a rathole, with this archiving project. I suggest you back up a ways and look at the problem from a high level and find a different way to solve it. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Wed, Feb 20, 2013, at 08:11 PM, Jens Alfke wrote: > You could conceivably create a fake volume in the filesystem that didn’t > correspond to any real file but just returned your data when read > (something like what the disk images driver does) … but the moment you > did this, your data would exist in the filesystem and would be accessible > to any other process that tried to open and read the same path. You can accomplish this without writing to the file system, but it involves foregoing NSTask. Fork, close stdin in the child process, open a pipe (so that the child gets the read end in fd 0), then exec the tool with "/dev/stdin" as the filename argument. I'm not sure it's any more secure than just writing to the filesystem, though. It depends on whether OS X lets a user view the memory of other processes running as that user. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On 2013/02/21, at 13:11, Jens Alfke wrote: > > On Feb 20, 2013, at 4:18 PM, dangerwillrobinsondan...@gmail.com wrote: > >> Is there a way to feed an NSTask argument data when the command line tool in >> the task expects a file path argument? >> I would like to not actually create a file to use as the argument, but >> rather send data that would be in said file. >> Can this be done via NSFileHandle or NSPipe from NSData? > > This isn’t really feasible, for reasons that have nothing to do with NSTask. > The tool’s argument list is just an array of strings. The tool is going to > interpret one of those strings as a filesystem path and do something that > will end up asking the filesystem to open the file at that path (e.g. the > open() system call.) The system call has no idea where that path string came > from. > > You could conceivably create a fake volume in the filesystem that didn’t > correspond to any real file but just returned your data when read (something > like what the disk images driver does) … but the moment you did this, your > data would exist in the filesystem and would be accessible to any other > process that tried to open and read the same path. > > ―Jens Thanks Jens. As usual, always well thought insights. Makes perfect sense. Basically it will have to be a temp file that is overwritten and then unlinked. Small window of risk but unavoidable for now. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On Feb 20, 2013, at 8:05 PM, "Gerriet M. Denkmann" wrote: > I find that very easy to proof: Looks like you’re right — it’s the string @“$null” that’s to blame, for some reason. I would guess that somewhere in the archiver is some fscked-up unquoting code. I hope you’ve filed a bug report with Apple? I don’t have any really good suggestions, except not to use anything based on NSCoding. :-p There are plenty of non-opaque non-proprietary data formats you can use to serialize structured data; I recommend JSON. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Wed, Feb 20, 2013, at 08:22 PM, Kyle Sluder wrote: > You can accomplish this without writing to the file system, but it > involves foregoing NSTask. Fork, close stdin in the child process, open > a pipe (so that the child gets the read end in fd 0), then exec the tool > with "/dev/stdin" as the filename argument. Actually, the appropriate order of operations here is pipe, fork, close(stdin), dup(filedes[0]), exec. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 8:22 PM, Kyle Sluder wrote: > You can accomplish this without writing to the file system, but it > involves foregoing NSTask. Fork, close stdin in the child process, open > a pipe (so that the child gets the read end in fd 0), then exec the tool > with "/dev/stdin" as the filename argument. D’ohh! I’d forgotten about /dev/stdin. But why does this require abandoning NSTask? Its API supports redirecting input/output. Just call -[NSTask setStandardInput:]. —JEns ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 8:30 PM, Jens Alfke wrote: > > On Feb 20, 2013, at 8:22 PM, Kyle Sluder wrote: > >> You can accomplish this without writing to the file system, but it >> involves foregoing NSTask. Fork, close stdin in the child process, open >> a pipe (so that the child gets the read end in fd 0), then exec the tool >> with "/dev/stdin" as the filename argument. > > D’ohh! I’d forgotten about /dev/stdin. But why does this require abandoning > NSTask? Its API supports redirecting input/output. Just call -[NSTask > setStandardInput:]. Because you can't use CF (and by extension, Foundation) after calling fork. --Kyle Sluder ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
Oh crap, NOW I get it. :P You don't have to do the fork dance at all. Just call -setStandardInput: and pass /dev/stdin as the filename argument. Let NSTask take care of the rest. --Kyle Sluder On Wed, Feb 20, 2013, at 08:30 PM, Jens Alfke wrote: > > On Feb 20, 2013, at 8:22 PM, Kyle Sluder wrote: > > > You can accomplish this without writing to the file system, but it > > involves foregoing NSTask. Fork, close stdin in the child process, open > > a pipe (so that the child gets the read end in fd 0), then exec the tool > > with "/dev/stdin" as the filename argument. > > D’ohh! I’d forgotten about /dev/stdin. But why does this require > abandoning NSTask? Its API supports redirecting input/output. Just call > -[NSTask setStandardInput:]. > > —JEns ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 10:28 PM, Kyle Sluder wrote: > On Wed, Feb 20, 2013, at 08:22 PM, Kyle Sluder wrote: >> You can accomplish this without writing to the file system, but it >> involves foregoing NSTask. Fork, close stdin in the child process, open >> a pipe (so that the child gets the read end in fd 0), then exec the tool >> with "/dev/stdin" as the filename argument. > > Actually, the appropriate order of operations here is pipe, fork, > close(stdin), dup(filedes[0]), exec. It's not clear to me why that technique wouldn't work with NSTask and NSPipe. The read end of the NSTask's standardInput pipe is dup'd to stdin and you can easily enough pass "/dev/stdin" in the argument list. You would only need to do manual syscalls if you wanted to use a different file descriptor and "/dev/fd/". Finally, you should generally prefer dup2() over close() plus dup(). Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 21 Feb 2013, at 11:27, Jens Alfke wrote: > > On Feb 20, 2013, at 8:05 PM, "Gerriet M. Denkmann" > wrote: > >> I find that very easy to proof: > > Looks like you’re right — it’s the string @“$null” that’s to blame, for some > reason. I would guess that somewhere in the archiver is some fscked-up > unquoting code. They are using $null to stand for nil. Which does not play nice with NSArrays (and other containers), which cannot contain nil. > I hope you’ve filed a bug report with Apple? Have done long ago. Came back as duplicate (not surprising) with a very low number too. Meaning that this bug is known to Apple since ages, but they decided not to bother. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTask arguments
On Feb 20, 2013, at 10:31 PM, Kyle Sluder wrote: > On Feb 20, 2013, at 8:30 PM, Jens Alfke wrote: > >> On Feb 20, 2013, at 8:22 PM, Kyle Sluder wrote: >> >>> You can accomplish this without writing to the file system, but it >>> involves foregoing NSTask. Fork, close stdin in the child process, open >>> a pipe (so that the child gets the read end in fd 0), then exec the tool >>> with "/dev/stdin" as the filename argument. >> >> D’ohh! I’d forgotten about /dev/stdin. But why does this require abandoning >> NSTask? Its API supports redirecting input/output. Just call -[NSTask >> setStandardInput:]. > > Because you can't use CF (and by extension, Foundation) after calling fork. But with NSTask and NSPipe a) it's all taken care of for you, you don't need to do anything yourself after the fork; and b) it using pipe() and either fork()+exec() or posix_spawn() behind the scenes anyway. There's no use of high-level frameworks required in the subprocess. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 21 Feb 2013, at 11:15, Jens Alfke wrote: > > On Feb 20, 2013, at 12:10 AM, Gerriet M. Denkmann > wrote: > >> But I do not know how to recognise mutability. >> >> 1. use isKindOfClass: [NSMutableString class] >> disadvantage: all strings turn out to be mutable > > This is somewhat of an FAQ. There is no way to do this (without groping > inside private data structures.) Well, turns out there is a way. As Ronald Oussoren kindly pointed out yesterday: BOOL isMutable = [ someString classForKeyedArchiver ] == [ NSMutableString class ]; does exactly what I needed. > I think you’ve posted about this stuff before? Probably. But never got this really clever answer of classForKeyedArchiver. > It really sounds like you’re on a wild goose chase down a rathole, with this > archiving project. Well, it is not going too badly. My Archiver has keyed archiving and produces output comparable to NSArchiver (much smaller than NSKeyedArchiver) and can be used on iOS (unlike NSArchiver). It is not yet optimised (polite way to say: it is quite slow). > I suggest you back up a ways and look at the problem from a high level and > find a different way to solve it. I will have a look at JSON. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On Feb 20, 2013, at 8:39 PM, Gerriet M. Denkmann wrote: > They are using $null to stand for nil. Which does not play nice with NSArrays > (and other containers), which cannot contain nil. Plus, the object @“$null” is not the same as a nil pointer, so this is bad whether or not a container can contain nil. This makes NSArchiver a bad idea for _any_ data structure that can contain user (or worse, remote) input, since things will presumably start to break if the user enters “$null” into the right fields. (This makes me want to start entering that into various text fields in apps to see what will happen…) :-p I’m serious. These types of unquoting bugs are absolutely rampant in PHP libraries, and are one source of the constant security exploits that show up in WordPress and other PHP apps. I didn’t think Apple would leave this type of bug open for long — there’s probably a way to use it to pwn some Mac or iOS software, if a creative enough hacker gets ahold of it. —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 21 Feb 2013, at 12:09, Jens Alfke wrote: > > On Feb 20, 2013, at 8:39 PM, Gerriet M. Denkmann wrote: > >> They are using $null to stand for nil. Which does not play nice with >> NSArrays (and other containers), which cannot contain nil. > > Plus, the object @“$null” is not the same as a nil pointer, so this is bad > whether or not a container can contain nil. > > This makes NSArchiver no: NSArchiver is ok (though kind of frowned upon) NSKeyedArchiver is the silly one. > a bad idea for _any_ data structure that can contain user (or worse, remote) > input, since things will presumably start to break if the user enters “$null” > into the right fields. (This makes me want to start entering that into > various text fields in apps to see what will happen…) :-p Just make a nib (or xib) file with some label or button title of $null and see what happens. > > — there’s probably a way to use it to pwn some Mac or iOS software, if a > creative enough hacker gets ahold of it. I am not so sure. I have only noticed that NSKeyedUnarchiver turns arrays with $null into empty arrays. (And dictionaries, which have their keys and values stored as two arrays turn out to have a mismatch between number of keys and values). But another bug looks rather promising: feed strings with illegal Unicode to NSArchiver and see what happens. Did this (by accident) the other day. NSArchiver did not return, there was no exception, the app did not crash. Not sure what was going on. Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On Feb 20, 2013, at 9:31 PM, Gerriet M. Denkmann wrote: > But another bug looks rather promising: feed strings with illegal Unicode to > NSArchiver and see what happens. It’s harder to get such a string into an app, though, since you can’t really type it. > Did this (by accident) the other day. NSArchiver did not return, there was no > exception, the app did not crash. Not sure what was going on. Sounds like something called abort() — that’ll make the process exit abruptly. You can try setting a breakpoint on it. Or on exit(). —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to recognize mutability?
On 21 Feb 2013, at 12:58, Jens Alfke wrote: > > On Feb 20, 2013, at 9:31 PM, Gerriet M. Denkmann wrote: > >> But another bug looks rather promising: feed strings with illegal Unicode to >> NSArchiver and see what happens. > > It’s harder to get such a string into an app, though, since you can’t really > type it. > >> Did this (by accident) the other day. NSArchiver did not return, there was >> no exception, the app did not crash. Not sure what was going on. > > Sounds like something called abort() — that’ll make the process exit > abruptly. You can try setting a breakpoint on it. Or on exit(). Looks like there is an exception, though nothing gets logged in the Xcode console: frame #0: 0x7fff88d483c5 libobjc.A.dylib`objc_exception_throw frame #1: 0x7fff8ade6e7c CoreFoundation`+[NSException raise:format:] + 204 frame #2: 0x7fff880662e7 Foundation`-[NSString encodeWithCoder:] + 263 frame #3: 0x7fff880592d0 Foundation`_encodeObject_old + 152 frame #4: 0x7fff880591b1 Foundation`-[NSArchiver encodeRootObject:] + 179 frame #5: 0x7fff88058e76 Foundation`+[NSArchiver archivedDataWithRootObject:] + 145 Kind regards, Gerriet. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
