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 1 of 2  [1] 2  Next page →

#65983 — stdin and stdout

Are there any ways to get these two values, other than making use of the 
built-in variables (or macros or whatever they are) 'stdin' and 'stdout'?

I want, for example, to use the C file functions in a dynamic library 
such as MSVCRT.DLL. That library might not be the same one linked in to 
the executable, so the stdin/out values available within the executable 
might not be compatible.

Looking at a few implementations, stdin/stdout are defined as elements 
of a FILE array called "iob" but the exact name seems to be vary.

I thought there might be a function that returned the values or a 
pointer to them.

-- 
Bartc

[toc] | [next] | [standalone]

#65986

On 20/07/15 14:37, Bartc wrote:
> Are there any ways to get these two values, other than making use of the
> built-in variables (or macros or whatever they are) 'stdin' and 'stdout'?

Not in standard C, no.

> I want, for example, to use the C file functions in a dynamic library
> such as MSVCRT.DLL. That library might not be the same one linked in to
> the executable, so the stdin/out values available within the executable
> might not be compatible.

If it's the same executable program, why wouldn't stdin and stdout be 
the same? If it isn't, the canonical way to connect with stdin and 
stdout from another process is via pipes (try asking in 
comp.os.ms-windows.programmer.win32).

> Looking at a few implementations, stdin/stdout are defined as elements
> of a FILE array called "iob" but the exact name seems to be vary.
>
> I thought there might be a function that returned the values or a
> pointer to them.

There is no ISO C function that does this.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#65993

On 20/07/2015 14:58, Richard Heathfield wrote:
> On 20/07/15 14:37, Bartc wrote:

 >> I want, for example, to use the C file functions in a dynamic library
 >> such as MSVCRT.DLL. That library might not be the same one linked in to
 >> the executable, so the stdin/out values available within the executable
 >> might not be compatible.
 >
 > If it's the same executable program, why wouldn't stdin and stdout be
 > the same?

(It'll be different libraries. It's definitely a problem when taking a 
pointer from a malloc() call of a statically linked library, and passing 
it to free() of a separate library. The two will maintain their own sets 
of data.)

>> I thought there might be a function that returned the values or a
>> pointer to them [stdin and stdout]
>
> There is no ISO C function that does this.

I think I can get around this most of the time, because usually file 
handles are returned by functions such as fopen(). And I can print to 
stdout by calling printf instead of fprintf. Sometimes stdin and stdout 
will be needed however.

But I now recall that opening a file called "con" under Windows will 
return a file handle that writes to the console. Trying it, this does 
seem to work:

  f = fopen("con", "rb");      // similar to stdin
  f = fopen("con", "wb");      // similar to stdout

Although they are distinct from stdin and stdout. (I don't know what 
happens when someone wants to create a file actually called "con".)

Now I all I need is a similar magic path in Linux and I'm all set..


-- 
Bartc

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

#66002

Bartc <bc@freeuk.com> writes:
<snip>
> But I now recall that opening a file called "con" under Windows will
> return a file handle that writes to the console. Trying it, this does
> seem to work:
>
>  f = fopen("con", "rb");      // similar to stdin
>  f = fopen("con", "wb");      // similar to stdout
>
> Although they are distinct from stdin and stdout. (I don't know what
> happens when someone wants to create a file actually called "con".)
>
> Now I all I need is a similar magic path in Linux and I'm all set..

  fopen("/dev/stdin", "rb");

It's not the same as "con" because it seems to be what you actually
want, but there are are Linux devices similar to Window's "con" if you
prefer.

-- 
Ben.

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

#66008

On 20/07/2015 16:29, Ben Bacarisse wrote:
> Bartc <bc@freeuk.com> writes:
> <snip>
>> But I now recall that opening a file called "con" under Windows will
>> return a file handle that writes to the console. Trying it, this does
>> seem to work:
>>
>>   f = fopen("con", "rb");      // similar to stdin
>>   f = fopen("con", "wb");      // similar to stdout
>>
>> Although they are distinct from stdin and stdout. (I don't know what
>> happens when someone wants to create a file actually called "con".)
>>
>> Now I all I need is a similar magic path in Linux and I'm all set..
>
>    fopen("/dev/stdin", "rb");
>
> It's not the same as "con" because it seems to be what you actually
> want, but there are are Linux devices similar to Window's "con" if you
> prefer.

OK, thanks.

-- 
Bartc

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

#66010

On 7/20/2015 10:31 AM, Bartc wrote:
> On 20/07/2015 14:58, Richard Heathfield wrote:
>> On 20/07/15 14:37, Bartc wrote:
>
>  >> I want, for example, to use the C file functions in a dynamic library
>  >> such as MSVCRT.DLL. That library might not be the same one linked in to
>  >> the executable, so the stdin/out values available within the executable
>  >> might not be compatible.
>  >
>  > If it's the same executable program, why wouldn't stdin and stdout be
>  > the same?
[...]
> But I now recall that opening a file called "con" under Windows will return
> a file handle that writes to the console. Trying it, this does seem to work:
>
>   f = fopen("con", "rb");      // similar to stdin
>   f = fopen("con", "wb");      // similar to stdout
>
> Although they are distinct from stdin and stdout. (I don't know what happens
> when someone wants to create a file actually called "con".)
[...]

If stdio has been redirected, the above will still get you the "console" on 
Windows.  (Just as "/dev/tty" IIRC will do on Linux.)

Note that, on Windows, you can't have a file named "con".  (Or even 
"con.something".)

Try this:

     echo hello >c:\con.txt
or
     echo hello >%windir%\con.dat

Neither will create the specified file, but will instead echo "hello" back 
to the console.

Or try:

     mkdir con
     mkdir lpt1.dir

and so on.

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

#66087

On 2015-07-20 16:31, Bartc wrote:

> Now I all I need is a similar magic path in Linux and I'm all set..

I'd say the problem won't arise in linux,
unless the shared object and the main executable
were built with different versions (major version!) of glibc,
but in that case it wouldn't work anyways.

C++ is another question; for example it is quite possible,
that objects compiled with "-D_THREAD_SAFE" won't be binary
compatible with objects compiled without that flag
(using the same compiler).

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

#66037

Bartc <bc@freeuk.com> writes:
> Are there any ways to get these two values, other than making use of the 
> built-in variables (or macros or whatever they are) 'stdin' and 'stdout'?
>
> I want, for example, to use the C file functions in a dynamic library 
> such as MSVCRT.DLL. That library might not be the same one linked in to 
> the executable, so the stdin/out values available within the executable 
> might not be compatible.
>
> Looking at a few implementations, stdin/stdout are defined as elements 
> of a FILE array called "iob" but the exact name seems to be vary.
>
> I thought there might be a function that returned the values or a 
> pointer to them.

There's no standard function that does this -- nor is there anything
stopping you from writing such a function yourself.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#66041

On 20/07/2015 19:19, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:

>> I thought there might be a function that returned the values or a
>> pointer to them.
>
> There's no standard function that does this -- nor is there anything
> stopping you from writing such a function yourself.

How? (Other than solutions based on passing special files/paths to fopen.)

First, this is likely to need to operate outside of the C language. But 
even if there is a C element (which there will be for the time being), 
that C won't know anything about the dynamic library which is loaded at 
runtime; it will only have access to the stdin/out to do with the linked 
version of the CRT.

One way is to create a special DLL, in C, which is a giant wrapper 
around the MSVCRT or other library. Then that new DLL can include the 
functions needed. But that's a giant dependency which I'd rather not 
have: MSVCRT etc I know will exist, the new file I'll have to maintain 
and provide. And there might more than one library I could use.

(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[]!)

-- 
Bartc

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

#66051

Bartc <bc@freeuk.com> writes:
> On 20/07/2015 19:19, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> I thought there might be a function that returned the values or a
>>> pointer to them.
>>
>> There's no standard function that does this -- nor is there anything
>> stopping you from writing such a function yourself.
>
> How? (Other than solutions based on passing special files/paths to fopen.)

#include <stdio.h>

FILE *stdin_func(void)  { return stdin; }
FILE *stdout_func(void) { return stdout; }
FILE *stderr_func(void) { return stderr; }

I don't know enough about what you're doing to know whether that's a
solution.

[snip]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#66069

On 20/07/2015 20:56, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 20/07/2015 19:19, Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
>>
>>>> I thought there might be a function that returned the values or a
>>>> pointer to them.
>>>
>>> There's no standard function that does this -- nor is there anything
>>> stopping you from writing such a function yourself.
>>
>> How? (Other than solutions based on passing special files/paths to fopen.)
>
> #include <stdio.h>
>
> FILE *stdin_func(void)  { return stdin; }
> FILE *stdout_func(void) { return stdout; }
> FILE *stderr_func(void) { return stderr; }
>
> I don't know enough about what you're doing to know whether that's a
> solution.

The problem is that there might be two C runtime libraries (one linked 
normally, the other loaded independently at runtime). They could be 
different libraries, or possibly the same one, but it thinks there are 
two different instances of itself.

The stdin/stdout in your code will only correspond to one of those. If 
you call the fprintf of one library, with the stdout of the other, I 
don't know what will happen.

(Another issue is if that C library is accessed by a program that 
doesn't use C source code, then 'stdin' etc are not available. Actually, 
for this kind of reason, I try and ensure one module is pure C. Although 
this doesn't help with the above problem.

I will use the fopen("con") kind of solution or that.)

-- 
Bartc

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

#66079

Bartc <bc@freeuk.com> wrote:
> On 20/07/2015 20:56, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
(snip on stdin and stdout)

>>>> There's no standard function that does this -- nor is there anything
>>>> stopping you from writing such a function yourself.

>>> How? (Other than solutions based on passing special files/paths to fopen.)

>> #include <stdio.h>

>> FILE *stdin_func(void)  { return stdin; }
>> FILE *stdout_func(void) { return stdout; }
>> FILE *stderr_func(void) { return stderr; }

>> I don't know enough about what you're doing to know whether that's a
>> solution.
 
> The problem is that there might be two C runtime libraries (one linked 
> normally, the other loaded independently at runtime). They could be 
> different libraries, or possibly the same one, but it thinks there are 
> two different instances of itself.

I don't believe that the standard allows for that, but in any case
you need to get the appropriate one for each.

Some years ago, I did mixed C and Fortran programming. The two each
had their own output stream and buffering. In that case, it was
pretty obvious which was which, but the output might get mixed up.
 
> The stdin/stdout in your code will only correspond to one of those. If 
> you call the fprintf of one library, with the stdout of the other, I 
> don't know what will happen.

If you use the method that Keith suggests, and include the appropriate
stdio.h for each, then each should get the right value.

That is, you will need two stdin_func() functions, etc.

Uset the result from each in the appropriate context.
 
> (Another issue is if that C library is accessed by a program that 
> doesn't use C source code, then 'stdin' etc are not available. Actually, 
> for this kind of reason, I try and ensure one module is pure C. Although 
> this doesn't help with the above problem.

For this, Keith's method should still work. You might also need
wrappers for other functions, such as getc() and putc(), if they are
implemented as macros.
 
> I will use the fopen("con") kind of solution or that.)

-- glen
 

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

#66120

On 7/20/2015 6:18 PM, glen herrmannsfeldt wrote:
> Bartc <bc@freeuk.com> wrote:
>> On 20/07/2015 20:56, Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
> (snip on stdin and stdout)
>

<snip>

>
>> (Another issue is if that C library is accessed by a program that
>> doesn't use C source code, then 'stdin' etc are not available. Actually,
>> for this kind of reason, I try and ensure one module is pure C. Although
>> this doesn't help with the above problem.
>
> For this, Keith's method should still work. You might also need
> wrappers for other functions, such as getc() and putc(), if they are
> implemented as macros.
>

yes, agreed.

I often do IO interfaces by having basically a reasonably complete set 
of wrappers (usually most of the stdio functions, with a few additions 
such as whole-file load/store, often a basic readdir/fstat style 
interface, and basic memory management).

the main reason for providing some derived utility functions (vs keeping 
the interface strictly minimal), is that it may be considerably cheaper 
in some cases (for example, bulk load/store may be a lot cheaper with a 
compressed VFS than doing the same thing via a sequence like "fopen 
fseek ftell malloc fseek fread fclose").


a typical interface structure is set up sort of like:
there is a shared structure with a collection of function pointers;
the interface provider side of things provides a set of wrappers for 
each function (say, forwarding calls to stdlib), and a struct is made 
which contains pointers to these functions;
a pointer to this structure is retrieved and passed where appropriate;
the code which uses these functions may also have another set of wrapper 
functions which forward calls through the structure (*).

the pattern may seem a little convoluted, but this is a reasonably good 
way to provide interfaces between subsystems while avoiding the 
subsystems directly depending on each other.


*: typically it can be done something like:
Foo_IoVtable *foo_if;
int foo_fread(void *buf, int s1, int s2, foo_file *fd)
   { return(foo_if->fRead(buf, s1, s2, fd)); }
or:
Foo_IoVtable **foo_if;
int foo_fread(void *buf, int s1, int s2, foo_file *fd)
   { return((*foo_if)->fRead(foo_if, buf, s1, s2, fd)); }


though, the latter pattern is less common for IO wrappers (which don't 
normally need explicit state, but can sometimes be useful with VFS's by 
allowing something to be run within a virtual root directory).

for many types of interfaces, this is a lot more convenient than a 
"FooGetProcAddress()" style system, but the latter may be a viable 
option for functions which go outside the original scope.


for some use-cases, it may also make sense to be able to provide for 
things like asynchronous/non-blocking IO operations:
int foo_freqread(void *buf, int s1, int s2, foo_file *fd,
     void (*func)(int status, void *cbdata), void *cbdata)
   { return((*foo_if)->fReqRead(foo_if, buf, s1, s2, fd,
     func, cbdata)); }

where the operation may be queued and handled asynchronously (control 
returns to the caller immediately), with a callback used to indicate 
when the operation has been completed.

this can be a lot more useful for dealing with slow IO, or where the 
caller may not be allowed to block waiting for IO.


for a HLL, the IO interface provided in the HLL may be created by 
forwarding through the structure (and made to look like stdio, or 
whatever else).

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

#66132

> The problem is that there might be two C runtime libraries (one linked 
> normally, the other loaded independently at runtime). They could be 
> different libraries, or possibly the same one, but it thinks there are 
> two different instances of itself.

If you discover that this is the problem, trash the linked executable
and figure out how to link it properly.

Hint:  Uninstall all but one C runtime library.

> The stdin/stdout in your code will only correspond to one of those. If 
> you call the fprintf of one library, with the stdout of the other, I 
> don't know what will happen.

It's a waste of time to find out, so delete the executable instead
of trying to run it.  Such a program doesn't always crash immediately;
sometimes it just throws in some uninitialized memmory garbage
instead.

> (Another issue is if that C library is accessed by a program that 
> doesn't use C source code, then 'stdin' etc are not available. Actually, 
> for this kind of reason, I try and ensure one module is pure C. Although 
> this doesn't help with the above problem.

You can access stdin or stdout by calling a function that does not
require an argument but accesses it implicitly, like getc(), printf(),
etc.  You can also write your own C wrapper function that calls the C
function that you really want to call and supplies stdin on its own
rather than making the non-C code pass it.

> I will use the fopen("con") kind of solution or that.)

That doesn't get you stdin or stdout.   If you want "the console", it
may be an acceptable way to get at it.

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

#66148

On 22/07/2015 01:14, Gordon Burditt wrote:

>> The stdin/stdout in your code will only correspond to one of those. If
>> you call the fprintf of one library, with the stdout of the other, I
>> don't know what will happen.
>
> It's a waste of time to find out, so delete the executable instead
> of trying to run it.  Such a program doesn't always crash immediately;
> sometimes it just throws in some uninitialized memmory garbage
> instead.

This comes up when trying to use a dynamic version of a C runtime 
library via a different language, or a different version of C.

It happens that sometimes, you want to be able to write this:

    fprintf(stdout,"Hello World\n")

and have it work. But notice there is no semicolon; this isn't C! The 
full (currently working) example is:

    import clib

    stdout:=fopen("con","wb")
    fprintf(stdout,"Hello World\n")

Should C libraries be allowed to be used this way or not? You obviously 
think they shouldn't.

(The alternatives are to piggy-back on top of the formally linked CRT 
library of the host (if this code is interpreted), or to forget the CRT 
and use the OS APIs directly, which are usually much more complicated 
and will vary by OS.)

> You can access stdin or stdout by calling a function that does not
> require an argument but accesses it implicitly, like getc(), printf(),
> etc.

By the same argument stdin and stdout aren't needed in any C program.

-- 
Bartc

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

#66227

>>> The stdin/stdout in your code will only correspond to one of those. If
>>> you call the fprintf of one library, with the stdout of the other, I
>>> don't know what will happen.

Call the fprintf wrapper in one library, which calls fprintf in the
real standard C library.

>> It's a waste of time to find out, so delete the executable instead
>> of trying to run it.  Such a program doesn't always crash immediately;
>> sometimes it just throws in some uninitialized memmory garbage
>> instead.
> 
> This comes up when trying to use a dynamic version of a C runtime 
> library via a different language, or a different version of C.

If you are writing another standard C library, you're doing something
wrong.  *CALL THE EXISTING ONE*.  Writing a wrapper library is fine.

> It happens that sometimes, you want to be able to write this:
> 
>    fprintf(stdout,"Hello World\n")

Whatever language that is, have it *NOT* duplicate the fprintf()
function, but have it call the fprintf() function in the one and
only C library, using a wrapper if needed, but DO NOT name the
wrapper fprintf() (at the external-symbol level - you can use any
names you want at the other-language-source-code-level.

C often uses a symbol-mangling method to translate C source code
function and variable names to executable symbol names.  A common
one for C is to add a leading _ to the function name.  One technique
I've seen used for FORTRAN is to add a *trailing* _ to the function
name.  You can have a fprintf in C and a fprintf in FORTRAN and
they refer to different symbols and different functions.  Oh, yes,
C++ name mangling gets much more complicated since it indicates
types and in the case of functions, argument types.  If your C
doesn't mangle symbol names, that doesn't prohibit you adding
__XYZZY________ to the end of every function in your other language
when you generate code.

If the language supports the equivalent of a C void * pointer, you
can initialize one to stdin and one to stdout, and use these pointers.
If the language does not support pointers, well, FORTRAN had logical
unit numbers, which could index into an array of FILE * in the I/O
wrapper function.


> and have it work. But notice there is no semicolon; this isn't C! The 
> full (currently working) example is:
> 
>    import clib
> 
>    stdout:=fopen("con","wb")
>    fprintf(stdout,"Hello World\n")
> 
> Should C libraries be allowed to be used this way or not? 

Use one and only one standard C library that contains the basic C functions
for a C hosted implementation.  Everything else should call that one,
directly or through a wrapper function to deal with different linkage
conventions if needed.

You should NOT create two definitions of the same linker symbol.
That way lies linker errors and/or madness.  Create wrapper functions,
dealing with differences in linkage, data representation, etc.  on
the way.  You may be able to teach your other language that certain
symbols don't need wrappers and to directly use the C version.  It
might be a practical necessity to create a wrapper function for
every function you wish to call in the C library.  But you only
have to do it once, and perhaps you can write code to generate most
of the wrapper functions for you.

> You obviously 
> think they shouldn't.

In this case I object to the misuse of terminology:  con and stdout
do not mean the same thing, and under fairly common conditions do
not point at the same place.

Do not create two stdout's.  Use the existing one, somehow.
If you need to pass in some magic token because your language doesn't
have pointers, fine, do it, and translate it in the wrapper function.
You should not have any code that needs to examine the internal guts
of a FILE struct that isn't a call to one of the C functions that
use them (fopen, fclose, fread, fwrite, fprintf, getc, putc, fflush,
etc.).

> (The alternatives are to piggy-back on top of the formally linked CRT 
> library of the host (if this code is interpreted), or to forget the CRT 
> and use the OS APIs directly, which are usually much more complicated 
> and will vary by OS.)

Sometimes the C API and the OS API overlap by 50%, especially on UNIX.

>> You can access stdin or stdout by calling a function that does not
>> require an argument but accesses it implicitly, like getc(), printf(),
>> etc.
> 
> By the same argument stdin and stdout aren't needed in any C program.

How do I fflush(stdout) without a reference to stdout?  You can get
some access but not all you might want.  Oh, yes, I should have
said to avoid the functions defined as macros.

Maybe, but you can't do that with stderr, and often it is very
convenient to use a FILE * variable which might equal stdout or
might equal the result from fopen()ing some log file, depending
on whether logging was requested.

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

#66233

On 23/07/2015 02:05, Gordon Burditt wrote:
>>>> The stdin/stdout in your code will only correspond to one of those. If
>>>> you call the fprintf of one library, with the stdout of the other, I
>>>> don't know what will happen.
>
> Call the fprintf wrapper in one library, which calls fprintf in the
> real standard C library.
>
>>> It's a waste of time to find out, so delete the executable instead
>>> of trying to run it.  Such a program doesn't always crash immediately;
>>> sometimes it just throws in some uninitialized memmory garbage
>>> instead.
>>
>> This comes up when trying to use a dynamic version of a C runtime
>> library via a different language, or a different version of C.
>
> If you are writing another standard C library, you're doing something
> wrong.  *CALL THE EXISTING ONE*.  Writing a wrapper library is fine.

This and the rest of your comments suggest you've either completely 
misunderstood the problem, or I've explained it very badly.

I'm not rewriting any C library (although that might be one solution!). 
I needed to obtain stdin/stdout by non-conventional means. Why, you'll 
have to re-read the thread.


-- 
Bartc

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

#66135

On 7/20/15 6:06 PM, Bartc wrote:

> The problem is that there might be two C runtime libraries (one linked
> normally, the other loaded independently at runtime). They could be
> different libraries, or possibly the same one, but it thinks there are
> two different instances of itself.
>

This is getting off topic, but a program that staticly links to the 
standard library and then uses a dynamic link library (at least on 
windows) is inherently broken. The basic rule is if you use any DLL, 
then you need to use the DLL version of the standard library (Which also 
means that any DLL needs to use the DLL version of the standard library).

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

#66141

Richard Damon <Richard@damon-family.org> wrote:
> On 7/20/15 6:06 PM, Bartc wrote:
 
>> The problem is that there might be two C runtime libraries (one linked
>> normally, the other loaded independently at runtime). They could be
>> different libraries, or possibly the same one, but it thinks there are
>> two different instances of itself.
 
> This is getting off topic, but a program that staticly links to the 
> standard library and then uses a dynamic link library (at least on 
> windows) is inherently broken. The basic rule is if you use any DLL, 
> then you need to use the DLL version of the standard library (Which also 
> means that any DLL needs to use the DLL version of the standard library).

I suppose, but it happens sometimes. Consider the case where you
have two different libraries that are distributed object only, and
compiled with different compilers? It might be that each expects
a specific libc, so you need two of them. 

I also once mixed Fortran and C, and each had its own library.
That was before it was usual for the Fortran library to use C I/O.
Both buffer, and I/O gets mixed together.

-- glen

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

#66118

On 7/20/2015 1:38 PM, Bartc wrote:
> On 20/07/2015 19:19, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>
>>> I thought there might be a function that returned the values or a
>>> pointer to them.
>>
>> There's no standard function that does this -- nor is there anything
>> stopping you from writing such a function yourself.
>
> How? (Other than solutions based on passing special files/paths to fopen.)
>
> First, this is likely to need to operate outside of the C language. But
> even if there is a C element (which there will be for the time being),
> that C won't know anything about the dynamic library which is loaded at
> runtime; it will only have access to the stdin/out to do with the linked
> version of the CRT.
>
> One way is to create a special DLL, in C, which is a giant wrapper
> around the MSVCRT or other library. Then that new DLL can include the
> functions needed. But that's a giant dependency which I'd rather not
> have: MSVCRT etc I know will exist, the new file I'll have to maintain
> and provide. And there might more than one library I could use.
>
> (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).

then you can presumably get handles from the DLL suitable for use with 
the DLL.


admittedly, I haven't fully investigated this (I have generally provided 
things like IO interfaces via forwarding wrappers).

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web