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

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

is_binary_file()

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

Contents

  is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-06 01:05 +0000
    Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 01:41 +0000
      Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 02:00 +0000
        Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:40 +0000
        Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:35 +0000
          Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 15:07 +0000
            Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-10 19:00 +0200
              Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 17:18 +0000
                Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-10 19:42 +0000
                  Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-10 22:37 +0000
                    Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-10 22:35 -0500
                      Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-11 11:46 +0000
                        Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-11 12:53 +0100
            Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:42 +0000
          Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-10 15:58 +0000
            Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:44 +0000
          Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-10 12:46 -0500
            Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:45 +0000
          Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 18:41 +0000
            Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 20:57 +0000
              Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-10 22:07 +0000
                Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-11 01:09 +0000
                  Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-11 12:33 +0000
                    Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-12 19:25 +0000
                      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-12 22:54 +0000
                        Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-12 15:33 -0800
                          Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-13 00:20 +0000
                            Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-13 02:32 +0000
                          Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-16 00:26 +0000
                            Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-16 17:24 +0100
                              Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-17 03:19 +0000
                                Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-17 07:57 +0100
                                  Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-17 19:35 +0000
                                    Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 08:44 +0100
                                      Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-18 12:49 +0000
                                        Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 14:06 +0100
                                          Re: is_binary_file() gazelle@shell.xmission.com (Kenny McCormack) - 2025-12-18 13:17 +0000
                                            Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-18 16:03 +0100
    Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-05 17:42 -0800
      Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:37 +0000
        Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-06 16:05 -0800
        Re: is_binary_file() Louis Krupp <lkrupp@invalid.pssw.com.invalid> - 2025-12-07 03:43 -0700
          Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-07 16:47 +0000
          Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 03:18 +0000
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:46 +0000
    Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-06 02:42 +0000
      Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-06 12:42 +0000
      Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:40 +0000
        Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 18:04 +0000
          Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 19:06 +0000
            Re: is_binary_file() Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2025-12-06 21:16 +0000
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:48 +0000
        Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-08 19:26 +0000
          Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-08 19:42 +0000
          Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 21:49 +0000
    Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-06 03:14 -0500
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 17:56 +0000
        Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 20:16 +0000
          Re: is_binary_file() David Brown <david.brown@hesbynett.no> - 2025-12-09 09:03 +0100
            Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-09 09:43 +0000
              Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-09 10:17 +0000
                Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-09 20:15 +0000
            Re: is_binary_file() tTh <tth@none.invalid> - 2025-12-09 12:22 +0100
              Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-09 20:26 -0500
            Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-09 06:38 -0500
              Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-09 17:31 +0200
              Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 02:49 +0000
      Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-28 00:12 +0000
        Re: is_binary_file() richard@cogsci.ed.ac.uk (Richard Tobin) - 2025-12-28 00:43 +0000
    Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-06 17:33 +0000
      Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-07 19:04 +0100
    Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-06 20:37 -0500
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:02 +0000
      Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-09 16:29 -0500
        Re: is_binary_file() Michael S <already5chosen@yahoo.com> - 2025-12-10 11:21 +0200
          Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-10 12:48 -0500
        Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:38 +0000
    Re: is_binary_file() antispam@fricas.org (Waldek Hebisch) - 2025-12-07 03:43 +0000
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:04 +0000
        Re: is_binary_file() bart <bc@freeuk.com> - 2025-12-08 18:44 +0000
          Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 19:53 +0000
            Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-09 15:42 -0800
              Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 11:41 +0000
                Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-10 15:20 -0800
                  Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-10 23:59 +0000
          Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-09 16:23 -0500
    Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-07 19:01 +0000
      Re: is_binary_file() Richard Heathfield <rjh@cpax.org.uk> - 2025-12-07 21:51 +0000
        Re: is_binary_file() Richard Harnden <richard.nospam@gmail.invalid> - 2025-12-07 22:49 +0000
        Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 13:51 +0100
          Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 16:04 +0000
            Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 19:27 +0100
          Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 05:51 +0000
            Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-29 16:06 +0100
              Re: is_binary_file() mjos_examine <m6502x64@gmail.com> - 2025-12-29 11:49 -0500
                Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-29 20:49 +0100
              Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-30 01:52 +0000
        Re: is_binary_file() scott@slp53.sl.home (Scott Lurndal) - 2025-12-08 16:02 +0000
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:07 +0000
      Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 03:13 +0000
        Re: is_binary_file() Paul <nospam@needed.invalid> - 2025-12-27 01:28 -0500
          Re: is_binary_file() Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-12-27 21:27 +0000
          Re: is_binary_file() antispam@fricas.org (Waldek Hebisch) - 2025-12-28 05:46 +0000
    Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-07 14:42 -0800
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-08 18:09 +0000
        Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-09 12:45 -0800
    Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 20:36 +0100
      Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-08 20:50 +0100
        Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-09 15:09 +0100
      Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-10 09:18 +0100
    Re: is_binary_file() Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-12-08 14:43 -0800
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-09 21:38 +0000
    Re: is_binary_file() Kaz Kylheku <046-301-5902@kylheku.com> - 2025-12-11 17:33 +0000
      Re: is_binary_file() Bonita Montero <Bonita.Montero@gmail.com> - 2025-12-11 19:10 +0100
      Re: is_binary_file() "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-12-11 14:56 -0800
      Re: is_binary_file() James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-12-11 18:15 -0500
      Re: is_binary_file() Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-12-12 02:19 +0100
      Re: is_binary_file() Michael Sanders <porkchop@invalid.foo> - 2025-12-14 08:27 +0000
      Re: is_binary_file() Lynn McGuire <lynnmcguire5@gmail.com> - 2025-12-17 00:52 -0600

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

#395739

On Mon, 8 Dec 2025 18:44:33 +0000, bart wrote:

> It's not clear what the actual problem is. What is the use-case for a 
> function that tells you whether any file /might/ be a text-file based on 
> speculative analysis of its contents?
> 
> Is the result /meant/ to be fuzzy?

Hey bart.

What I mean is that since I have not yet defined a canonical standard
for my program, the goal here (to determine if my code can parse the file)
is unclear.

It means I need to plan much more *before* I write more code, no mean feat
when one is excited & ready to jump in =)

-- 
:wq
Mike Sanders

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

#395747

Michael Sanders <porkchop@invalid.foo> writes:
> On Mon, 8 Dec 2025 18:44:33 +0000, bart wrote: 
>> It's not clear what the actual problem is. What is the use-case 
>> for a  function that tells you whether any file /might/ be a 
>> text-file based on  speculative analysis of its contents?   Is 
>> the result /meant/ to be fuzzy? 
> 
> Hey bart. 
> 
> What I mean is that since I have not yet defined a canonical 
> standard for my program, the goal here (to determine if my code 
> can parse the file) is unclear. 
> 
> It means I need to plan much more *before* I write more code, no 
> mean feat when one is excited & ready to jump in =) 
 
You say you want to parse the file.  That implies that you expect 
the file to have a certain format/syntax, and for parsing to fail 
on a file that doesn't satisfy the syntax.   In that case, I 
speculate that determining whether the file is text or binary is 
not useful.  The way to determine whether you can parse it is 
simply to try to parse it, and see whether that succeeds or fails. 
For example, if I want to parse a file containing a C translation 
unit, I can feed it to a C compiler (or just a parser if I have 
one).  If the file contains non-text bytes, that's just a special 
case of a syntactically incorrect input, and the parser will 
detect it.  It should work similarly for whatever format you're 
trying to parse.  I doubt that you need to distinguish between 
incorrect input that's pure text and incorrect input that's 
"binary".   If I'm right about this (which is by no means 
certain), you could have saved a lot of time by telling us up 
front *why* you want to distinguish between "text" and "binary" 
files.   On the other hand, I've seized on the word "parse", and I 
may be reading too much into it. 

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#395758

On Tue, 09 Dec 2025 15:42:59 -0800, Keith Thompson wrote:

> [...]

Keith if you get a chance see my reply to Lew 'is_text_file()'

Let me know if I've inched closer a step or two...

-- 
:wq
Mike Sanders

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

#395776

Michael Sanders <porkchop@invalid.foo> writes:
> On Tue, 09 Dec 2025 15:42:59 -0800, Keith Thompson wrote: 
> 
>> [...] 
> 
> Keith if you get a chance see my reply to Lew 'is_text_file()' 
> 
> Let me know if I've inched closer a step or two...

Closer to what exactly?

In the parent article, I suggested that you likely don't need to 
determine whether a file is "text" or "binary".  You said you want 
to parse a file.  An attempt to parse it will fail either if the 
input is binary or if it's text that doesn't match the grammar you 
require.   For example, a parser for C source code doesn't need to 
check whether the input is binary or text.  Certain input 
characters will simply cause the parse to fail, and a syntax error 
can be reported.   Tell us more about how you want to parse files. 
Are you parsing according to a formal grammar?  Or is it more 
ad-hoc? 

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

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

#395778

On Wed, 10 Dec 2025 15:20:19 -0800, Keith Thompson wrote:

> Michael Sanders <porkchop@invalid.foo> writes:
>> On Tue, 09 Dec 2025 15:42:59 -0800, Keith Thompson wrote: 
>> 
>>> [...] 
>> 
>> Keith if you get a chance see my reply to Lew 'is_text_file()' 
>> 
>> Let me know if I've inched closer a step or two...
> 
> Closer to what exactly?
> 
> In the parent article, I suggested that you likely don't need to 
> determine whether a file is "text" or "binary".  You said you want 
> to parse a file.  An attempt to parse it will fail either if the 
> input is binary or if it's text that doesn't match the grammar you 
> require.   For example, a parser for C source code doesn't need to 
> check whether the input is binary or text.  Certain input 
> characters will simply cause the parse to fail, and a syntax error 
> can be reported.   Tell us more about how you want to parse files. 
> Are you parsing according to a formal grammar?  Or is it more 
> ad-hoc?

Yes I'm parsing a formal grammar (but a *really* small one).

Yes I can parse binary/text just fine as you guessed.

The matter at hand:

I wanted to build a stand alone function that makes a solid guess as
to whether a file would be considered an average text file or not.

That's all...

I've solved the issue to my satisfaction.

-- 
:wq
Mike Sanders

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

#395743

On Mon, 8 Dec 2025 18:44:33 +0000, bart wrote:

> It's not clear what the actual problem is. What is the use-case for a 
> function that tells you whether any file /might/ be a text-file based on 
> speculative analysis of its contents?
> 
> Is the result /meant/ to be fuzzy?
The fundamental problem is that no analysis of the contents can give you
anything other than a fuzzy result. There's nothing more clearly a
binary file than one that contains an array of binary floating point
numbers. However, just by chance, the binary numbers it contains could
happen to be such that every byte of that file can be interpreted as a
text character. How could an analysis of only the file tell you, with
certainty, that it wasn't a text file?

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

#395707

On 06/12/2025 01:05, Michael Sanders wrote:
> Am I close? Missing anything you'd consider to be (or not) needed?

A text file is supposed to end with a '\n' (M$, of course, largely 
ignores this convention), but a quick test could be:

         f = fopen(path, "rb");

         fseek(f, -1, SEEK_END);

         if ( (c = fgetc(f)) == '\n' )
             printf("Text\n");
         else
             printf("Binary\n");

         fclose(f);

Be aware of false positives/negatives, because I'm sure there will be 
plenty :)


> 
> <stdio.h>
> 
> /*
>   * Checks if a file is likely a binary by examining its content
>   * for NULL bytes (0x00) or unusual control characters.
>   * Returns 0 if text, 1 if binary or file open failure.
>   */
> 
> int is_binary_file(const char *path) {
>      FILE *f = fopen(path, "rb");
>      if (!f) return 1; // cannot open file, treat as error/fail check
> 
>      unsigned char buf[65536];
>      size_t n, i;
> 
>      while ((n = fread(buf, 1, sizeof(buf), f)) > 0) {
>          for (i = 0; i < n; i++) {
>              unsigned char c = buf[i];
> 
>              // 1. check for the NULL byte (strong indicator of binary data)
>              if (c == 0x00) {
>                  fclose(f);
>                  return 1; // IS binary
>              }
> 
>              // 2. check for C0 control codes (0x01-0x1F), excluding known
>              // text formatting characters: 0x09 (Tab), 0x0A (LF), 0x0D (CR)
>              if (c < 0x20) {
>                  if (c != 0x09 && c != 0x0A && c != 0x0D) {
>                      fclose(f);
>                      return 1; // IS binary (contains unexpected control code)
>                  }
>              }
>          }
>      }
> 
>      fclose(f);
>      return 0; // NOT binary
> }
> 

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

#395709

On 07/12/2025 19:01, Richard Harnden wrote:
> On 06/12/2025 01:05, Michael Sanders wrote:
>> Am I close? Missing anything you'd consider to be (or not)
>> needed?
> 
> A text file is supposed to end with a '\n' (M$, of course, 
> largely ignores this convention), but a quick test could be:
> 
> f = fopen(path, "rb");
> 
> fseek(f, -1, SEEK_END);

Not guaranteed to work with binary files...

7.19.9.2(3)

A binary stream need not meaningfully support fseek calls with a 
whence value of SEEK_END.

...or text files.

7.19.9.2(4)

For a text stream, either offset shall be zero, or offset shall
be a value returned by an earlier successful call to the ftell 
function on a stream associated with the same file and whence 
shall be SEEK_SET.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#395711

On 07/12/2025 21:51, Richard Heathfield wrote:
> On 07/12/2025 19:01, Richard Harnden wrote:
>> On 06/12/2025 01:05, Michael Sanders wrote:
>>> Am I close? Missing anything you'd consider to be (or not)
>>> needed?
>>
>> A text file is supposed to end with a '\n' (M$, of course, largely 
>> ignores this convention), but a quick test could be:
>>
>> f = fopen(path, "rb");
>>
>> fseek(f, -1, SEEK_END);
> 
> Not guaranteed to work with binary files...
> 
> 7.19.9.2(3)
> 
> A binary stream need not meaningfully support fseek calls with a whence 
> value of SEEK_END.
> 
> ...or text files.
> 
> 7.19.9.2(4)
> 
> For a text stream, either offset shall be zero, or offset shall
> be a value returned by an earlier successful call to the ftell function 
> on a stream associated with the same file and whence shall be SEEK_SET.
> 

Ah, okay.  Thanks.

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

#395712

Am 07.12.2025 um 22:51 schrieb Richard Heathfield:
> On 07/12/2025 19:01, Richard Harnden wrote:
>> On 06/12/2025 01:05, Michael Sanders wrote:
>>> Am I close? Missing anything you'd consider to be (or not)
>>> needed?
>>
>> A text file is supposed to end with a '\n' (M$, of course, largely 
>> ignores this convention), but a quick test could be:
>>
>> f = fopen(path, "rb");
>>
>> fseek(f, -1, SEEK_END);
>
> Not guaranteed to work with binary files...
>
> 7.19.9.2(3)
>
> A binary stream need not meaningfully support fseek calls with a 
> whence value of SEEK_END.

 From the glibc Reference Manual:

“The distinction between text and binary streams is only meaningful on 
systems where text files
have a different internal representation. On Unix systems, there is no 
difference between the
two; the ‘b’ is accepted but ignored.”


>
> ...or text files.
>
> 7.19.9.2(4)
>
> For a text stream, either offset shall be zero, or offset shall
> be a value returned by an earlier successful call to the ftell 
> function on a stream associated with the same file and whence shall be 
> SEEK_SET.
>

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

#395714

Bonita Montero <Bonita.Montero@gmail.com> writes:
>Am 07.12.2025 um 22:51 schrieb Richard Heathfield:
>> On 07/12/2025 19:01, Richard Harnden wrote:
>>> On 06/12/2025 01:05, Michael Sanders wrote:
>>>> Am I close? Missing anything you'd consider to be (or not)
>>>> needed?
>>>
>>> A text file is supposed to end with a '\n' (M$, of course, largely 
>>> ignores this convention), but a quick test could be:
>>>
>>> f = fopen(path, "rb");
>>>
>>> fseek(f, -1, SEEK_END);
>>
>> Not guaranteed to work with binary files...
>>
>> 7.19.9.2(3)
>>
>> A binary stream need not meaningfully support fseek calls with a 
>> whence value of SEEK_END.
>
> From the glibc Reference Manual:

Has nothing to do with glibc.  Dates back to the earliest
days of unix,  and is codified by POSIX/SUS.

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

#395723

Am 08.12.2025 um 17:04 schrieb Scott Lurndal:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>> Am 07.12.2025 um 22:51 schrieb Richard Heathfield:
>>> On 07/12/2025 19:01, Richard Harnden wrote:
>>>> On 06/12/2025 01:05, Michael Sanders wrote:
>>>>> Am I close? Missing anything you'd consider to be (or not)
>>>>> needed?
>>>> A text file is supposed to end with a '\n' (M$, of course, largely
>>>> ignores this convention), but a quick test could be:
>>>>
>>>> f = fopen(path, "rb");
>>>>
>>>> fseek(f, -1, SEEK_END);
>>> Not guaranteed to work with binary files...
>>>
>>> 7.19.9.2(3)
>>>
>>> A binary stream need not meaningfully support fseek calls with a
>>> whence value of SEEK_END.
>>  From the glibc Reference Manual:
> Has nothing to do with glibc.  Dates back to the earliest
> days of unix,  and is codified by POSIX/SUS.

Where did I say that this is tue for glibc only ?

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

#395990

On Mon, 8 Dec 2025 13:51:49 +0100, Bonita Montero wrote:

> From the glibc Reference Manual:
>
> “The distinction between text and binary streams is only meaningful
> on systems where text files have a different internal
> representation. On Unix systems, there is no difference between the
> two; the ‘b’ is accepted but ignored.”

However, you need to distinguish the two if you want, like Python
does, to be able to have a “universal newline” mode, where you can
correctly handle line breaks in files written on any of the three main
platform families: *nix/Unix, Windows, and macOS.

This is such a useful idea I’m surprised no one has suggested that C
should offer the option.

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

#396009

Am 27.12.2025 um 06:51 schrieb Lawrence D’Oliveiro:
> On Mon, 8 Dec 2025 13:51:49 +0100, Bonita Montero wrote:
>
>>  From the glibc Reference Manual:
>>
>> “The distinction between text and binary streams is only meaningful
>> on systems where text files have a different internal
>> representation. On Unix systems, there is no difference between the
>> two; the ‘b’ is accepted but ignored.”
> However, you need to distinguish the two if you want, like Python
> does, to be able to have a “universal newline” mode, where you can
> correctly handle line breaks in files written on any of the three main
> platform families: *nix/Unix, Windows, and macOS.
No, MacOS, not macOS; the latter is "MacOS" since macOS X.
> This is such a useful idea I’m surprised no one has suggested that C
> should offer the option.

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

#396010

On 2025-12-29 10:06 a.m., Bonita Montero wrote:
>> However, you need to distinguish the two if you want, like Python
>> does, to be able to have a “universal newline” mode, where you can
>> correctly handle line breaks in files written on any of the three main
>> platform families: *nix/Unix, Windows, and macOS.
> No, MacOS, not macOS; the latter is "MacOS" since macOS X.

Your assertion is contrary to that operating system vendor's own stance 
and branding.
https://www.apple.com/os/macos/

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

#396011

Am 29.12.2025 um 17:49 schrieb mjos_examine:
> Your assertion is contrary to that operating system vendor's own 
> stance and branding.
> https://www.apple.com/os/macos

There's nothing about the distinction between MacOS and macOS on this page.

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

#396015

On Mon, 29 Dec 2025 16:06:50 +0100, Bonita Montero wrote:

> Am 27.12.2025 um 06:51 schrieb Lawrence D’Oliveiro:
>>
>> On Mon, 8 Dec 2025 13:51:49 +0100, Bonita Montero wrote:
>>
>>>  From the glibc Reference Manual:
>>>
>>> “The distinction between text and binary streams is only
>>> meaningful on systems where text files have a different internal
>>> representation. On Unix systems, there is no difference between
>>> the two; the ‘b’ is accepted but ignored.”
>>
>> However, you need to distinguish the two if you want, like Python
>> does, to be able to have a “universal newline” mode, where you can
>> correctly handle line breaks in files written on any of the three main
>> platform families: *nix/Unix, Windows, and macOS.
>>
>> This is such a useful idea I’m surprised no one has suggested that C
>> should offer the option.

Way to distract from my point!

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

#395713

Richard Heathfield <rjh@cpax.org.uk> writes:
>On 07/12/2025 19:01, Richard Harnden wrote:
>> On 06/12/2025 01:05, Michael Sanders wrote:
>>> Am I close? Missing anything you'd consider to be (or not)
>>> needed?
>> 
>> A text file is supposed to end with a '\n' (M$, of course, 
>> largely ignores this convention), but a quick test could be:
>> 
>> f = fopen(path, "rb");
>> 
>> fseek(f, -1, SEEK_END);
>
>Not guaranteed to work with binary files...
>
>7.19.9.2(3)
>
>A binary stream need not meaningfully support fseek calls with a 
>whence value of SEEK_END.

Not to mention that the ASCII LF character _is_ a valid binary
character, so the presence or absence of an LF as the last byte of a file
doesn't indicate anything useful.

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

#395721

On Sun, 7 Dec 2025 19:01:02 +0000, Richard Harnden wrote:

> A text file is supposed to end with a '\n' (M$, of course, largely 
> ignores this convention), but a quick test could be:
> 
>          f = fopen(path, "rb");
> 
>          fseek(f, -1, SEEK_END);
> 
>          if ( (c = fgetc(f)) == '\n' )
>              printf("Text\n");
>          else
>              printf("Binary\n");
> 
>          fclose(f);
> 
> Be aware of false positives/negatives, because I'm sure there will be 
> plenty :)

Thank you Richard. Interesting thoughts.


-- 
:wq
Mike Sanders

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

#395988

On Sun, 7 Dec 2025 19:01:02 +0000, Richard Harnden wrote:

> A text file is supposed to end with a '\n'

PDF files end with that. The object index comes at the end, and each
index entry is fixed in length and ends with \015\012.

But the spec makes it very clear that PDF files are not supposed to be
treated as text files.

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

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

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

csiph-web