FILE structure - porting C DLL into other languages

J

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
 
V

Vladimir S. Oka

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
 
X

Xavier

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
 
K

Keith Thompson

Vladimir S. Oka said:
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.
 
A

Al Balmer

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.
 
F

Flash Gordon

Keith said:
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).
 
S

santosh

Keith said:
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?
 
S

santosh

Keith said:
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?
 
J

Jordan Abel

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.
 
S

santosh

Jordan said:
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.
 
J

John Bode

santosh said:
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 */
}
 
S

santosh

John said:
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.
 
S

Stephen Sprunk

John Bode said:
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 ***
 
R

Richard Bos

Stephen Sprunk said:
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
 
F

Flash Gordon

Stephen said:
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.
 
R

Richard Tobin

John Bode said:
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
 
C

CBFalconer

santosh said:
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/>
 
M

Micah Cowan

Flash Gordon said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,734
Messages
2,569,441
Members
44,832
Latest member
GlennSmall

Latest Threads

Top