Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

skiabox

macrumors regular
Original poster
Jul 27, 2010
184
109
Larisa, Greece
I am writing the following code to append fileA to fileB with no success.
Code:
//Append the file "fileA" to the end of "fileB"


#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>
#import <Foundation/NSFileHandle.h>
#import <Foundation/NSFileManager.h>
#import <Foundation/NSAutoreleasePool.h>
#import <Foundation/NSData.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	
	NSFileHandle *inFile, *outFile;
	NSData *buffer;
	
	//Open the file fileA for reading
	inFile = [NSFileHandle fileHandleForReadingAtPath:@"fileA"];
	
	if (inFile == nil)
	{
		NSLog(@"Open of fileA for reading failed!");
		return 1;
	}
	
	//Open the file fileB for updating
	outFile = [NSFileHandle fileHandleForWritingAtPath:@"fileB"];
	
	if (outFile = nil)
	{
		NSLog(@"Open of fileB for writing failed!");
		return 2;
	}
	
	//Seek to the end of outfile
	[outFile seekToEndOfFile];
	
	//Read inFile and write its contents to outFile
	buffer = [inFile readDataToEndOfFile];
	[outFile writeData:buffer];
	
	//Close the two files
	[inFile closeFile];
	[outFile closeFile];
	
	//Verify its contents
	NSLog(@"%@", [NSString stringWithContentsOfFile:@"fileB" encoding:NSUTF8StringEncoding error:NULL]);
	
	
	
    [pool drain];
    return 0;
}

Am I doing something wrong?
Thank you.
 
I am writing the following code to append fileA to fileB with no success.
Code:
//Append the file "fileA" to the end of "fileB"


#import <Foundation/NSObject.h>
#import <Foundation/NSString.h>
#import <Foundation/NSFileHandle.h>
#import <Foundation/NSFileManager.h>
#import <Foundation/NSAutoreleasePool.h>
#import <Foundation/NSData.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	
	NSFileHandle *inFile, *outFile;
	NSData *buffer;
	
	//Open the file fileA for reading
	inFile = [NSFileHandle fileHandleForReadingAtPath:@"fileA"];
	
	if (inFile == nil)
	{
		NSLog(@"Open of fileA for reading failed!");
		return 1;
	}
	
	//Open the file fileB for updating
	outFile = [NSFileHandle fileHandleForWritingAtPath:@"fileB"];
	
	if ([B][COLOR="Red"]outFile = nil[/COLOR][/B]) [B][COLOR="DarkOrange"]// assignment, outFile will always be nil[/COLOR][/B]
	{
		NSLog(@"Open of fileB for writing failed!");
		return 2; [COLOR="DarkOrange"] // execution ALWAYS ends here.[/COLOR]
	}
	
	//Seek to the end of outfile
	[outFile seekToEndOfFile];
	
	//Read inFile and write its contents to outFile
	buffer = [inFile readDataToEndOfFile];
	[outFile writeData:buffer];
	
	//Close the two files
	[inFile closeFile];
	[outFile closeFile];
	
	//Verify its contents
	NSLog(@"%@", [NSString stringWithContentsOfFile:@"fileB" encoding:NSUTF8StringEncoding error:NULL]);
	
	
	
    [pool drain];
    return 0;
}

Am I doing something wrong?
Thank you.

See above bold reds.
 
Last edited:
I haven't tried to compile it, but I see a problem here:

Code:
	if (outFile = nil)
	{
		NSLog(@"Open of fileB for writing failed!");
		return 2;
	}

You're assigning nil to outFile with = instead of == to compare equality, so it's like
Code:
if (NO)
	{
		NSLog(@"Open of fileB for writing failed!");
		return 2;
	}

So that NSLog will never execute and the program will carry on with outFile set to nil

As PatrickCocoa said, you should tell us exactly what happens when you try to run it.

Anyway, change it to == and it works.
 
Last edited:
See above bold reds.

You're a smidge off. It will NEVER fall into that if. An assignment statement evaluates to the right operand. In this case, nil. nil will be treated as false. That assignment is a/the problem, but execution will continue.

-Lee
 
There is a gcc option that will warn about constructs like this: -Wparentheses or -Wall.

Example:
Code:
gcc -Wparentheses -framework Foundation append.m
append.m: In function 'main':
append.m:22: warning: suggest parentheses around assignment used as truth value

gcc -Wall -framework Foundation append.m
append.m: In function 'main':
append.m:22: warning: suggest parentheses around assignment used as truth value

I suggest enabling -Wall at all times, and then heeding the warnings.
 
You're a smidge off. It will NEVER fall into that if. An assignment statement evaluates to the right operand. In this case, nil. nil will be treated as false. That assignment is a/the problem, but execution will continue.

-Lee

Interesting, I had it right the first time then. Initially I had more red marks down the page saying which calls wouldn't do anything because outFile was nil.

Then thought, "hey wouldn't it just return here?" and thus removed my other comments, and inserting the one about the return 2; line.
 
Interesting, I had it right the first time then. Initially I had more red marks down the page saying which calls wouldn't do anything because outFile was nil.

Then thought, "hey wouldn't it just return here?" and thus removed my other comments, and inserting the one about the return 2; line.

While we don't always think about it specifically, we definitely depend on assignment working this way. For example:
x = y = 7;
not that common, but depends on the evaluation of =. Also, sometimes in a while:
while ( myThing = nextThing() ) {
...
}
where nextThing will return null when you've looked at all the things. This is a fairly standard pattern. An explicit comparison to null would be nice, but it's frequently omitted.

The assignment-as-conditional is more nefarious than it seems, because if the right operand is a variable sometimes the condition will be true, others it won't depending on if it is 0.

-Lee
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.