Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #72234 > unrolled thread

Working with files on different operating systems

Back to article view | Back to comp.lang.c

Contents

  Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 05:11 +0200
    Re: Working with files on different operating systems Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-08 22:12 -0600
    Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 00:18 -0500
      Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-09 11:13 +0100
        Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 18:05 +0200
          Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 12:49 -0500
          Re: Working with files on different operating systems Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-09 17:32 -0400
          Re: Working with files on different operating systems Ian Collins <ian-news@hotmail.com> - 2015-10-10 12:37 +1300
        Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 12:48 -0500
          Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-09 19:53 +0100
            Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 21:09 +0200
              Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-09 20:28 +0100
                Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 21:40 +0200
                  Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-09 15:59 -0400
                    Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 22:07 +0200
                      Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-09 16:24 -0400
                        Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-10 03:08 +0200
                  Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-09 21:50 +0100
          Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-09 14:54 -0400
            Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 21:05 +0200
              Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 21:47 +0200
              Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-09 15:53 -0400
                Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 22:01 +0200
                  Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-09 16:05 -0400
            Re: Working with files on different operating systems glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-10 01:16 +0000
              Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-10 03:46 +0200
              Re: Working with files on different operating systems Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-10 08:08 -0400
            Re: Working with files on different operating systems raltbos@xs4all.nl (Richard Bos) - 2015-10-10 17:02 +0000
          Re: Working with files on different operating systems Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-09 15:53 -0400
      Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 18:00 +0200
        Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 12:59 -0500
          Re: Working with files on different operating systems Keith Thompson <kst-u@mib.org> - 2015-10-09 12:37 -0700
            Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 17:36 -0500
              Re: Working with files on different operating systems Keith Thompson <kst-u@mib.org> - 2015-10-09 16:52 -0700
                Re: Working with files on different operating systems raltbos@xs4all.nl (Richard Bos) - 2015-10-14 11:27 +0000
                  Re: Working with files on different operating systems James Kuyper <jameskuyper@verizon.net> - 2015-10-14 11:27 -0400
                  Re: Working with files on different operating systems Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-14 16:46 +0000
                  Re: Working with files on different operating systems Keith Thompson <kst-u@mib.org> - 2015-10-14 10:18 -0700
                Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-14 23:06 -0500
      Re: Working with files on different operating systems Keith Thompson <kst-u@mib.org> - 2015-10-09 09:16 -0700
        Re: Working with files on different operating systems Les Cargill <lcargill99@comcast.com> - 2015-10-09 17:43 -0500
          Re: Working with files on different operating systems Keith Thompson <kst-u@mib.org> - 2015-10-09 16:57 -0700
            Re: Working with files on different operating systems Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-09 22:41 -0700
      Re: Working with files on different operating systems David Thompson <dave.thompson2@verizon.net> - 2015-10-31 06:50 -0400
    Re: Working with files on different operating systems Siri Cruz <chine.bleu@yahoo.com> - 2015-10-08 23:25 -0700
      Re: Working with files on different operating systems Geoff <geoff@invalid.invalid> - 2015-10-10 10:35 -0700
    Re: Working with files on different operating systems Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-09 08:42 -0400
      Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-09 18:51 +0200
        Re: Working with files on different operating systems Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-15 18:09 -0700
          Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-17 04:01 +0200
            Re: Working with files on different operating systems Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:55 +1300
              Re: Working with files on different operating systems Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-16 20:09 -0700
                Re: Working with files on different operating systems Ian Collins <ian-news@hotmail.com> - 2015-10-17 16:36 +1300
              Re: Working with files on different operating systems "Morten W. Petersen" <morphex@gmail.com> - 2015-10-17 05:10 +0200
          Re: Working with files on different operating systems supercat@casperkitty.com - 2015-10-31 12:05 -0700
            Re: Working with files on different operating systems Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-31 12:42 -0700
              Re: Working with files on different operating systems supercat@casperkitty.com - 2015-10-31 13:40 -0700
            Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 19:55 +0000
              Re: Working with files on different operating systems supercat@casperkitty.com - 2015-10-31 13:43 -0700
                Re: Working with files on different operating systems Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-31 21:38 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#72310

On 09.10.2015 21:27, Stefan Ram wrote:
> "Morten W. Petersen" <morphex@gmail.com> writes:
>> Well you can read answers other places in this thread posted well
>> before you posted this one and see what we're actually discussing.
>
>    In a newsgroup, there is not a single instance that defines
>    what one discusses (an answer should be related to the topic
>    of the newsgroup and the thread or preceding post, though).
>
>    James has a much a right to discuss what is interesting to him
>    as you have the right to discuss what is interesting to you.
>    There is no dichotomy between »we« and James, James is part of »we«.

OK, I read James and Ben's posts after one another (20:53 and 20:54),
and guess I brushed them under the same comb, while James' post appears
to be correct.

-Morten

[toc] | [prev] | [next] | [standalone]

#72312

On 10/09/2015 03:05 PM, Morten W. Petersen wrote:
> On 09.10.2015 20:54, James Kuyper wrote:
>> On 10/09/2015 01:48 PM, Les Cargill wrote:
>>> Ben Bacarisse wrote:
>> ...
>>>> To the OP: there's no obvious reason for you to know the input size
>>>> before you parse it.  Are you storing it whole for some purpose that has
>>>> eluded me?  If so, you will have to avoid knowing the size if you want
>>>> to handle the widest range in input sources.
>>>>
>>>
>>> He wants to know how big a buffer to allocate. That is not unreasonable.
>>
>> He wants to read the entire file into a single buffer. Depending upon
>> context, that might be unreasonable. Many programs can do their intended
>> job by reading in only one character at a time, or one line at a time,
>> or one record at a time. When that's the case, reading in the entire
>> file before processing it can lead to unnecessary complications, like
>> this one.
> 
> Well you can read answers other places in this thread posted well
> before you posted this one and see what we're actually discussing.

I did. I didn't see anything that gave enough information about the
intended purpose of this code to determine whether or not reading the
entire file in at one time was a good idea. You posted the first message
you that said anything about the purpose of this program at 03:09 today,
4 minutes after the message I'm responding to.

From that explanation, I strongly suspect that the best approach would
be to do a buffered read of a single character at a time using fgetc(),
and to push that character through a parsing engine that recognizes the
syntax of the files you're reading, and builds structures in memory to
represent their contents. Depending upon that syntax, you might need a
limited amount of look-ahead, but you shouldn't need to have the ability
to look at the entire input file at one time.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#72315

On 09.10.2015 21:53, James Kuyper wrote:
> On 10/09/2015 03:05 PM, Morten W. Petersen wrote:
>> On 09.10.2015 20:54, James Kuyper wrote:
>>> On 10/09/2015 01:48 PM, Les Cargill wrote:
>>>> Ben Bacarisse wrote:
>>> ...
>>>>> To the OP: there's no obvious reason for you to know the input size
>>>>> before you parse it.  Are you storing it whole for some purpose that has
>>>>> eluded me?  If so, you will have to avoid knowing the size if you want
>>>>> to handle the widest range in input sources.
>>>>>
>>>>
>>>> He wants to know how big a buffer to allocate. That is not unreasonable.
>>>
>>> He wants to read the entire file into a single buffer. Depending upon
>>> context, that might be unreasonable. Many programs can do their intended
>>> job by reading in only one character at a time, or one line at a time,
>>> or one record at a time. When that's the case, reading in the entire
>>> file before processing it can lead to unnecessary complications, like
>>> this one.
>>
>> Well you can read answers other places in this thread posted well
>> before you posted this one and see what we're actually discussing.
>
> I did. I didn't see anything that gave enough information about the
> intended purpose of this code to determine whether or not reading the
> entire file in at one time was a good idea. You posted the first message
> you that said anything about the purpose of this program at 03:09 today,
> 4 minutes after the message I'm responding to.

To me it looked like you and Ben responded well after different
approaches and reasoning behind those approaches were mentioned.

Message ID <mv8r8o$ru8$1@speranza.aioe.org> for example has the
local time here of 18:51, while in your message with ID
<87zizrj2ky.fsf@bsb.me.uk> local time 20:53 you say that it is
unreasonable to know how big of a buffer to allocate.

>  From that explanation, I strongly suspect that the best approach would
> be to do a buffered read of a single character at a time using fgetc(),
> and to push that character through a parsing engine that recognizes the
> syntax of the files you're reading, and builds structures in memory to
> represent their contents. Depending upon that syntax, you might need a
> limited amount of look-ahead, but you shouldn't need to have the ability
> to look at the entire input file at one time.

There are reasons for different approaches, fgetc is one, while there
may be benefits of others as well.

-Morten

[toc] | [prev] | [next] | [standalone]

#72318

On 10/09/2015 04:01 PM, Morten W. Petersen wrote:
...
> To me it looked like you and Ben responded well after different
> approaches and reasoning behind those approaches were mentioned.

Your reasons for choosing to read the entire file at one time have not
yet been mentioned in any message I've seen, and I thought I've seen
them all.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#72360

James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/09/2015 01:48 PM, Les Cargill wrote:

(snip)
>> He wants to know how big a buffer to allocate. 
>> That is not unreasonable.
 
> He wants to read the entire file into a single buffer. Depending upon
> context, that might be unreasonable. Many programs can do their intended
> job by reading in only one character at a time, or one line at a time,
> or one record at a time. When that's the case, reading in the entire
> file before processing it can lead to unnecessary complications, like
> this one.

Yes. It seems that many new programmers like to read a while file
into memory, process it, then write out the results. There is some
tendency to do that, even in the cases where the output can be 
generated line-by-line from the input data.  

For people who started programming when machines were much smaller 
than today, learning to avoid reading in whole files was important.

There are cases where reading in a while file is useful, though even
then the size of the file isn't always what you want to know. 
(You might store it with different line-end convention than on
disk.)

A loop using realloc() isn't so hard to do, and worth learning.

-- glen

[toc] | [prev] | [next] | [standalone]

#72364

On 10.10.2015 03:31, Stefan Ram wrote:
[...]
>    When one has to parse a recursive language, there does not
>    seem to be a replacement for a real parser. Possibly, the
>    ability to read and write grammers and parsers separates the
>    programmer who has learned programming in a dedicated
>    college course of studies from the amateur.

Do you get more certain of that for every student loan installment you
make?

-Morten

[toc] | [prev] | [next] | [standalone]

#72391

On 10/9/2015 9:16 PM, glen herrmannsfeldt wrote:
> James Kuyper <jameskuyper@verizon.net> wrote:
>> On 10/09/2015 01:48 PM, Les Cargill wrote:
>
> (snip)
>>> He wants to know how big a buffer to allocate.
>>> That is not unreasonable.
>
>> He wants to read the entire file into a single buffer. Depending upon
>> context, that might be unreasonable. Many programs can do their intended
>> job by reading in only one character at a time, or one line at a time,
>> or one record at a time. When that's the case, reading in the entire
>> file before processing it can lead to unnecessary complications, like
>> this one.
>
> Yes. It seems that many new programmers like to read a while file
> into memory, process it, then write out the results. There is some
> tendency to do that, even in the cases where the output can be
> generated line-by-line from the input data.
>
> For people who started programming when machines were much smaller
> than today, learning to avoid reading in whole files was important.

     Also for people nowadays whose large machines are still far too
small to accommodate all the data.  Until a few years ago, I worked
for a company that "downloads the Internet" repeatedly. You can bet
we didn't read *that* into RAM in one go!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#72398

James Kuyper <jameskuyper@verizon.net> wrote:

> On 10/09/2015 01:48 PM, Les Cargill wrote:
> > Ben Bacarisse wrote:
> ...
> >> To the OP: there's no obvious reason for you to know the input size
> >> before you parse it.  Are you storing it whole for some purpose that has
> >> eluded me?  If so, you will have to avoid knowing the size if you want
> >> to handle the widest range in input sources.
> >>
> > 
> > He wants to know how big a buffer to allocate. That is not unreasonable.
> 
> He wants to read the entire file into a single buffer. Depending upon
> context, that might be unreasonable.

The point is, though, that that context is going to be _inherently_
system-specific, and therefore, so is the solution. No portable ISO C
solution exists, or can exist.

<http://c-faq.com/osdep/filesize.html>

Richard

[toc] | [prev] | [next] | [standalone]

#72311

On 10/9/2015 1:48 PM, Les Cargill wrote:
> Ben Bacarisse wrote:
>> [...]
>> You can't rewind many kinds of stream, and that's as true today as it
>> ever was.
>
> Then you can't actually maintain the file size without some sort of out
> of band ... thing. You take the data as it comes.
>
> Is there some secret society dedicated to keeping 9-track
> tape or those awful cartridge tapes alive? They have *piles*
> of 4 TB drives down at Fry's and they are stupid cheap...

     I bought one to replace my keyboard.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#72268

On 09.10.2015 07:18, Les Cargill wrote:
> Morten W. Petersen wrote:
[...]
>> That way, the code for reading a file and reading a stream for example
>> from the network is the same.
>>
>
> Are you familiar with select/poll/epoll? Might be time to
> learn about them; this is a good ( albeit tedious ) way to
> unify these things.

I've barely glanced at them, will have a closer look.

>> It might be enough to realloc, but maybe a bit more robust solution
>> for adding onto a buffer in increments is to have a buffer segment
>> that is linked to the next buffer segment and so on.
>>
>> Any thoughts on this?
>>
>
> Your original plan should be just fine. This is the way I have
> determined file sizes since the 20th Century, modulo declariong
> and initializing things at the same time for some cruder toolchains:
>
> FILE *f = fopen(....);
>
> int rc = fseek(f,SEEK_END,0L);
> int len = ftell(f);
> rc = fseek(f,SEEK_SET,0L);
>
> after which, the file is nicely rewound and len contains the total
> number of octets in the file.
>
> Obviously  for some file systems this may not work, but those are
> hard to find now.

Well, what about this then?

https://www.securecoding.cert.org/confluence/display/c/FIO19-C.+Do+not+use+fseek()+and+ftell()+to+compute+the+size+of+a+regular+file

-Morten

[toc] | [prev] | [next] | [standalone]

#72292

Morten W. Petersen wrote:
> On 09.10.2015 07:18, Les Cargill wrote:
>> Morten W. Petersen wrote:
> [...]
>>> That way, the code for reading a file and reading a stream for example
>>> from the network is the same.
>>>
>>
>> Are you familiar with select/poll/epoll? Might be time to
>> learn about them; this is a good ( albeit tedious ) way to
>> unify these things.
>
> I've barely glanced at them, will have a closer look.
>
>>> It might be enough to realloc, but maybe a bit more robust solution
>>> for adding onto a buffer in increments is to have a buffer segment
>>> that is linked to the next buffer segment and so on.
>>>
>>> Any thoughts on this?
>>>
>>
>> Your original plan should be just fine. This is the way I have
>> determined file sizes since the 20th Century, modulo declariong
>> and initializing things at the same time for some cruder toolchains:
>>
>> FILE *f = fopen(....);
>>
>> int rc = fseek(f,SEEK_END,0L);
>> int len = ftell(f);
>> rc = fseek(f,SEEK_SET,0L);
>>
>> after which, the file is nicely rewound and len contains the total
>> number of octets in the file.
>>
>> Obviously  for some file systems this may not work, but those are
>> hard to find now.
>
> Well, what about this then?
>
> https://www.securecoding.cert.org/confluence/display/c/FIO19-C.+Do+not+use+fseek()+and+ftell()+to+compute+the+size+of+a+regular+file
>
>
> -Morten
>

Excellent question!

Always use binary mode ( when applicable ). You do have to
entertain the possibility of the two caveats given:

	- extra null characters.
	- a binary stream need not fully support ftell().

but in about ten minutes, you should be able to determine 
programmatically  if those are relevant to your system or not.

If whether or not they are relevant is an open question, then you
have more work to do.

And if this is a *profoundly* open question, I'd use
certain architectural solutions - like custom drivers, threading or
other techniques - to ameliorate it and make the main thing
work as if it were talking to a file on disk.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#72306

Les Cargill <lcargill99@comcast.com> writes:
[...]
> Always use binary mode ( when applicable ).
[...]

I would add to that:

Always use text mode (when applicable).

In other words, always use the appopriate mode for the data you're
dealing with.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72341

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
> [...]
>> Always use binary mode ( when applicable ).
> [...]
>
> I would add to that:
>
> Always use text mode (when applicable).
>

I meant by "when applicable" that text mode
sort of makes no sense on Linux.

No, always use binary, nonblocking ( and no buffering if you can ) in 
terms of the entry points exposed by of file.h

Yes, even for simple filters. And ESPECIALLY for tty devices
unless somebody's forcing you to use control signals in a
certain kind of way. In that case, protest loudly.

> In other words, always use the appopriate mode for the data you're
> dealing with.
>

This too. Although I'd rather write a state machine to split lines
than depend on the marshalling/unmarshalling of the standard library.

Your mileage may vary.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#72354

Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>> [...]
>>> Always use binary mode ( when applicable ).
>> [...]
>>
>> I would add to that:
>>
>> Always use text mode (when applicable).
>
> I meant by "when applicable" that text mode
> sort of makes no sense on Linux.
>
> No, always use binary, nonblocking ( and no buffering if you can ) in 
> terms of the entry points exposed by of file.h

What is "file.h"?

Text mode makes perfectly good sense on Linux.  It just happens to
behave the same way as binary mode.

If I'm going to read a file that I expect to contain text, I'll open it
with
    fopen("filename.txt", "r");
If I expect it to contain arbitrary data, I'll use
    fopen("filename.dat", "rb");

If my code ends up running on Windows, it should still work (assuming
it's not given foreign-format text files).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72822

Keith Thompson <kst-u@mib.org> wrote:

> Les Cargill <lcargill99@comcast.com> writes:
> > Keith Thompson wrote:
> >> Les Cargill <lcargill99@comcast.com> writes:
> >> [...]
> >>> Always use binary mode ( when applicable ).
> >> [...]
> >>
> >> I would add to that:
> >>
> >> Always use text mode (when applicable).
> >
> > I meant by "when applicable" that text mode
> > sort of makes no sense on Linux.
> >
> > No, always use binary, nonblocking ( and no buffering if you can ) in 
> > terms of the entry points exposed by of file.h
> 
> What is "file.h"?

It's yet another way to lock you into Linux Only.

Monopolisation? Didn't Microsoft have a monopoly on that? Evidently not.

Richard

[toc] | [prev] | [next] | [standalone]

#72846

On 10/14/2015 07:27 AM, Richard Bos wrote:
> Keith Thompson <kst-u@mib.org> wrote:
> 
>> Les Cargill <lcargill99@comcast.com> writes:
...
>>> No, always use binary, nonblocking ( and no buffering if you can ) in 
>>> terms of the entry points exposed by of file.h
>>
>> What is "file.h"?
> 
> It's yet another way to lock you into Linux Only.

I've been using Linux for a couple of decade now, and I've almost never
had to #include <sys/file.h>, so they aren't doing a particularly
effective job of locking me into Linux Only. On my desktop system,
sys/file.h is essentially a wrapper for fcntl.h, which I have actually
made use of, on rare occasions - but only directly, through #include
<fcntl.h>. The only thing that sys/file.h itself provides is a prototype
for flock() and several associated macros.

The man page for flock() says that it conforms to 4.4.BSD, and has been
part of the BSD specification since version 4.2, which dates back to
1983, so it's not Linux-specific.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#72855

On Wed, 2015-10-14, Richard Bos wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
>> Les Cargill <lcargill99@comcast.com> writes:
>> > Keith Thompson wrote:
>> >> Les Cargill <lcargill99@comcast.com> writes:
>> >> [...]
>> >>> Always use binary mode ( when applicable ).
>> >> [...]
>> >>
>> >> I would add to that:
>> >>
>> >> Always use text mode (when applicable).
>> >
>> > I meant by "when applicable" that text mode
>> > sort of makes no sense on Linux.
>> >
>> > No, always use binary, nonblocking ( and no buffering if you can ) in 
>> > terms of the entry points exposed by of file.h
>> 
>> What is "file.h"?
>
> It's yet another way to lock you into Linux Only.

Are you just guessing?  There is no file.h on my Linux system.  There
is a <sys/file.h>, but it seems to just expose flock(), and that one
was introduced in BSD back in the days, long before Linux.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#72858

raltbos@xs4all.nl (Richard Bos) writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>> > Keith Thompson wrote:
>> >> Les Cargill <lcargill99@comcast.com> writes:
>> >> [...]
>> >>> Always use binary mode ( when applicable ).
>> >> [...]
>> >>
>> >> I would add to that:
>> >>
>> >> Always use text mode (when applicable).
>> >
>> > I meant by "when applicable" that text mode
>> > sort of makes no sense on Linux.
>> >
>> > No, always use binary, nonblocking ( and no buffering if you can ) in 
>> > terms of the entry points exposed by of file.h
>> 
>> What is "file.h"?
>
> It's yet another way to lock you into Linux Only.
>
> Monopolisation? Didn't Microsoft have a monopoly on that? Evidently not.

I believe you misunderstood the question.  Others have answered it,
though.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#72923

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> Keith Thompson wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>> [...]
>>>> Always use binary mode ( when applicable ).
>>> [...]
>>>
>>> I would add to that:
>>>
>>> Always use text mode (when applicable).
>>
>> I meant by "when applicable" that text mode
>> sort of makes no sense on Linux.
>>
>> No, always use binary, nonblocking ( and no buffering if you can ) in
>> terms of the entry points exposed by of file.h
>
> What is "file.h"?
>

I typed file.h and meant stdio.h

> Text mode makes perfectly good sense on Linux.  It just happens to
> behave the same way as binary mode.
>
> If I'm going to read a file that I expect to contain text, I'll open it
> with
>      fopen("filename.txt", "r");
> If I expect it to contain arbitrary data, I'll use
>      fopen("filename.dat", "rb");
>
> If my code ends up running on Windows, it should still work (assuming
> it's not given foreign-format text files).
>
> [...]
>
-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#72272

Les Cargill <lcargill99@comcast.com> writes:
> Morten W. Petersen wrote:
>> I was working on removing warnings from 'gcc -Wall....' and found that
>> fileno was a POSIX-specific function call,
>
> ???
>
> For Mingw:
>
> C:\windows\system32>grep fileno \MinGW\include\*.h
> \MinGW\include\stdio.h:_CRTIMP int __cdecl __MINGW_NOTHROW      _fileno 
> (FILE*);
> \MinGW\include\stdio.h:_CRTIMP int __cdecl __MINGW_NOTHROW      fileno 
> (FILE*);
> \MinGW\include\stdio.h:#define _fileno(__F) ((__F)->_file)
> \MinGW\include\stdio.h:#define fileno(__F) ((__F)->_file)
>
> C:\windows\system32>
>
>
> It's part of the stdio.h ... canon, which, SFAIK well
> antedates and has no dependencies on posix.

The fileno() function is not defined by the ISO C standard.  It is
defined by POSIX.  It's declared in <stdio.h> for historical reasons
that probably predate the C and POSIX standards, but the C standard
committee chose not to standardize it (or any functions that work with
POSIX-style file descriptors).

(IMHO it would have been better if all POSIX-specific declarations
were separate headers not defined by ISO C.)

A conforming ISO C implementation may not unconditionally define the
fileno() function in <stdio.h>, since a strictly conforming program is
free to use that identifier for its own purposes.  A conforming POSIX
implementation must do so.  Which means that, in order to use
POSIX-specific functions, you have to invoke the compiler in a
non-ISO-C-conforming mode (perhaps by defining a macro and/or using a
particular command-line option).

>> and that finding the file
>> size on Linux and Windows were two different procedures.
>
> This should also not be.

And yet it is.

[...]

> Your original plan should be just fine. This is the way I have 
> determined file sizes since the 20th Century, modulo declariong
> and initializing things at the same time for some cruder toolchains:
>
> FILE *f = fopen(....);
>
> int rc = fseek(f,SEEK_END,0L);
> int len = ftell(f);
> rc = fseek(f,SEEK_SET,0L);
>
> after which, the file is nicely rewound and len contains the total 
> number of octets in the file.
>
> Obviously  for some file systems this may not work, but those are
> hard to find now.

As we've discussed here recently, the C standard does not guarantee
that that will work.  The value returned by ftell() is not guaranteed
to be meaningful, and neither fseek() nor ftell() is guaranteed to
work at all on all files.  On Windows, the size of a file generally
does not match the number of characters that can be read from it
in text mode.

POSIX systems have the stat() and fstat() functions, which will give
you the size of a file, among other information (I think they'll
typically report 0 for special files that don't have a size).
Windows has its own function(s) for doing the same kind of thing.
(And yes, those functions will usually give you the same result as
the fseek/ftell method.)

Any method for determining the size of a file can only tell you what
the size was when you checked it.  A file can grow, shrink, become
inaccessible, or cease to exist between the size determination and
a subsequent attempt to read it.  Which doesn't mean that trying
determine its size is useless, but code to access the file should
be robust in the presence of possible changes.  It's sensible to
use the apparent size as an *estimate* of how much memory you'll
need to store its contents.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web