marfuas

Ett tips är att kolla det licensavtal som hänger med programmet, om det finns ett sånt. Jag skulle gissa att du inte får "dekompilera, modifiera eller skapa härledda verk från Produkten". Att hamna i juridiska tvister med amerikanska företag kan få häpnadsväckande tråkiga konsekvenser ...

Vill bara säga att jag är helt på Jogins sida när det gäller sakfrågan. För den som fortfarande tvivlar på att det går att skriva malware till OSX rekommenderas en titt på http://www.securemac.com/

Då skulle man kunna dela upp den här frågan i två delar: 1) Om det går att göra malware (det gör det) och 2) Varför det inte finns malware (för det finns det inte). Fråga 1) är väl utredd, och fråga 2) kan man bara spekulera om. Eller hur?

Men ni måste ju komma med ett bättre argument till varför det inte skulle gå att göra malware till Mac. Okej att det inte finns just nu, men varför skulle det inte gå att göra? Argumentet "det går inte, för att Mac är bättre än Windows" duger inte.

Om man då bortser från den här "Mac är min religion och OSX är hans profet"-attityden så skulle jag vilja veta om det finns något principiellt skäl till att det är omöjligt att skriva malware till Mac. Eftersom t.ex. OpenBSD använder sig av slumpmässig minnesallokering är det i princip omöjligt att skriva kod till det operativet som utnyttjar buffertspill (eller hur?), men finns det några principiella skäl till varför det inte skulle gå att exempelvis knåda ihop ett Applescript som sprider sig till alla kontakter i iMail?

Ska förstås vara probe[[test length]], men problemet uppstår ändå. Jag kan inte hitta något direkt mönster, det kan funka för tre-fyra strängar i rad och plötsligt paja för nästa sträng (särskilt om den är kortare). Får samma beteende även för "aaaaaa" följt av "a".

Kuriöst nog kan jag inte reproducera problemet om jag kompilerar programmet i Release-läge. Det kan inte vara så att jag har gjort nåt fel med allokeringar på ett helt annat ställe (glömt ett retain eller vad vet jag) som pajar en intern buffert nånstans inne i implementationen av NSString?

Jag skulle kunna tänka mig att strängen alltid termineras med en nollbyte, särskilt som man får en const char* tillbaka. Men för att kontrollera det skulle man behöva peta in ett UTF32-tecken som inte är noll i första byten (finns det ens såna?).

Ja, såvitt jag kan bedöma så är det verkligen så. Följande snutt ger lite då och då någonting annat i slutet av strängen än en nolla:

const wchar_t* probe;
	NSString* test;
	
	test = [textField stringValue];
	probe = (const wchar_t*)[test cStringUsingEncoding:NSUTF32StringEncoding];
	NSAssert(probe, @Null);
	if(probe[[test length] + 1] != 0){
			NSLog(@Not zero);
	}	

textField är en NSTextField i en simpel dialogruta. Man måste köra snutten först med en lång sträng och sedan en kortare i textrutan för att provocera fram felet.

Får samma beteende för NSUTF8StringEncoding och NSASCIIStringEncoding.

Som alltid är det mycket möjligt att jag har sluntit på tangenterna och/eller inte läst manualen ordentligt. Hojta gärna i så fall!

Men originalfrågan kvarstår: Vad tycker Apple att man ska använda?

Visst är det mysko? Om man kollar här http://trac.aarone.org/cicu/browser/trunk/source/NSStringICUAdditions.m?rev=17 (rad 81) verkar andra ockå ha haft liknande problem. Minns inte riktigt hur jag kom fram till att det var NSString som betedde sig konstigt, och inte jag. Kan försöka verifiera det ordentligt i morgon på jobbet.

Jo, jag var där och rotade innan jag postade här, men jag blev inte mycket klokare för det. I dagsläget får jag ut en unichar-sträng med getCharacters som jag sedan konverterar "för hand" till wchar_t. Det fungerar rent tekniskt men känns onödigt och oestetiskt. Hoppades att det fanns ett vettigare sätt.

Hej!

Sitter och försöker koppla ihop en komponent i c++ med Cocoa, och det funkar utmärkt utom när det gäller att konvertera strängar från och till NSString/wchar_t. Hur är det tänkt att man ska gå till väga? Körde först med cStringUsingEncoding, och det verkade fungerade alldeles utmärkt ända tills jag begrep att den sträng som spottas ut inte är nollterminerad, och det verkar ju inte finnas någon direkt enkelt sätt att kolla hur lång strängen är innan man har konverterat den. (Hur har dom tänkt när de returnerar en c-sträng som inte är nollterminerad?)

Efterom jag är totalt rudis när det gäller Mac-utveckling i allmänhet och Cocoa i synnerhet anar jag att det finns ett enkelt och elegant sätt att göra den här konverteringen på.