bjoern@drdhh.hanse.de (Bjoern Kriews) (03/25/91)
Hello Netland ! I've a question about tmpfile(). My 'Mark Williams lexical guide to ANSI C' states (referring to 4.9.4.3): "tmpfile creates a file to hold data temporarily. The file is opened in binary update mode (wb+) and is removed automatically when it is closed or the program ends." My question is: May a conforming program call tmpfile() more than once ? The MW Book doesn't say anything about it and my clib always creates the same file (brain-damaged at all). I would like to have a definitive statement before I go and complain to my vendor. Thanks, Bjoern --- bjoern@drdhh.hanse.de = Bjoern Kriews / Stormsweg 6 / 2000 Hamburg 76 / FRG
bhoughto@hopi.intel.com (Blair P. Houghton) (03/27/91)
In article <2537.03.91@drdhh.hanse.de> bjoern@drdhh.hanse.de writes: >My question is: >May a conforming program call tmpfile() more than once ? You can call it, but if you get NULL as the return value or end up clobbering the same file, the implementation still conforms... (Btw, mode "wb+" truncates the file to 0 length then allows fseek()/rewind() operations on it; the 'b' indicates that when opened the access pointer can be positioned past the end of the data due to null padding, but if the file is truncated to 0 length... ? ) >The MW Book doesn't say anything about it and my clib >always creates the same file (brain-damaged at all). This is conformant behavior, nonetheless. >I would like to have a definitive statement before >I go and complain to my vendor. Complain, anyway. They weren't prevented from having it open uniquely-named files, but there's nothing there that says it should. Better yet, tell them how to write it and they might just do it that way. --Blair "...for the next 'release'...in six months...for Eastern Borneo only..."
gwyn@smoke.brl.mil (Doug Gwyn) (03/28/91)
In article <2537.03.91@drdhh.hanse.de> bjoern@drdhh.hanse.de writes: >May a conforming program call tmpfile() more than once ? Sure. However, the implementation may choose to return a null pointer on any or all calls to tmpfile(); how well it supports tmpfile() is a matter of "quality of implementation". The usual UNIX implementation supports any number of open temporary files up to system limits on open file descriptors for the process, etc. (The file is unliked after being opened. Note that some non-UNIX file systems such as NFS may have problems with that.)
gwyn@smoke.brl.mil (Doug Gwyn) (03/28/91)
In article <15603@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >(The file is unliked after being opened. Note that some non-UNIX file >systems such as NFS may have problems with that.) Obviously I meant "unlinked", not "unliked". (Must have been influenced by thinking about NFS while typing that.)
cudcv@warwick.ac.uk (Rob McMahon) (03/30/91)
In article <15603@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes: >(The file is unli[n]ked after being opened. Note that some non-UNIX file >systems such as NFS may have problems with that.) NFS may have its problems, but this is not one. Unlinking from the client that opened the file is covered. Rob -- UUCP: ...!mcsun!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick INET: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England