FILE structure - porting C DLL into other languages

[jparus]

Hello,
can anybody explain me how to port FILE structure into other languages.
I have an DLL library and functions in this library take FILE* as a
parameter. I want to make an interface into Delphi, thus I must
"export" function names and parameters of the function. It is easy for
usual data types and structures but I don't know how to port FILE
structure.

Tahnks.

Jindra

[Xavier]

jp****@gmail.com wrote:

Hello,
can anybody explain me how to port FILE structure into other languages.
I have an DLL library and functions in this library take FILE* as a
parameter. I want to make an interface into Delphi, thus I must
"export" function names and parameters of the function. It is easy for
usual data types and structures but I don't know how to port FILE
structure.

Tahnks.

Jindra

look at stream in your IDE help system

Xavier

[Vladimir S. Oka]

On Thursday 16 March 2006 08:41, jp****@gmail.com opined (in
<11*********************@i40g2000cwc.googlegroups. com>):

Hello,
can anybody explain me how to port FILE structure into other
languages. I have an DLL library and functions in this library take
FILE* as a parameter. I want to make an interface into Delphi, thus I
must "export" function names and parameters of the function. It is
easy for usual data types and structures but I don't know how to port
FILE structure.

You should look into the C implementation used to create the library,
and see how exactly is FILE declared there. You'll then hopefully have
enough information to map the fields to whatever Delphi requires. You
will most likely need an interface layer for this.

--
BR, Vladimir

Recent research has tended to show that the Abominable No-Man
is being replaced by the Prohibitive Procrastinator.
-- C.N. Parkinson

[Keith Thompson]

"Vladimir S. Oka" <no****@btopenworld.com> writes:

On Thursday 16 March 2006 08:41, jp****@gmail.com opined (in
<11*********************@i40g2000cwc.googlegroups. com>):

can anybody explain me how to port FILE structure into other
languages. I have an DLL library and functions in this library take
FILE* as a parameter. I want to make an interface into Delphi, thus I
must "export" function names and parameters of the function. It is
easy for usual data types and structures but I don't know how to port
FILE structure.

You should look into the C implementation used to create the library,
and see how exactly is FILE declared there. You'll then hopefully have
enough information to map the fields to whatever Delphi requires. You
will most likely need an interface layer for this.

I don't know whether that's the best approach (partly because I know
very little about Delphi).

C programs in general don't use the FILE structure itself. They only
use pointers to FILE structures (type FILE*). Think of a FILE* as an
opaque type that happens to be implemented as a pointer. The only
valid values of type FILE* are NULL and values returned by functions
such as fopen(). The only valid things to do with FILE* values are to
compare them to NULL or to each other, or to pass them to functions.

The internals of the FILE structure itself are entirely
system-specific. Don't do anything that depends on those internals
unless you absolutely have to.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Al Balmer]

On 16 Mar 2006 00:41:50 -0800, jp****@gmail.com wrote:

Hello,
can anybody explain me how to port FILE structure into other languages.
I have an DLL library and functions in this library take FILE* as a
parameter. I want to make an interface into Delphi, thus I must
"export" function names and parameters of the function. It is easy for
usual data types and structures but I don't know how to port FILE
structure.

You really don't want to port the FILE structure. You want to look at
what the I/O is doing, then do the same thing in Delphi.

--
Al Balmer
Sun City, AZ

[Flash Gordon]

Keith Thompson wrote:

"Vladimir S. Oka" <no****@btopenworld.com> writes:

On Thursday 16 March 2006 08:41, jp****@gmail.com opined (in
<11*********************@i40g2000cwc.googlegroups. com>):

can anybody explain me how to port FILE structure into other
languages. I have an DLL library and functions in this library take
FILE* as a parameter. I want to make an interface into Delphi, thus I
must "export" function names and parameters of the function. It is
easy for usual data types and structures but I don't know how to port
FILE structure. You should look into the C implementation used to create the library,
and see how exactly is FILE declared there. You'll then hopefully have
enough information to map the fields to whatever Delphi requires. You
will most likely need an interface layer for this.

I don't know whether that's the best approach (partly because I know
very little about Delphi).

I do know Delphi and cannot think of a good reason for doing it.
C programs in general don't use the FILE structure itself. They only
use pointers to FILE structures (type FILE*). Think of a FILE* as an
opaque type that happens to be implemented as a pointer. The only
valid values of type FILE* are NULL and values returned by functions
such as fopen(). The only valid things to do with FILE* values are to
compare them to NULL or to each other, or to pass them to functions.

The internals of the FILE structure itself are entirely
system-specific. Don't do anything that depends on those internals
unless you absolutely have to.

I agree with you completely.

The OP should either use the IO built in to Delphi with is perfectly
adequate for most tasks of if he *really* needs to access C streams
write wrapper functions in an extended version of C (extensions being
required for calling conventions) to do what is required.

The details are off topic here. Probably one of the Boreland groups
would be a good place, since Boreland do a C (and C++) compiler as well
as Delphi (although you can use other C compilers for this).
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[santosh]

Keith Thompson wrote:

C programs in general don't use the FILE structure itself. They only
use pointers to FILE structures (type FILE*). Think of a FILE* as an
opaque type that happens to be implemented as a pointer. The only
valid values of type FILE* are NULL and values returned by functions
such as fopen(). The only valid things to do with FILE* values are to
compare them to NULL or to each other, or to pass them to functions.

Is it meaningful to compare two FILE * values with each other?

[Keith Thompson]

"santosh" <sa*********@gmail.com> writes:

Keith Thompson wrote:

C programs in general don't use the FILE structure itself. They only
use pointers to FILE structures (type FILE*). Think of a FILE* as an
opaque type that happens to be implemented as a pointer. The only
valid values of type FILE* are NULL and values returned by functions
such as fopen(). The only valid things to do with FILE* values are to
compare them to NULL or to each other, or to pass them to functions.

Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[santosh]

Keith Thompson wrote:

"santosh" <sa*********@gmail.com> writes:

Keith Thompson wrote:

C programs in general don't use the FILE structure itself. They only
use pointers to FILE structures (type FILE*). Think of a FILE* as an
opaque type that happens to be implemented as a pointer. The only
valid values of type FILE* are NULL and values returned by functions
such as fopen(). The only valid things to do with FILE* values are to
compare them to NULL or to each other, or to pass them to functions.

Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

[Jordan Abel]

On 2006-03-21, santosh <sa*********@gmail.com> wrote:

Keith Thompson wrote:

"santosh" <sa*********@gmail.com> writes:

> Keith Thompson wrote:
>> C programs in general don't use the FILE structure itself. They only
>> use pointers to FILE structures (type FILE*). Think of a FILE* as an
>> opaque type that happens to be implemented as a pointer. The only
>> valid values of type FILE* are NULL and values returned by functions
>> such as fopen(). The only valid things to do with FILE* values are to
>> compare them to NULL or to each other, or to pass them to functions.
>
> Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

If one part of your code isn't telling the other whether they're the
same FILE * or not.

[santosh]

Jordan Abel wrote:

On 2006-03-21, santosh <sa*********@gmail.com> wrote:

Keith Thompson wrote:

"santosh" <sa*********@gmail.com> writes:
> Keith Thompson wrote:
>> C programs in general don't use the FILE structure itself. They only
>> use pointers to FILE structures (type FILE*). Think of a FILE* as an
>> opaque type that happens to be implemented as a pointer. The only
>> valid values of type FILE* are NULL and values returned by functions
>> such as fopen(). The only valid things to do with FILE* values are to
>> compare them to NULL or to each other, or to pass them to functions.
>
> Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

If one part of your code isn't telling the other whether they're the
same FILE * or not.

Okay thanks, though that would probably not be a very good way to
differentiate between different streams.

[John Bode]

santosh wrote:

Keith Thompson wrote:

"santosh" <sa*********@gmail.com> writes:

Keith Thompson wrote:
> C programs in general don't use the FILE structure itself. They only
> use pointers to FILE structures (type FILE*). Think of a FILE* as an
> opaque type that happens to be implemented as a pointer. The only
> valid values of type FILE* are NULL and values returned by functions
> such as fopen(). The only valid things to do with FILE* values are to
> compare them to NULL or to each other, or to pass them to functions.

Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

You might want to do different processing if your input stream is stdin
vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

[santosh]

John Bode wrote:

santosh wrote:

Keith Thompson wrote:

"santosh" <sa*********@gmail.com> writes:
> Keith Thompson wrote:
>> C programs in general don't use the FILE structure itself. They only
>> use pointers to FILE structures (type FILE*). Think of a FILE* as an
>> opaque type that happens to be implemented as a pointer. The only
>> valid values of type FILE* are NULL and values returned by functions
>> such as fopen(). The only valid things to do with FILE* values are to
>> compare them to NULL or to each other, or to pass them to functions.
>
> Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

You might want to do different processing if your input stream is stdin
vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

Thanks for the example.

[Stephen Sprunk]

"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

santosh wrote:

Keith Thompson wrote:

> "santosh" <sa*********@gmail.com> writes:
> > Keith Thompson wrote:
> >> C programs in general don't use the FILE structure itself. They
> >> only
> >> use pointers to FILE structures (type FILE*). Think of a FILE* as
> >> an
> >> opaque type that happens to be implemented as a pointer. The only
> >> valid values of type FILE* are NULL and values returned by functions
> >> such as fopen(). The only valid things to do with FILE* values are
> >> to
> >> compare them to NULL or to each other, or to pass them to functions.
> >
> > Is it meaningful to compare two FILE * values with each other?
>
> As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?

You might want to do different processing if your input stream is stdin
vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

Does anything prohibit user code from opening a second stream that also
points to stdin? More generally, is there any rule that prohibits two
different FILE objects from referring to the same stream?

The POSIX I/O layer, which C streams are often layered on top of, allows two
file descriptors to refer to the same file. Simply testing fds for equality
can prove they do refer to the same file but can't prove they refer to
different files.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

*** Free account sponsored by SecureIX.com ***
*** Encrypt your Internet usage with a free VPN account from http://www.SecureIX.com ***

[Richard Bos]

"Stephen Sprunk" <st*****@sprunk.org> wrote:

"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

You might want to do different processing if your input stream is stdin
vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

Does anything prohibit user code from opening a second stream that also
points to stdin? More generally, is there any rule that prohibits two
different FILE objects from referring to the same stream?

No, and no, AFAICT.

Richard

[Richard Tobin]

In article <11**********************@u72g2000cwu.googlegroups .com>,
John Bode <jo*******@my-deja.com> wrote:

if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */

Though it might apply in some special circumstances, testing for stdin
is not generally a good way to test for interactivity. Most operating
systems have a more reliable way to test it.

An alternative example of comparing two streams might be a function
that takes a stream for input and output. If the two are the same it
might need to use a temporary file, or report an error.

Of course, C doesn't guarantee that two different FILEs don't in fact
refer to the same underlying operating system stream or file, so any
such comparisons are not completely reliable.

-- Richard

[Flash Gordon]

Stephen Sprunk wrote:

"John Bode" <jo*******@my-deja.com> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.com...

santosh wrote:

Keith Thompson wrote:
> "santosh" <sa*********@gmail.com> writes:
> > Keith Thompson wrote:
> >> C programs in general don't use the FILE structure itself. They
> >> only
> >> use pointers to FILE structures (type FILE*). Think of a FILE*
as > >> an
> >> opaque type that happens to be implemented as a pointer. The only
> >> valid values of type FILE* are NULL and values returned by
functions
> >> such as fopen(). The only valid things to do with FILE* values
are > >> to
> >> compare them to NULL or to each other, or to pass them to
functions.
> >
> > Is it meaningful to compare two FILE * values with each other?
>
> As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What I
meant was, in the context of user code, as opposed to the C library
implementation, does it make sense to compare two different FILE *
values? For example you open two files and get two FILE * values as a
result. What would be the meaning in comparing them, even though it may
be valid?
You might want to do different processing if your input stream is stdin
vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

Does anything prohibit user code from opening a second stream that also
points to stdin?

No, but it also does nothing to help you. I.e. you don't know what file
name to use to open a second stream on stdin or even if that is possible.
More generally, is there any rule that prohibits two
different FILE objects from referring to the same stream?
There is no such rule in standard C.
The POSIX I/O layer, which C streams are often layered on top of, allows
two file descriptors to refer to the same file. Simply testing fds for
equality can prove they do refer to the same file but can't prove they
refer to different files.

The same applies with C streams and the reason is probably the same.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Micah Cowan]

Flash Gordon <sp**@flash-gordon.me.uk> writes:

Stephen Sprunk wrote:

More generally, is there any rule that prohibits two
different FILE objects from referring to the same stream?

There is no such rule in standard C.

If there were, POSIX implementations would be in violation of standard
C, as it specifically allows this.

[CBFalconer]

santosh wrote:

John Bode wrote:

santosh wrote:

Keith Thompson wrote:
"santosh" <sa*********@gmail.com> writes:
.... snip ...>
> Is it meaningful to compare two FILE * values with each other?

As far as I know, yes. Why wouldn't it be?

Sorry if I don't make sense, but I'm still a beginner in C. What
I meant was, in the context of user code, as opposed to the C
library implementation, does it make sense to compare two
different FILE * values? For example you open two files and get
two FILE * values as a result. What would be the meaning in
comparing them, even though it may be valid?

You might want to do different processing if your input stream is
stdin vs. a file:

#include <stdio.h>

void getData(FILE *stream)
{
if (stream == stdin)
/* do special processing for interactive input */
else
/* do normal processing for batch input */
}

Thanks for the example.

Except it isn't enough. stdin may have been redirected from a disk
(or other) file. This is where a system specific routine is
handy. I use the following:

/* This is very likely to be non-portable */
/* DOES NOT check fp open for reading */
/* NULL fp is considered a keyboard here! */
static int akeyboard(FILE *fp)
{
#ifndef __TURBOC__ /* Turbo C is peculiar */
# ifdef __STDC__
/* This dirty operation allows gcc -ansi -pedantic */
extern int fileno(FILE *fp);
extern int isatty(int fn);
# endif
#endif
return ((fp != NULL) && isatty(fileno(fp)));
} /* akeyboard */

Its usual purpose is to trigger help when a utility is run without
input redirection.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>