Append is not working

Discussion in 'Mac Programming' started by skiabox, Dec 28, 2010.

  1. skiabox macrumors member

    Joined:
    Jul 27, 2010
    #1
    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.
     
  2. PatrickCocoa macrumors 6502a

    Joined:
    Dec 2, 2008
    #2
    So what happens

    So what happens when you run the above code?
     
  3. jared_kipe, Dec 28, 2010
    Last edited: Dec 28, 2010

    jared_kipe macrumors 68030

    jared_kipe

    Joined:
    Dec 8, 2003
    Location:
    Seattle
    #3
    See above bold reds.
     
  4. McGordon, Dec 28, 2010
    Last edited: Dec 28, 2010

    McGordon macrumors member

    Joined:
    Dec 28, 2010
    Location:
    Scotland
    #4
    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.
     
  5. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #5
    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
     
  6. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #6
    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.
     
  7. jared_kipe macrumors 68030

    jared_kipe

    Joined:
    Dec 8, 2003
    Location:
    Seattle
    #7
    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.
     
  8. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #8
    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
     
  9. skiabox thread starter macrumors member

    Joined:
    Jul 27, 2010

Share This Page