chet@uwovax.uwo.ca (02/16/90)
Thanks for the help with my append mode query. With your help and some luck, I've figured out part of what happened, but there is still a little mystery involved which makes it worth this final posting. (1) first, the problem is just an MS-DOS problem; both the Sun and the VAX C compilers run B without problem (2) The EOF (^Z, dec 26) was introduced by an assembly language editor that I sometimes use. When I used only MicroEMACS, program B ran without problem on Turbo C and Small-C. Whenever I used the other editor, the ^Z crept in (I used a third, binary, editor to confirm these facts). (3) For Turbo C, a simple fix was to change the mode from "a" (which by default is "at") to "r+" and then use lseek(fp, -1, 2). This position the file pointer just before the EOF. Note, however, that it should not be necessary to do this! (4) Small-C (version 2.2 on MS-DOS) does not have an fseek() function, and I have so far been unsuccessful in my attempts to use the substitute function, bseek(), to achieve what I did in Turbo C with lseek(). (5) I don't know what the Turbo C compiler does, but Jim Hendrix describes the operation of fopen() very clearly in his book on Small C, and according to his description, the DOS EOF sign (^Z) should be changed to -1 on opening (presumably Turbo C does the same thing), and it should not be possible to append text after it. This is the bit of mystery that remains. Chet Creider creider@csd.uwo.ca
darcy@druid.uucp (D'Arcy J.M. Cain) (02/17/90)
In article <5003.25dabd8f@uwovax.uwo.ca> chet@uwovax.uwo.ca writes: > >(2) The EOF (^Z, dec 26) was introduced by an assembly language editor >that I sometimes use. When I used only MicroEMACS, program B ran >without problem on Turbo C and Small-C. Whenever I used the other >editor, the ^Z crept in (I used a third, binary, editor to confirm >these facts). > >(3) For Turbo C, a simple fix was to change the mode from "a" (which by >default is "at") to "r+" and then use lseek(fp, -1, 2). This position >the file pointer just before the EOF. Note, however, that it should not >be necessary to do this! > Why not? If you have an editor that thinks it is running on CP/M and must add a ^Z to the end of the file then why wouldn't an append happen after the last character in a file. Do you think there is something special about ^Z that DOS or fopen should recognize? After all ^Z doesn't even make any sense as an end of file. It is a SUB (substitute) character in ASCII. I would think the following would make at least as much sense as an end of file marker if one was needed: ^C ETX End of text ^D EOT End of transmission ^W ETB End of transmission block ^Y EM End of medium ^\ FS File separator So why not have append append from the ^D for instance. Nope. The proper thing for append to do is go to the end of the physical file and the programmer must back up if there are characters in the file that don't belong there. Maybe you should write a utility that searches for ^Z and resizes the file to the character before it. Then you have a standard file which append works properly on. -- D'Arcy J.M. Cain (darcy@druid) | Thank goodness we don't get all D'Arcy Cain Consulting | the government we pay for. West Hill, Ontario, Canada | (416) 281-6094 |