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 3 of 6 — ← Prev page 1 2 [3] 4 5 6  Next page →

#395700

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>>Please use the term "null bytes", not "NULL bytes".  NULL is a standard
>>macro that expands to a null pointer constant.
>
> The proper term IMO is 'NUL' byte as defined by ASCII.

That's *a* proper term.  It's not the only one.

Both ASCII and EBCDIC use the term "NUL" for the character value
with all bits set to zero, but C doesn't assume either ASCII or
EBCDIC and doesn't use the name "NUL".  The standard uses the term
"null character", which is technically correct but might not be
ideal to refer to a byte in a file whose contents aren't intended
to represent characters.

I have no problem with the term "NUL", "NUL byte", or "NUL
character", but personally I tend to prefer "null byte", "zero byte",
or '\0'.

[...]

-- 
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]

#395703

On 12/6/2025 10:37 AM, Scott Lurndal wrote:
> <snip>

> Some older operating systems actually stored the file type in
> metadata (like the unix inode). The Burroughs MCP filesystems
> included a file-type field in the metadata for a file; the CANDE editor
> would use this to determine the programming language (and the associated
> language formatting rules a la COBOL or FORTRAN vis-a-vis column
> assignments for the sequence number, program verbs, etc.

The Burroughs file attribute name was "FILEKIND," and it took values 
like ALGOLSYMBOL (for an ALGOL source file) and ALGOLCODE (for an 
executable compiled with ALGOL). Other file attributes included maximum 
record length, character encoding (e.g. ASCII or EBCDIC), and lots more.

This brings back memories, most of them fond.

As far as I can tell, UNISYS MCP systems still have all that:

https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000064-520/86000064-520/chapter-000002094.html

Louis

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

#395704

Louis Krupp <lkrupp@invalid.pssw.com.invalid> writes:
>On 12/6/2025 10:37 AM, Scott Lurndal wrote:
>> <snip>
>
>> Some older operating systems actually stored the file type in
>> metadata (like the unix inode). The Burroughs MCP filesystems
>> included a file-type field in the metadata for a file; the CANDE editor
>> would use this to determine the programming language (and the associated
>> language formatting rules a la COBOL or FORTRAN vis-a-vis column
>> assignments for the sequence number, program verbs, etc.
>
>The Burroughs file attribute name was "FILEKIND," and it took values 
>like ALGOLSYMBOL (for an ALGOL source file) and ALGOLCODE (for an 
>executable compiled with ALGOL). Other file attributes included maximum 
>record length, character encoding (e.g. ASCII or EBCDIC), and lots more.
>
>This brings back memories, most of them fond.
>
>As far as I can tell, UNISYS MCP systems still have all that:
>
>https://public.support.unisys.com/aseries/docs/ClearPath-MCP-19.0/86000064-520/86000064-520/chapter-000002094.html
>

Yes the A-series (Large Systems) emulated systems still have
all that.

The V-series (long defunct) also supported a file kind attribute
for CANDE files.

--------------------------------------------------------------------------------
CAT
                                C A T A L O G
Usercode: 9895        Filetitle: ====qn on HOME    As of 12/07/25 08:35:22 Pg 01

gemcqn SYS     Record-size =   600  RPB =   1  Areas  0  EOF      716 LOCALSPO  
w15eqn SYS     Record-size =   160  RPB =  90  Areas  0  EOF      322 LURNDAL
AAAAqn BPL     09/28/89 10:18:13       5Rec(s)  Pub IO                9895
ADDMqn BPL     04/14/87 19:46:19      10Rec(s)  Pri IO                9895 
ADDUqn BPL     03/03/89 17:04:42      21Rec(s)  Pub IO                9895
ADSSqn BPL     06/28/89 14:15:24    7999Rec(s)  Pub IO                9895
AHWAqn SPRITE  10/09/89 17:53:23      23Rec(s)  Pub IO                9895
AIFAqn BPL     10/12/89 15:15:29       8Rec(s)  Pub IO                9895
AIVAqn BPL     10/20/89 16:21:33       4Rec(s)  Pub IO                9895
APBPqn BPL     01/11/89 18:05:38      92Rec(s)  Pub IO                9895
ARCVqn BPL     04/10/89 10:47:00     376Rec(s)  Grd IO                9895
BACKqn BPL     09/09/89 03:55:03     576Rec(s)  Pub IO                9895
BBBBqn SPRITE  01/25/89 12:47:45       1Rec(s)  Pub IO                9895
BFILqn BINDER  07/05/88 16:27:44       9Rec(s)  Pub IO                9895
BLESqn BPL     11/18/88 14:37:32      34Rec(s)  Pub IO                9895
BLOAqn BINDER  08/01/87 16:02:54      49Rec(s)  Pub IO                9895
BNAGqn DATA    02/08/88 15:07:06      41Rec(s)  Pub IO                9999
BNAUqn BPL     06/06/88 15:02:14     104Rec(s)  Pri IO                9895
BNAVqn DATA    03/03/89 16:15:00      58Rec(s)  Pri IO                9895
BSKLqn BPL     08/11/89 14:24:18     536Rec(s)  Pub IO                9895
Transmit space for next page..

BPL - Burroughs Programming Language (low-level systems programming)
SPRITE - Modula-like OS implementation language
BINDER - linker instructions.


(ADSSqn is the BPL source for the document formatting utility)

four-letter file names were a bit of a pain (the system had
six character names, but the last two characters for CANDE
stored the usercode (9895 in EBCDIC is 'qn').

I wrote the MCP system intialization code; the source file
was SINSqn, the printer banner name was SINEqn.  A colleague pointed
out that could be read as sine non qua which seemed quite
apropo for the system boot code :-).

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

#395989

On Sun, 7 Dec 2025 03:43:40 -0700, Louis Krupp wrote:

> This brings back memories, most of them fond.

Many former users of Burroughs systems seem to feel the same. ;)

I have an unflattering story about John McCarthy, the father of Lisp,
who was an IBM man who took over a computing centre where there was
a Burroughs machine ...

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

#395716

On Fri, 05 Dec 2025 17:42:30 -0800, Keith Thompson wrote:

> There is no completely reliable way to do this, but you might be
> able to make a reasonable guess.  A binary file might happen to
> contain only byte values that represent printable characters.

I suspected this was going to be the case actually.

> Please use the term "null bytes", not "NULL bytes".  NULL is a standard
> macro that expands to a null pointer constant.

Okay, will do.

> It seems odd to say that a file is assumed to be binary if you can't
> open it.  I suggest having the function return more than two distinct
> values:
> 
> - File seems to be binary
> - File seems to be text
> - Could be either
> - Something went wrong
> 
> An enum is probably a good choice.

Aye, that's an interesting way to look at it.

> 0x00 -> '\0'
> 0x20 -> ' '
> 0x09 -> '\t'
> 0x0A -> '\n'
> 0x0D -> '\r'

Well, I got too fancy there...

> Depending on how far you want to get into it, distinguishing between
> text and binary files is anywhere from difficult to literally
> impossible.

Thanks for your expertise Keith, I appreciate your insight.

-- 
:wq
Mike Sanders

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

#395690

On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
> Am I close? Missing anything you'd consider to be (or not) needed?
>
><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) {

[ ... ]

>     fclose(f);
>     return 0; // NOT binary
> }

How about:

int is_binary_file(const char *path)
{
  FILE *f = fopen(path);
  int yes = 0;

  if (f) {
    int ch;

    while ((ch == getc(f)) != EOF) {
      for (int i = 0; i < CHAR_BIT; i++, ch >>= 1) {
        switch ((ch & 1)) {
        case 0:
        case 1:
          break;
        default:
          goto out;
        }
      }
    }

    // TODO: distinguish feof/ferror
    yes = 1;
out:

    fclose(f);
  }

  return yes;
}

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#395692

On 06/12/2025 02:42, Kaz Kylheku wrote:
> On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
>> Am I close? Missing anything you'd consider to be (or not) needed?
>>
>> <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) {
> 
> [ ... ]
> 
>>      fclose(f);
>>      return 0; // NOT binary
>> }
> 
> How about:
> 
> int is_binary_file(const char *path)
> {
>    FILE *f = fopen(path);
>    int yes = 0;
> 
>    if (f) {
>      int ch;
> 
>      while ((ch == getc(f)) != EOF) {
>        for (int i = 0; i < CHAR_BIT; i++, ch >>= 1) {
>          switch ((ch & 1)) {
>          case 0:
>          case 1:
>            break;
>          default:

If this is suppposed to detect files which don't consist of binary 
characters (for example each ch has CHAR_BIT quaternary digits) then I 
don't believe this will detect that.

Assumung that 'ch & 1' is equivalent to 'ch % 2' in that case.

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

#395696

Kaz Kylheku <046-301-5902@kylheku.com> writes:
>On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
>> Am I close? Missing anything you'd consider to be (or not) needed?
>>
>><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) {
>
>[ ... ]
>
>>     fclose(f);
>>     return 0; // NOT binary
>> }
>
>How about:
>
>int is_binary_file(const char *path)
>{
>  FILE *f = fopen(path);
>
>  if (f) {

     while (isprint(getc(f)) {}
     return (!feof(f));

   }
   return 0;
 }

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

#395697

On Sat, 06 Dec 2025 17:40:18 +0000, Scott Lurndal wrote:

> Kaz Kylheku <046-301-5902@kylheku.com> writes:
>>On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
>>> Am I close? Missing anything you'd consider to be (or not) needed?
>>>
>>><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) {
>>
>>[ ... ]
>>
>>>     fclose(f);
>>>     return 0; // NOT binary
>>> }
>>
>>How about:
>>
>>int is_binary_file(const char *path)
>>{
>>  FILE *f = fopen(path);
>>
>>  if (f) {
> 
>      while (isprint(getc(f)) {}

The isprint function tests for any member of a locale-specific
set of characters (each of which occupies one printing position
on a display device) including space (' ').

It effectively evaluates whether or not a given value is a
"printing character" in the execution characterset, not whether
or not a given value (from an outside file) is a text character.

I'd use this function cautiously, as it will produce false
results when the characterset of the source data is not the the
execution characterset (think a Unicode UTF16 encoded text
file, and an ASCII execution characterset).

>      return (!feof(f));
> 
>    }
>    return 0;
>  }




-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

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

#395698

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>On Sat, 06 Dec 2025 17:40:18 +0000, Scott Lurndal wrote:
>
>> Kaz Kylheku <046-301-5902@kylheku.com> writes:
>>>On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
>>>> Am I close? Missing anything you'd consider to be (or not) needed?
>>>>
>>>><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) {
>>>
>>>[ ... ]
>>>
>>>>     fclose(f);
>>>>     return 0; // NOT binary
>>>> }
>>>
>>>How about:
>>>
>>>int is_binary_file(const char *path)
>>>{
>>>  FILE *f = fopen(path);
>>>
>>>  if (f) {
>> 
>>      while (isprint(getc(f)) {}
>
>The isprint function tests for any member of a locale-specific
>set of characters (each of which occupies one printing position
>on a display device) including space (' ').
>
>It effectively evaluates whether or not a given value is a
>"printing character" in the execution characterset, not whether
>or not a given value (from an outside file) is a text character.

What is your definition of a "text" character?

>
>I'd use this function cautiously, as it will produce false
>results when the characterset of the source data is not the the
>execution characterset (think a Unicode UTF16 encoded text
>file, and an ASCII execution characterset).
>
>>      return (!feof(f));
>> 
>>    }
>>    return 0;
>>  }
>
>
>
>
>-- 
>Lew Pitcher
>"In Skills We Trust"
>Not LLM output - I'm just like this.

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

#395699

On Sat, 06 Dec 2025 19:06:14 +0000, Scott Lurndal wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>On Sat, 06 Dec 2025 17:40:18 +0000, Scott Lurndal wrote:
>>
>>> Kaz Kylheku <046-301-5902@kylheku.com> writes:
>>>>On 2025-12-06, Michael Sanders <porkchop@invalid.foo> wrote:
>>>>> Am I close? Missing anything you'd consider to be (or not) needed?
>>>>>
>>>>><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) {
>>>>
>>>>[ ... ]
>>>>
>>>>>     fclose(f);
>>>>>     return 0; // NOT binary
>>>>> }
>>>>
>>>>How about:
>>>>
>>>>int is_binary_file(const char *path)
>>>>{
>>>>  FILE *f = fopen(path);
>>>>
>>>>  if (f) {
>>> 
>>>      while (isprint(getc(f)) {}
>>
>>The isprint function tests for any member of a locale-specific
>>set of characters (each of which occupies one printing position
>>on a display device) including space (' ').
>>
>>It effectively evaluates whether or not a given value is a
>>"printing character" in the execution characterset, not whether
>>or not a given value (from an outside file) is a text character.
> 
> What is your definition of a "text" character?

I have none, for this case. However, the OP /might/ have one, given
that his code was an attempt to discern "text" files from "binary"
files.

>>
>>I'd use this function cautiously, as it will produce false
>>results when the characterset of the source data is not the the
>>execution characterset (think a Unicode UTF16 encoded text
>>file, and an ASCII execution characterset).
>>
>>>      return (!feof(f));
>>> 
>>>    }
>>>    return 0;
>>>  }

-- 
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.

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

#395717

On Sat, 6 Dec 2025 02:42:39 -0000 (UTC), Kaz Kylheku wrote:

> How about:
> 
> [...]

You sir are an OCD coder =)

-- 
:wq
Mike Sanders

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

#395725

On 2025-12-08, Michael Sanders <porkchop@invalid.foo> wrote:
> On Sat, 6 Dec 2025 02:42:39 -0000 (UTC), Kaz Kylheku wrote:
>
>> How about:
>> 
>> [...]
>
> You sir are an OCD coder =)

At last, someone seems to have gotten the joke.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

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

#395727

On 08/12/2025 19:26, Kaz Kylheku wrote:
> On 2025-12-08, Michael Sanders <porkchop@invalid.foo> wrote:
>> On Sat, 6 Dec 2025 02:42:39 -0000 (UTC), Kaz Kylheku wrote:
>>
>>> How about:
>>>
>>> [...]
>>
>> You sir are an OCD coder =)
> 
> At last, someone seems to have gotten the joke.

An OCD coder would have remembered that fopen takes two 
parameters. :-o

-- 
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]

#395746

On Mon, 8 Dec 2025 19:26:07 -0000 (UTC), Kaz Kylheku wrote:

> At last, someone seems to have gotten the joke.

I had originally intended to reply (without the hints):

c: 01100011
h: 01101000
u: 01110101
c: 01100011
k: 01101011
l: 01101100
e: 01100101

But figured it could lead to a shellacking...

-- 
:wq
Mike Sanders

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

#395691

On Fri, 12/5/2025 8:05 PM, Michael Sanders wrote:
> Am I close? Missing anything you'd consider to be (or not) needed?
> 
> <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
> }
> 

It is the year 2025.

How many times do you suppose someone has considered this question ?

I'm not trying to be a smart ass by saying this, just that the
question is bound to be nuanced. You can do a fast and totally
inaccurate determination. You can do a computationally expensive
or I/O expensive determination.

There has to be a reason for doing this, and a damn good reason.

*******

There is the "file" command.

It was invented in 1973.

   https://en.wikipedia.org/wiki/File_%28command%29

The beauty of this command, is it has some sort of ordered
approach to file determination.

Originally, as I understand it (I don't see it in the Wiki), it
was not supposed to read more than 1024 bytes of the file. This
was because the command was intended to settle file determinations
for "ordered types". For example, an MSWord doc, might have four
unique bytes near the beginning of the file. The designers felt
they could quickly "sort" or "determine" what kind of highly
stylized file they were dealing with.

But the results I got one day a couple years ago, suggests
they have strayed from that. I got around 100 different text
file declarations. For example, a text file with a binary block
in it as a "corruption", it is declared as a text file, but
the word "ISO something or other" is part of the file type
determination. Thus, when I see a certain file on my computer
is no longer a plain text file, but contains the word ISO,
then I must scroll through it with a hex editor and see what
the hell has triggered this determination.

The experience suggested the entire text file was being read.
I did not craft any tests to see if that was true.

Some file types receive very little differentiation. There is
only the one detection for them, the detection offers no help
for technical people.

That's an exemplar of a still-supported effort to identify files.
The "file" command. It does not rely upon, or use, the extension.

And those people are wizards. You can't expect to just read their
source and make some instant discovery. Sometimes, when someone
asks for a new detection, the wizards know of some dependencies
in the detection tree that prevent the craftsmanship necessary.
Mere mortals need not apply while this is going on.

To find 100 different text file types, I un-tarred the Firefox
source tarball and scanned it, then used AWK to total the
various detections and print them out. I only used the AWK
code, after being shocked to find what a shithole the tarball was.
I had originally intended to run UNIX2DOS over the thing, but
that was entirely out of the question when the detections
came in. In fact, there is just one source file in the Firefox
tree, that you MUST NOT alter. It breaks the build, if you do
ANYTHING to it. Good times. I could not figure out why gcc
had such a problem with the file. Could not root cause it.

*******

As a little example, I will scan the Sent file of my News Client,
which I happen to know is corrupted, but I haven't bothered to
fix it yet. And how I detected the corruption in the first place,
was by running this!

$ File Sent
Sent:        Non-ISO extended-ASCII text, with very long lines, with CRLF, NEL line terminators

That is a corrupt one.

$ File Trash
Trash:       ASCII text, with CRLF line terminators

That is not corrupt.

$ dd if=/dev/urandom of=big.bin bs=1048576 count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 7.44362 s, 144 MB/s

$ file big.bin
big.bin: data    <=== Not definitive, as even trivially distorted files do this.
                      This file just happens to be "perfectly undetectable".

A file full of zeros, is also "data". There is no special detection for it.

   Paul

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

#395718

On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote:

> It is the year 2025.
> 
> How many times do you suppose someone has considered this question ?
> 
> I'm not trying to be a smart ass by saying this, just that the
> question is bound to be nuanced. You can do a fast and totally
> inaccurate determination. You can do a computationally expensive
> or I/O expensive determination.

I get it Paul, but as with all things, there's lots of opinions on this.

> There has to be a reason for doing this, and a damn good reason.
> 
> *******
> 
> There is the "file" command.
> 
> It was invented in 1973.
> 
>    https://en.wikipedia.org/wiki/File_%28command%29
> 
> The beauty of this command, is it has some sort of ordered
> approach to file determination.

And... is not generally available on Windows & causes a 3rd party
dependency. Not to say that you're not correct in your thinking
but I want portability. And there are lots of things I want that
dont always happen either...

> [...]

Thanks Paul, actually I do appreciate your rant & the detailed examples
you cite. I'm in the same place with my project, it can be very frustrating.

-- 
:wq
Mike Sanders

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

#395729

Michael Sanders <porkchop@invalid.foo> writes:
>On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote:
>
>> It is the year 2025.
>> 
>> How many times do you suppose someone has considered this question ?
>> 
>> I'm not trying to be a smart ass by saying this, just that the
>> question is bound to be nuanced. You can do a fast and totally
>> inaccurate determination. You can do a computationally expensive
>> or I/O expensive determination.
>
>I get it Paul, but as with all things, there's lots of opinions on this.
>
>> There has to be a reason for doing this, and a damn good reason.
>> 
>> *******
>> 
>> There is the "file" command.
>> 
>> It was invented in 1973.
>> 
>>    https://en.wikipedia.org/wiki/File_%28command%29
>> 
>> The beauty of this command, is it has some sort of ordered
>> approach to file determination.
>
>And... is not generally available on Windows 

It is open source and could be built for windows.

It's also included in any linux distribution running
under WSL.

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

#395731

On 08/12/2025 21:16, Scott Lurndal wrote:
> Michael Sanders <porkchop@invalid.foo> writes:
>> On Sat, 6 Dec 2025 03:14:55 -0500, Paul wrote:
>>
>>> It is the year 2025.
>>>
>>> How many times do you suppose someone has considered this question ?
>>>
>>> I'm not trying to be a smart ass by saying this, just that the
>>> question is bound to be nuanced. You can do a fast and totally
>>> inaccurate determination. You can do a computationally expensive
>>> or I/O expensive determination.
>>
>> I get it Paul, but as with all things, there's lots of opinions on this.
>>
>>> There has to be a reason for doing this, and a damn good reason.
>>>
>>> *******
>>>
>>> There is the "file" command.
>>>
>>> It was invented in 1973.
>>>
>>>     https://en.wikipedia.org/wiki/File_%28command%29
>>>
>>> The beauty of this command, is it has some sort of ordered
>>> approach to file determination.
>>
>> And... is not generally available on Windows
> 
> It is open source and could be built for windows.
> 
> It's also included in any linux distribution running
> under WSL.
> 

It is available anywhere you find Windows ports of common *nix 
utilities, such as the msys2 project.  (And while an msys2 installation 
can be quite large, it's possible to pull out individual utilities if 
you need to.)  Still, it's fair to say that most Windows installations 
don't have it.

But surely on Windows you can just look at the file extension - if it is 
".txt", it's a text file, otherwise it's a binary file.

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

#395732

On 09/12/2025 08:03, David Brown wrote:

<snip>

> But surely on Windows you can just look at the file extension - 
> if it is ".txt", it's a text file, otherwise it's a binary file.

It is now almost a decade since I last made (approximately 
weekly) use of a Windows system. For the 25 years prior to that I 
used a variety of extensions for text filenames, including:

txt - generic textfile
doc - documentation*
c   - C source
cpp - C++ source
h   - C or C++ header
tex - LaTeX source
ly  - Lilypond source
eml - email backup
cfg - configuration files
ini - initialisation files
     - Makefiles and READMEs
sh  - shell script
asm - assembly language source
i   - C preprocessor output
bin - binary (contains only '0', '1', and '\n') - I found less 
than a dozen of these, but there they were.

These are, of course, all also binary files. Whether a file that 
contains only printable characters is text or binary is really a 
matter of perspective more than anything else.

-- 
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]

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

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

csiph-web