Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #65983 > unrolled thread

stdin and stdout

Back to article view | Back to comp.lang.c

Contents

  stdin and stdout Bartc <bc@freeuk.com> - 2015-07-20 14:37 +0100
    Re: stdin and stdout Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 14:58 +0100
      Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-20 15:31 +0100
        Re: stdin and stdout Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-20 16:29 +0100
          Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-20 17:03 +0100
        Re: stdin and stdout Ken Brody <kenbrody@spamcop.net> - 2015-07-20 12:09 -0400
        Re: stdin and stdout Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-07-21 10:02 +0200
    Re: stdin and stdout Keith Thompson <kst-u@mib.org> - 2015-07-20 11:19 -0700
      Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-20 19:38 +0100
        Re: stdin and stdout Keith Thompson <kst-u@mib.org> - 2015-07-20 12:56 -0700
          Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-20 23:06 +0100
            Re: stdin and stdout glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-20 23:18 +0000
              Re: stdin and stdout BGB <cr88192@hotmail.com> - 2015-07-21 14:12 -0500
            Re: stdin and stdout gordonb.9oj0u@burditt.org (Gordon Burditt) - 2015-07-21 19:14 -0500
              Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-22 11:11 +0100
                Re: stdin and stdout gordonb.3xos3@burditt.org (Gordon Burditt) - 2015-07-22 20:05 -0500
                  Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-23 09:27 +0100
            Re: stdin and stdout Richard Damon <Richard@Damon-Family.org> - 2015-07-21 21:44 -0400
              Re: stdin and stdout glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-07-22 04:10 +0000
        Re: stdin and stdout BGB <cr88192@hotmail.com> - 2015-07-21 12:55 -0500
          Re: stdin and stdout Bartc <bc@freeuk.com> - 2015-07-21 20:49 +0100
            Re: stdin and stdout BGB <cr88192@hotmail.com> - 2015-07-22 00:05 -0500
              Re: stdin and stdout "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 02:48 -0700
                Re: stdin and stdout "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-07-22 02:57 -0700
                  Re: stdin and stdout gordonb.bjmxp@burditt.org (Gordon Burditt) - 2015-07-22 20:27 -0500
                Re: stdin and stdout BGB <cr88192@hotmail.com> - 2015-07-22 13:19 -0500
                  Re: stdin and stdout Robert Wessel <robertwessel2@yahoo.com> - 2015-07-22 18:09 -0500

Page 2 of 2 — ← Prev page 1 [2]

#66122

On 21/07/2015 18:55, BGB wrote:
> On 7/20/2015 1:38 PM, Bartc wrote:

>> (And it will need to provide fixups for all the CRT functions I might
>> need, as I can't still access the independent MSVCRT, as it might have a
>> different iob[] array from the one used by the wrapped version[]!)
>>
>
> have you tried using "GetProcAddress()" to retrieve "__iob"?
>
> maybe also check for "__iob_func()", which should be a function for
> fetching a pointer to __iob (or "_iob" in C).

Actually yes, a brief check seemed to work on MSVCRT; this was a loading 
a function called "_iob" (although it's the address of an array).

But my concern doing that is that the "_iob" name might vary across 
different C systems; maybe some will use something completely different. 
(Also, I think that iob is an array of FILE types, but I don't know the 
size of a FILE object. Things get tricky when you venture outside the 
confines of the language!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#66142

On 7/21/2015 2:49 PM, Bartc wrote:
> On 21/07/2015 18:55, BGB wrote:
>> On 7/20/2015 1:38 PM, Bartc wrote:
>
>>> (And it will need to provide fixups for all the CRT functions I might
>>> need, as I can't still access the independent MSVCRT, as it might have a
>>> different iob[] array from the one used by the wrapped version[]!)
>>>
>>
>> have you tried using "GetProcAddress()" to retrieve "__iob"?
>>
>> maybe also check for "__iob_func()", which should be a function for
>> fetching a pointer to __iob (or "_iob" in C).
>
> Actually yes, a brief check seemed to work on MSVCRT; this was a loading
> a function called "_iob" (although it's the address of an array).
>
> But my concern doing that is that the "_iob" name might vary across
> different C systems; maybe some will use something completely different.
> (Also, I think that iob is an array of FILE types, but I don't know the
> size of a FILE object. Things get tricky when you venture outside the
> confines of the language!)
>

yeah. this is pretty much MSVCRT specific.

apart from wrapper functions, probably you aren't really going to find a 
whole lot of particularly portable options here.

[toc] | [prev] | [next] | [standalone]

#66146

Bart,

Would GetStdHandle() work?

    https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=VS.85).aspx

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66147

You could also create a child process which inherits
your handles. Three of the struct members in doing
that are those values, and then you'll know them.

FWIW, I always thought stdin, stdout, and stderr
were per process, assigned by the OS, and were
always handles 1, 2, and 3 in Windows, a throwback
to the DOS days. Have you examined their runtime
values? I could be wrong, but I can remember back
in the days of DOS using an INT 21H function, and
those values for the file handles to write out data.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#66228

> You could also create a child process which inherits
> your handles. Three of the struct members in doing
> that are those values, and then you'll know them.
> 
> FWIW, I always thought stdin, stdout, and stderr
> were per process, assigned by the OS, and were
> always handles 1, 2, and 3 in Windows, a throwback
> to the DOS days. 

Under UNIX, stdin, stdout, and stderr are taken from file descriptors
0, 1, and 2 passed to it, regardless of any use of stdin, stdout,
or stderr in the process calling one of the exec*() functions.

This is standardized in POSIX.  You can use STDIN_FILENO, STDOUT_FILENO,
and STDERR_FILENO defined in <unistd.h>, but the values are guaranteed
to be 0, 1, and 2 respectively.

According to an online reference DOS file handles 0, 1, 2, 3, and
4 are keyboard, screen, error output (usually screen), COM1, and
printer.  That's pretty close to 0, 1, and 2 being stdin, stdout,
and stderr.

> Have you examined their runtime
> values? I could be wrong, but I can remember back
> in the days of DOS using an INT 21H function, and
> those values for the file handles to write out data.

[toc] | [prev] | [next] | [standalone]

#66177

On 7/22/2015 4:48 AM, Rick C. Hodgin wrote:
> Bart,
>
> Would GetStdHandle() work?
>
>      https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=VS.85).aspx
>

for doing console IO? yes.
for getting FILE* pointers that work with the C library? no.


it is like using OpenFile(or CreateFile) / ReadFile(or ReadFileEx), or 
open/read, instead of fopen/fread.


though, granted, in my case I tend to prefer using wrappers and/or a VFS 
layer, which will typically mimic stdio, but generally uses OS-specific 
interfaces in the background, or if-needed falls back to stdio, via 
preprocessor magic.

if quick and dirty, the IO wrappers may simply forward to stdio.


this is still much more flexible than using stdio directly.
for example, it isn't hard to use a single VFS over the entire 
application, and allows plugging in VFS "drivers" which may provide 
specialized filesystem types (say, much of the filesystem contents can 
be "mounted" from ZIP files or similar), as well as being able to gloss 
over OS differences.


in my older (main) codebase, a VFS structure was used:
   foo/bar, may be a relative path, if a 'context' is used
     otherwise an 'absolute' virtual path.
   /foo/bar, absolute virtual path.
   //foo/bar, Linux special case, means OS absolute path.
   X:/foo/bar, used for "external" paths.
     A:/ .. Z:/, Win32 absolute path.
     also used for HTTP and FTP VFS drivers (as URLs).

there is also a VFS-level mechanism for aliasing, which is basically 
something between a mount and a symlink. there isn't currently a "good" 
mechanism for VFS level symlinks. there is currently a crude mechanism 
for symlinks (via special files holding the target path), but isn't 
really all that well-done or transparent (need to fix up handling of 
both symlinks and file permissions and async IO)


I could possibly do a redesigned VFS later, mostly doing some internal 
design cleanup and addressing some internal design flaws. dunno.

current VFS goes back to 2004, which had largely redesigned a VFS I had 
been using since the late 90s, which came about mostly because I had 
wanted to lazily abstract over stdio, so just took all the stdio calls 
and put a V on the front, so: "VFILE" and "vfread()", with some newer 
calls doing more like "VfWhatever()", could possibly go more over to 
this later convention, as well as providing a defined 'object' interface.

ex (possibly):
   VfRead(buf, s1, s2, fd);  //API function call
   can also be done as:
   (*fd)->VfRead(buf, s1, s2, fd); //object-style call
     (essentially already how the existing API does its API calls).

nevermind if a few other projects have apparently also used the name 
"VFILE" for their VFS's...


or such...

[toc] | [prev] | [next] | [standalone]

#66219

On Wed, 22 Jul 2015 13:19:14 -0500, BGB <cr88192@hotmail.com> wrote:

>On 7/22/2015 4:48 AM, Rick C. Hodgin wrote:
>> Bart,
>>
>> Would GetStdHandle() work?
>>
>>      https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=VS.85).aspx
>>
>
>for doing console IO? yes.
>for getting FILE* pointers that work with the C library? no.


You can convert a Windows file HANDLE to an fd number via
_open_osfhandle, and then convert the result of that to a FILE * with
_fdopen.  So you can get a FILE * from one of the OS standard handles
(which you can get via GetStdHandle)

That leaves the quiestion of whether or not its a good idea to to mix
I/O to same physical device with the FILE * from the above and the
FILE * that the C library created.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web