Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Porting from POSIX (FILE*) API to file descriptors. What is theequivalent of...

Reply
Thread Tools

Porting from POSIX (FILE*) API to file descriptors. What is theequivalent of...

 
 
Stephan Beal
Guest
Posts: n/a
 
      01-08-2009
Hello, all!

If this question seems off topic, please feel free to ignore it.

i'm busy porting some code which currently uses the POSIX file API
(e.g. fopen(), fclose(), fwrite(), etc.) to use the lower-level APIs
based on file descriptors. The original reason for porting is so that
i can add locking via fcntl() (and the literature suggests against
mixing the low-level and (FILE*) APIs), but tests have also shown the
port to provide a very substantial performance increase for my
particular use case.

i've run into a bit of a problem, though...

i can't seem to find lower-level equivalents for functions like feof
(), ferror(), and fclearerr(). Do such a things exist for the lower-
level API (i.e. requiring a file descriptor instead of a (FILE*)? If
not, is there a way to simulate them? For example, here's my first
attempt at simulating feof(), but i honestly have no clue if this
approach is valid using the lower-level API (seems reasonable/naive
enough, though):

bool iseof( int fileno )
{
off_t p1 = lseek( fileno, 0L, SEEK_CUR );
off_t p2 = lseek( fileno, 0L, SEEK_END );
bool rc = (p1 >= p2);
lseek( fileno, p1, SEEK_SET );
return rc;
}

The routines i'm looking for replacements for (or looking to simulate)
are:

- feof()
- ferror()
- clearerr()

all the other operations of the i/o device interface/API i'm working
inside of can be implemented directly using the lower-level operations
(e.g. read(), write(), ftruncate(), fdatasync()/fsync(), lseek()).

Any pointers in the right (or *a* right) direction would be much
appreciated.


 
Reply With Quote
 
 
 
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-08-2009
On Jan 8, 9:06*pm, Stephan Beal <(E-Mail Removed)> wrote:

<snip>

> The routines i'm looking for replacements for (or looking to simulate)
> are:
>
> * - feof()
> * - ferror()
> * - clearerr()


int feof(FILE *stream) { return stream->eof; }
int ferror(FILE *stream) { return stream->error; }
void clearerr(FILE *stream) { stream->error = stream->eof = 0; }
 
Reply With Quote
 
 
 
 
Stephan Beal
Guest
Posts: n/a
 
      01-08-2009
On Jan 8, 8:10*pm, (E-Mail Removed) wrote:
> On Jan 8, 9:06*pm, Stephan Beal <(E-Mail Removed)> wrote:
> > The routines i'm looking for replacements for (or looking to simulate)
> > are:

>
> > * - feof()
> > * - ferror()
> > * - clearerr()

>
> int feof(FILE *stream) { return stream->eof; }
> int ferror(FILE *stream) { return stream->error; }
> void clearerr(FILE *stream) { stream->error = stream->eof = 0; }


The problem is that i can't mix the FILE and file descriptor APIs
reliably (at least, literature such as the open() and fopen() man
pages strongly suggest against it due to buffering in the FILE* API).
Because i'm doing all i/o with read(), write(), and lseek(), the error
flags set in a FILE object are not [likely to be] valid (just as the
FILE handle's cursor position is [probably] not going to match
reality).

Internally i'm currently holding both a FILE* and a file descriptor
(to the same file), and only using the fXXXX() API for those 3
routines listed above. However, i'm quite certain my use of them is
bogus because of the problem mentioned in the previous paragraph.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2009
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
> On Jan 8, 9:06*pm, Stephan Beal <(E-Mail Removed)> wrote:
> <snip>
>
>> The routines i'm looking for replacements for (or looking to simulate)
>> are:
>>
>> * - feof()
>> * - ferror()
>> * - clearerr()

>
> int feof(FILE *stream) { return stream->eof; }
> int ferror(FILE *stream) { return stream->error; }
> void clearerr(FILE *stream) { stream->error = stream->eof = 0; }


Huh? What makes you think that FILE is a struct type that has members
named "eof" and "error"?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2009
Stephan Beal <(E-Mail Removed)> writes:
> If this question seems off topic, please feel free to ignore it.
>
> i'm busy porting some code which currently uses the POSIX file API
> (e.g. fopen(), fclose(), fwrite(), etc.) to use the lower-level APIs
> based on file descriptors. The original reason for porting is so that
> i can add locking via fcntl() (and the literature suggests against
> mixing the low-level and (FILE*) APIs), but tests have also shown the
> port to provide a very substantial performance increase for my
> particular use case.


I suggest asking about this in comp.unix.programmer (and ignoring the
trolls who will inevitably jump in to tell you otherwise). The
lower-level APIs are defined by POSIX, not by the C standard.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
vippstar@gmail.com
Guest
Posts: n/a
 
      01-08-2009
On Jan 8, 10:06*pm, Keith Thompson <(E-Mail Removed)> wrote:
> (E-Mail Removed) writes:
> > On Jan 8, 9:06*pm, Stephan Beal <(E-Mail Removed)> wrote:
> > <snip>

>
> >> The routines i'm looking for replacements for (or looking to simulate)
> >> are:

>
> >> * - feof()
> >> * - ferror()
> >> * - clearerr()

>
> > int feof(FILE *stream) { return stream->eof; }
> > int ferror(FILE *stream) { return stream->error; }
> > void clearerr(FILE *stream) { stream->error = stream->eof = 0; }

>
> Huh? *What makes you think that FILE is a struct type that has members
> named "eof" and "error"?


My point was that he was not really looking for what he thought to be
looking for, since an arbitrary implementation of those functions is
of no use.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-08-2009
(E-Mail Removed) writes:
> On Jan 8, 10:06*pm, Keith Thompson <(E-Mail Removed)> wrote:
>> (E-Mail Removed) writes:
>> > On Jan 8, 9:06*pm, Stephan Beal <(E-Mail Removed)> wrote:
>> > <snip>

>>
>> >> The routines i'm looking for replacements for (or looking to simulate)
>> >> are:

>>
>> >> * - feof()
>> >> * - ferror()
>> >> * - clearerr()

>>
>> > int feof(FILE *stream) { return stream->eof; }
>> > int ferror(FILE *stream) { return stream->error; }
>> > void clearerr(FILE *stream) { stream->error = stream->eof = 0; }

>>
>> Huh? *What makes you think that FILE is a struct type that has members
>> named "eof" and "error"?

>
> My point was that he was not really looking for what he thought to be
> looking for, since an arbitrary implementation of those functions is
> of no use.


Then make that point.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      01-08-2009
Stephan Beal wrote:
> Hello, all!
>
> If this question seems off topic, please feel free to ignore it.
>
> i'm busy porting some code which currently uses the POSIX file API
> (e.g. fopen(), fclose(), fwrite(), etc.) to use the lower-level APIs


fopen etc are part of the standard C library which POSIX merely
inherits, they are not POSIX specific.

<snip>

> i can't seem to find lower-level equivalents for functions like feof
> (), ferror(), and fclearerr(). Do such a things exist for the lower-
> level API (i.e. requiring a file descriptor instead of a (FILE*)? If
> not, is there a way to simulate them? For example, here's my first


<snip>

By the low-level API I'm guessing you mean open, read etc which actually
*are* defined by POSIX (although some non-POSIX systems also have
similarly named functions). So I suggest you read the man pages (or
equivalent documentation) for them paying attention to return values and
error handling provided by them and then go over to comp.unix.programmer
to ask further questions about them.

Be aware that at least some of the trolls who may provide
helpful-looking answers are proven liars, so any answers you get here
(where POSIX is not topical) may be completely or subtly wrong and there
is no guarantee that a correction would be provided.
--
Flash Gordon
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      01-08-2009
Stephan Beal wrote:
> i'm busy porting some code which currently uses the POSIX file API
> (e.g. fopen(), fclose(), fwrite(), etc.) to use the lower-level APIs
> based on file descriptors.


You seem to be confused. FILE* objects are used by the C standard I/O
library. POSIX defines an API that uses what it calls "file descriptors".

The folks in comp.unix.programmer should be able to help you with the
latter; it is off-topic here.

<OT>

> i can't seem to find lower-level equivalents for functions like feof
> (), ferror(), and fclearerr(). Do such a things exist for the lower-
> level API (i.e. requiring a file descriptor instead of a (FILE*)? If
> not, is there a way to simulate them?


There are no direct POSIX equivalents to those functions, nor are they
needed; EOF and errors are communicated using a different method that
does not require them. Look in the man pages for the functions you are
using and pay close attention to the "Return Value" and "Errors" sections.

</OT>

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Isaac Jaffe
 
Reply With Quote
 
Stephan Beal
Guest
Posts: n/a
 
      01-08-2009
On Jan 8, 9:51*pm, Flash Gordon <(E-Mail Removed)> wrote:
> By the low-level API I'm guessing you mean open, read etc which actually
> *are* defined by POSIX (although some non-POSIX systems also have
> similarly named functions). So I suggest you read the man pages (or
> equivalent documentation) for them paying attention to return values and
> error handling provided by them and then go over to comp.unix.programmer
> to ask further questions about them.


Yes, i mean open(), read(), etc. (and i admit to being confused by
which standard defines which functions). i've scoured the man pages
and all of the "see also" references, but i have found no equivalent
to feof(), ferror(), and clearerr() which works on file descriptors
(only FILE) handles. Since i have to avoid using the FILE handle and
the file descriptor APIs for the same object (because the man pages
say not to), i've grown very curious as to how those ops are achieved
when one has only a file descriptor.

i'll take a look over at comp.unix.programmer - thanks for the tip .

(And thanks to the rest of you for your time!!!)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Porting Python2 C-API/Swig based modules to Python 3 Adam Pridgen Python 3 02-24-2011 12:19 AM
How to generate execute file that include enthought.traits.api ,enthought.traits.ui.api ? ray Python 1 06-04-2010 03:49 PM
no module api file after generating ruby core api Bob Lu Ruby 0 06-25-2009 03:07 AM
signal handlers: does %SIG{'CLD'} require explicit SA_NOCLDSTOP via POSIX funcs? steffen staehle Perl 0 09-07-2004 03:22 PM
posix vs perl regular expressions RN Perl 0 09-10-2003 06:25 PM



Advertisments