473,227 Members | 1,576 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,227 software developers and data experts.

FILE structure - porting C DLL into other languages

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

Mar 16 '06 #1
18 1839
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
Mar 16 '06 #2
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

Mar 16 '06 #3
"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.
Mar 16 '06 #4
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
Mar 16 '06 #5
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
Mar 21 '06 #6
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?

Mar 21 '06 #7
"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.
Mar 21 '06 #8
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?

Mar 21 '06 #9
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.
Mar 21 '06 #10
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.

Mar 21 '06 #11

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 */
}

Mar 21 '06 #12
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.

Mar 21 '06 #13
"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 ***
Mar 21 '06 #14
"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
Mar 21 '06 #15
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
Mar 21 '06 #16
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
Mar 21 '06 #17
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.
Mar 21 '06 #18
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/>
Mar 21 '06 #19

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: pembed2003 | last post by:
Hi all, Given something like: std::ofstream out_file("path"); how do I extract the file descriptor from out_file? Is it possible? What I want is to extract the file descriptor and then pass...
14
by: Xah Lee | last post by:
is there a way to condense the following loop into one line? # -*- coding: utf-8 -*- # python import re, os.path imgPaths= # change the image path to the full sized image, if it exists
4
by: Chris Travers | last post by:
Hi all; A few years ago, I set about porting a PHP application from MySQL to PostgreSQL, after realizing that MySQL wasn't going to be able to handle it. In order to do this, I built a light,...
3
by: Obrecht | last post by:
Hi. I am new to VB .NET and am just starting to do some testing with it. I am trying to define a fixed length array of structures within a structure. I pass this structure to a Win32 Btrieve...
9
by: JimmyKoolPantz | last post by:
IDE: Visual Studio 2005 Language: VB.NET Fox Pro Driver Version: 9.0.0.3504 Problem: I currently have a problem altering a DBF file. I do not get any syntax errors when running the program. ...
0
by: srikar | last post by:
Hi all, I am working on porting of code in C++, I am having the following problem. In my code The following structure has been defined static struct rwtable { /* reserved word table */...
34
by: subramanian100in | last post by:
Is there any difference between porting and migrating. Kindly explain
14
by: deepak | last post by:
Hi Experts, I'm getting this compilation error while trying to access a member in structure. at what time we will get this error message? Thanks, Deepak
19
by: Dotan Cohen | last post by:
I often see mention of SMBs that either want to upgrade their Windows installations, or move to Linux, but cannot because of inhouse VB apps. Are there any Python experts who I can reference them...
0
by: VivesProcSPL | last post by:
Obviously, one of the original purposes of SQL is to make data query processing easy. The language uses many English-like terms and syntax in an effort to make it easy to learn, particularly for...
3
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 3 Jan 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). For other local times, please check World Time Buddy In...
0
by: abbasky | last post by:
### Vandf component communication method one: data sharing ​ Vandf components can achieve data exchange through data sharing, state sharing, events, and other methods. Vandf's data exchange method...
2
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 7 Feb 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:30 (7.30PM). In this month's session, the creator of the excellent VBE...
0
by: fareedcanada | last post by:
Hello I am trying to split number on their count. suppose i have 121314151617 (12cnt) then number should be split like 12,13,14,15,16,17 and if 11314151617 (11cnt) then should be split like...
1
by: davi5007 | last post by:
Hi, Basically, I am trying to automate a field named TraceabilityNo into a web page from an access form. I've got the serial held in the variable strSearchString. How can I get this into the...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: Aftab Ahmad | last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below. Dim IE As Object Set IE =...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.