MinGW - Minimalist GNU for Windows

Hey,

>   if ((tmpbuf = tmpfile()) == NULL)
>     return -1;

<snip>

>   fclose (tmpbuf);

I've not used tmpfile() before, but do you need to delete it after 
closing it?  I ask because I don't want to fill up the users machines 
with temp files.

Chris

-- 
ironhead@...
http://emergedesktop.org

<quote who="Chris Sutcliffe">
> Hey,
>
>>   if ((tmpbuf = tmpfile()) == NULL)
>>     return -1;
>
> <snip>
>
>>   fclose (tmpbuf);
>
> I've not used tmpfile() before, but do you need to delete it after
> closing it?  I ask because I don't want to fill up the users machines
> with temp files.
>

If the runtime is working correctly, then a file opened by tmpfile should
be deleted when closed.

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

<quote who="Danny Smith">
> What about this simple way of doing it.  Attached is a  vsnprintf using a
> tmpfile to allocate a "large enough"  tmp buffer and then copying the
> first n-1
> chars into the user's buffer and terminating with 0..
>

How many complaints about the function being slow will there be?  I don't
see any reason this wouldn't work.


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Earnie Boyd wrote:
> <quote who="Chris Sutcliffe">
>> Hey,
>>
>>>   if ((tmpbuf = tmpfile()) == NULL)
>>>     return -1;
>>
>> <snip>
>>
>>>   fclose (tmpbuf);
>>
>> I've not used tmpfile() before, but do you need to delete it after
>> closing it?  I ask because I don't want to fill up the users machines
>> with temp files.
>>
>
> If the runtime is working correctly, then a file opened by tmpfile should
> be deleted when closed.
>
That's correct, but there is a different problem with tmpfile.  It puts the file
in drive root directory, with obvious problems if that happens to be read-only.

Attached uses brute force approach to get a large enough buffer. It is also much
faster than the use of a tmpfile.  The tuning factors are just a first guess.

Danny

Danny
> Earnie

<quote who="Danny Smith">
> Earnie Boyd wrote:
>> <quote who="Chris Sutcliffe">
>>> Hey,
>>>
>>>>   if ((tmpbuf = tmpfile()) == NULL)
>>>>     return -1;
>>>
>>> <snip>
>>>
>>>>   fclose (tmpbuf);
>>>
>>> I've not used tmpfile() before, but do you need to delete it after
>>> closing it?  I ask because I don't want to fill up the users machines
>>> with temp files.
>>>
>>
>> If the runtime is working correctly, then a file opened by tmpfile
>> should
>> be deleted when closed.
>>
> That's correct, but there is a different problem with tmpfile.  It puts
> the file
> in drive root directory, with obvious problems if that happens to be
> read-only.
>

That's strange, according to MSDN it should open the tmpfile in the
current working directory.

> Attached uses brute force approach to get a large enough buffer. It is
> also much
> faster than the use of a tmpfile.  The tuning factors are just a first
> guess.
>

Looks good.


Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438

Earnie Boyd wrote:
> <quote who="Danny Smith">
>> That's correct, but there is a different problem with tmpfile.  It puts
>> the file
>> in drive root directory, with obvious problems if that happens to be
>> read-only.
>>
>
> That's strange, according to MSDN it should open the tmpfile in the
> current working directory.
>

This is why I made that statement:

#include <stdio.h>
#include <stdlib.h>
#include <windows.h>

int main (void)
{
   char pathbuf[_MAX_PATH];
   FILE* stream = tmpfile();
   char* path
     = _fullpath( pathbuf, stream->_tmpfname, _MAX_PATH);
   printf( "Temporary file %s was created\n", path);
   if (0xFFFFFFFF == GetFileAttributes(path))
     printf ("File does not exist\n");
   return 0;
}

When run from D:\develop\snippets

D:\develop\snippets>a
Temporary file D:\t5m was created

In any event, tmpfile() does create a real file and that causes problems with
read-only directories.

Danny

Apart from some small stylistic issues (two spaces used instead of one,
space after the left parenthesis), and references to both vsnprintf and
_vsnprintf), I did not find a major problem. However, I cannot say it is
an elegant solution. I wonder how many developers will choose to use it
if they know how it is implemented. I would prefer the Microsoft runtime.

Sorry for the lateness. I have been busy these days. And maybe I will be
late again for later discussions, since I am on vacation now, at last.

Kind regards,

Yongwei

Danny Smith wrote:

> Attached uses brute force approach to get a large enough buffer. It is also much
> faster than the use of a tmpfile.  The tuning factors are just a first guess.
> 
> Danny

How are things going on on this issue? I strongly recommend that we 
first make stuff like "%lld" and "%zu" work, and never rely on the 
Microsoft _vsnprintf internally.

Maybe a new option is needed to choose between the Microsoft and 
non-Microsoft xprintf runtime?

Best regards,

Yongwei

Wu Yongwei wrote:
> Apart from some small stylistic issues (two spaces used instead of one,
> space after the left parenthesis), and references to both vsnprintf and
> _vsnprintf), I did not find a major problem. However, I cannot say it is
> an elegant solution. I wonder how many developers will choose to use it
> if they know how it is implemented. I would prefer the Microsoft runtime.
> 
> Kind regards,
> 
> Yongwei
> 
> Danny Smith wrote:
> 
>> Attached uses brute force approach to get a large enough buffer. It is 
>> also much
>> faster than the use of a tmpfile.  The tuning factors are just a first 
>> guess.
>>
>> Danny

<quote who="Wu Yongwei">
> How are things going on on this issue? I strongly recommend that we
> first make stuff like "%lld" and "%zu" work, and never rely on the
> Microsoft _vsnprintf internally.
>
> Maybe a new option is needed to choose between the Microsoft and
> non-Microsoft xprintf runtime?
>

Or just support both formats.

Earnie

--
http://www.mingw.org
http://sourceforge.net/projects/mingw
https://sourceforge.net/donate/index.php?user_id=15438