"NUL" device is missing

KM wrote:

> Chuck,
>
> The "Session Manager (Windows subsystem)" is the component responsible for
> registring NUL device (and other DOS devices). You have likely got it in
> your image already.
> You will also need "Null Device Driver" (the component visilibity is 200 so
> make sure you've got proper settings for TD min.visibility level).
>
> KM

Thanks, that appears to have done the trick. It was the visibility level
that through me off.


I suppose I could eliminate my need for the NUL device if I could find a
different way to achieve what I'm doing with the printf() functions.
Basically, I'm using fopen() to open up a channel to the NULL device and
then I'm using fprintf() to write a formatted string out to it. This
results in fprintf() returning the # of bytes written. I then allocate that
amount of memory plus one additional byte [NULL terminator] and use it as
the buffer for a sprintf() call. If I could get the # of bytes to be
written out by the *printf() function w/o using the NULL device I'd be a
happy camper.


TIA,

Chuck
--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

Do not send me unsolicited commercial email.

Chuck,

> I suppose I could eliminate my need for the NUL device if I could find a
> different way to achieve what I'm doing with the printf() functions.
> Basically, I'm using fopen() to open up a channel to the NULL device and
> then I'm using fprintf() to write a formatted string out to it. This
> results in fprintf() returning the # of bytes written. I then allocate that
> amount of memory plus one additional byte [NULL terminator] and use it as
> the buffer for a sprintf() call. If I could get the # of bytes to be
> written out by the *printf() function w/o using the NULL device I'd be a happy camper.

If you want to stick with CRT (specifically to xxxprintf), you basically need a version of the sprintf that does not require you to
allocate a big output buffer. I'd say it is an old know CRT issue.

If you don't need floating point conversions, you can use Win32 APIs like FormatMessage that will allocate the buffer for you.

Or you can implement your own safe version of sprintf (not using NUL even though I think it is not a bad way to do so). For example,
you can switch to _snprintf and iterate the process of allocating/reallocating the buffer on necessary size.

Here is an example for you: http://www.flipcode.com/cgi-bin/msg....rum=cotd&id=-1

KM

KM wrote:

> If you want to stick with CRT (specifically to xxxprintf), you basically need a version of the sprintf that does not require you to
> allocate a big output buffer. I'd say it is an old know CRT issue.
>
> If you don't need floating point conversions, you can use Win32 APIs like FormatMessage that will allocate the buffer for you.
>
> Or you can implement your own safe version of sprintf (not using NUL even though I think it is not a bad way to do so). For example,
> you can switch to _snprintf and iterate the process of allocating/reallocating the buffer on necessary size.
>
> Here is an example for you: http://www.flipcode.com/cgi-bin/msg....rum=cotd&id=-1

Yes, I'd prefer to stay with standard CRT functions to keep this solution as
portable as possible. I need full support for all of the format specifiers
used in the *printf() functions, so the Win32 API functions won't work for me.

I'll probably stick with using the NUL device right now. I may end up
taking the time later to implement my own format parser that calculates the
required # of bytes of storage required to hold the formatted string, but I
don't have time to do it right now.


--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc. 864 801 2795 voice & voicemail
103 Autumn Hill Road 864 801 2774 fax
Greer, SC 29651

Do not send me unsolicited commercial email.

Chuck,

> I'll probably stick with using the NUL device right now. I may end up
> taking the time later to implement my own format parser that calculates

the

> required # of bytes of storage required to hold the formatted string, but

I

> don't have time to do it right now.

What VC version you are building against?
The reason I am asking is that the issue has been fixed in C standard of 99
year. Only VC 2003 has peaked up the fix.
The fix was to pass NULL to _snprintf to count the number of characters
required for a specified formating string. Basically, you can make a call
like: _snprintf(NULL,0,"%...",...) and it will return you the number.

You can easy track this down exploring CRT source of VC. In VC 6.0
(sprintf.h, output.c, stdio.h) you may see that the string formating routine
subcalls do not check for NULL. In VC 2003 CRT, they do (output.c, write_xxx
functions called from _output). This may be a cure for you. Also, there is
another useful wrapper (don't know if it is ANSI compatible) -
_scprintf(char* format,...) - this will return the same number of characters
you need.

Hope this helps,
KM