HELP, 64 bit File Access

[Hercule POIROT]

Hello !

Could you please write for me the simplest portable c program that
handles 64 bit file access.

I want to use only high-level functions (of section 3 : libraries) from
glibc/libc6.

I need answer to the following questions :
- Do I have to invoke gcc with the -D_FILE_OFFSET_BITS=64 argument ?
- Do I have to define a macro likewise : #define _FILE_OFFSET_BITS 64 ?
- Where can I place this macro; before the inclusion of stdlib or stdio ?

I want the program to perform the following tasks :

- Opening of a (long) data file with the appropriate mode.
- Seek of arbitrary 64-bit offset.
- Read the current (64-bit) offset.
- read/write a block of data.
- Seek of the end of the file, using an offset 0 and the seek mode SEEK_END.
- Closing of the file.


Will this program work on Debian GNU/Linux stable 3.1 (sarge) on an
IA-32 architecture machine with the precompiled binary packages for the
kernel 2.6.15, glibc, the gcc suite and binutils ?

I've written a full program of my own that performs well 32-bit file
operations and I'm stuck when I try to adapt it to handle 64-bit files.

Any walkthrough to adapt an existing program likewise ?

Thank you.

Sincerely,
H.P.

 

[Walter Roberson]

Could you please write for me the simplest portable c program that
handles 64 bit file access.

That depends what you mean by "portable". No matter what you do,
you aren't going to be able to use 64 bit file access on filesystems
that are only 32 bit (or less.)

I want to use only high-level functions (of section 3 : libraries) from
glibc/libc6.
I need answer to the following questions :
- Do I have to invoke gcc with the -D_FILE_OFFSET_BITS=64 argument ?

If you want to use gcc and glibc, then you are asking questions
about *non*-portable facilities, and you should ask them in a gnu
newsgroup.

 

[Skarmander]

Hello !

Could you please write for me the simplest portable c program that
handles 64 bit file access.

No such creature, if we're talking about standard C.

I want to use only high-level functions (of section 3 : libraries) from
glibc/libc6.

That ports to many systems, if by no means all.

I need answer to the following questions :
- Do I have to invoke gcc with the -D_FILE_OFFSET_BITS=64 argument ?
- Do I have to define a macro likewise : #define _FILE_OFFSET_BITS 64 ?
- Where can I place this macro; before the inclusion of stdlib or stdio ?

The answer to all your questions is: ask in a more appropriate newsgroup,
like comp.unix.programmer. This has nothing to do with standard C. (64-bit
file access is defined by POSIX as well.)

Sincerely,
H.P.

And for a detective of your renown, I would have expected you to find that
out on your own.

S.

 

[Herbert Rosenau]

Hello !

Could you please write for me the simplest portable c program that
handles 64 bit file access.

I want to use only high-level functions (of section 3 : libraries) from
glibc/libc6.

glibc is NOT a standard C library. It is itself highly system
dependant. So ask in a group matching your target system.

C has no idea of files, directories, disks or other devices. The only
C knows of is streams. So again, ask in a group matching to your
system.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

 

[Skarmander]

Herbert Rosenau wrote:

C has no idea of files, directories, disks or other devices. The only
C knows of is streams.

Untrue; C certainly does have a notion of files (in addition to streams), as
evidenced by section 7.19 of the standard (which describes <stdio.h>). It is
true that most platforms have a more detailed implementation of files than
is covered by standard C, of course.

S.

 

[Hercule POIROT]

Skarmander a écrit :

Herbert Rosenau wrote:

Untrue; C certainly does have a notion of files (in addition to
streams), as evidenced by section 7.19 of the standard (which describes
<stdio.h>). It is true that most platforms have a more detailed
implementation of files than is covered by standard C, of course.

S.

Thanks.

I'm pleased that you feel interested in my problem.

Furthermore, programmers are not so stupid as to have sclattered their
efforts amongst several different standards or interfaces about the
single topic of 64-bit file access ; most of them know of the POSIX
standard ;-)

Since I want to talk about portable C code, I mean to develop for a
target that has a POSIX-compliant stdio library.

In addition, is talking about functional and as portable as feasible C (
but non pure-C ) source code out of the scope of this newsgroup ?

We could even say that an int has no size in C since it is
platform-dependent !!!

I think such POSIX-compliant standard C libraries are commonplace under
*nix environments ; following your advice, I've made a more appropriate
post.

If, let's say in near future, MS Windows provides us with a Standard C
Library that is POSIX-compliant towards 64-bit file access, couldn't we
say that today's C language and its standard library are the common
denominator of accessing 64-bit files under all these OSes : UNIX,
Linux, *BSD, MS Windows, and so on ... ?

Can you all really evoke C programming without its standard libraries ?

What about access to 64-bit files under a 32-bit platform that uses a
64-bit-aware filesystem; and its coding in C with / APPROPRIATE standard
libraries under APPROPRIATE OSes ?

Thanks for developing a bit WHERE my problem is beyond the scope of this
newsgroup.

Bye,
H.P.

 

[Walter Roberson]

Furthermore, programmers are not so stupid as to have sclattered their
efforts amongst several different standards or interfaces about the
single topic of 64-bit file access ; most of them know of the POSIX
standard ;-)

Except for the OS functions that predate the standard, that
are in the operating systems of companies that developed the
ideas that the standards were derived from...

Since I want to talk about portable C code, I mean to develop for a
target that has a POSIX-compliant stdio library.

In addition, is talking about functional and as portable as feasible C (
but non pure-C ) source code out of the scope of this newsgroup ?

Yes. In this newsgroup we interpret programs in terms of the
existing C standards, and generally consider as off-topic any
program whose source relies upon features not found in those
standards.

If there is any call to a routine whose standard-C
compliant source is not given and whose -exact- semantics
is not documented, then we generally assume that the purpose
of said routine is to remove all files, launch a nuclear bomb,
and divide by zero -- and if those things haven't happened yet,
we presume that it is only due to bugs in the implementation.

We could even say that an int has no size in C since it is
platform-dependent !!!

No, it just doesn't have a -fixed- size in C. The C standards
make it clear that it must be able to hold at least 32767,
but the C standards are agnostic as to whether that's one
byte or two, and agnostic about whether 1<<31-1 is one, two,
or four bytes. {Hmmm, let's see, if a char was 12 bits long,
then 1<<31-1 could be represented in 3 bytes, so sizeof(int) could
possibly even be 3.}

If someone were to give you instructions to "Put on your shoe
and kick the football", then would you say that your shoe has
no size because it is wearer-dependant ?

If, let's say in near future, MS Windows provides us with a Standard C
Library that is POSIX-compliant towards 64-bit file access, couldn't we
say that today's C language and its standard library are the common
denominator of accessing 64-bit files under all these OSes : UNIX,
Linux, *BSD, MS Windows, and so on ... ?

No, today's "standard library" for C knows nothing about 64 bit
files, and there are still numerous Unices that have no 64 bit files.

Can you all really evoke C programming without its standard libraries ?

POSIX is not a C standard library. POSIX is an OS implementation
library which is an add-on.

What about access to 64-bit files under a 32-bit platform that uses a
64-bit-aware filesystem; and its coding in C with / APPROPRIATE standard
libraries under APPROPRIATE OSes ?

This newsgroup works with the C standard library. Libraries
belonging to other standards are off-topic here (unless they are
coded in standard C without extensions.)

 

[Flash Gordon]

Skarmander a écrit :

Thanks.

I'm pleased that you feel interested in my problem.

Furthermore, programmers are not so stupid as to have sclattered their
efforts amongst several different standards or interfaces about the
single topic of 64-bit file access ; most of them know of the POSIX
standard ;-)

Since I want to talk about portable C code, I mean to develop for a
target that has a POSIX-compliant stdio library.

Try running your POSIX compliant code on an Atari ST or an embedded
system. You will even find problems trying to run it on DOS or Windows!

In addition, is talking about functional and as portable as feasible C (
but non pure-C ) source code out of the scope of this newsgroup ?

This group only deals with C as defined by the C standard. For POSIX you
have comp.unix.programmer.

We could even say that an int has no size in C since it is
platform-dependent !!!

It has a minimum size, it is at least 16 bits and has a range of at
least -32767 to +32767

I think such POSIX-compliant standard C libraries are commonplace under
*nix environments ; following your advice, I've made a more appropriate
post.

If, let's say in near future, MS Windows provides us with a Standard C
Library that is POSIX-compliant towards 64-bit file access, couldn't we
say that today's C language and its standard library are the common
denominator of accessing 64-bit files under all these OSes : UNIX,
Linux, *BSD, MS Windows, and so on ... ?

There are more systems than are dreamt of in your philosophy...

Can you all really evoke C programming without its standard libraries ?

Non-hosted systems are required to have only very minimal library
support (a few headers and no functions). Even hosted implementations
are not required to support any additional items POSIX specifies.

What about access to 64-bit files under a 32-bit platform that uses a
64-bit-aware filesystem; and its coding in C with / APPROPRIATE standard
libraries under APPROPRIATE OSes ?

If it just works with standard file streams fine, otherwise you need to
use something specific to the OS in question.

Thanks for developing a bit WHERE my problem is beyond the scope of this
newsgroup.

As you want to be portable across POSIX ask in comp.unix.programmer.