Why is the text file created with this code having a charset == binary?

Question

In the below code I'm creating two files one in text format and other in binary format. The icons of the files show the same. But the characteristics of both the files are exactly same including the size ,charset (==binary) and stream(octet). Why isn't there a text file? Because if i create a text file explicitly the charset is ASCII.

Compiler version - gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0.

Operating system - Tried on both Ubuntu 18.10 and 19.04.

No messages displayed by compiler.

Command used to examine the files file --mime.

Output by the command for file Text1.txt : Text1.txt: application/octet-stream; charset=binary

Output by the command for file Text1.txt : Binary: application/octet-stream; charset=binary

Output by command od -xa FILENAME is same for both files and is :

0000000 0021
! 0000001

#include<stdio.h>
void main(){

FILE *fp;
FILE *fp2;
int a = 10111110;

fp2 = fopen("Text1.txt","w");
fputc('!',fp2);

fp = fopen("Binary","wb");
fputc('!',fp);

}

Expected output is One File with charset as ASCII and One with Binary, Actual output is both of them with charset as Binary

Answer 1

The file command diagnoses the files as binary and not ASCII because you are writing non-ASCII characters to the files due to incorrect use of fputc.

fputc("!",fp2); is incorrect. The first argument to fputc should be an int with a character value. "!" is a string literal, which is an array, which is automatically converted to a pointer to its first character.

GCC warns you about this, saying “warning: passing argument 1 of 'fputc' makes integer from pointer without a cast [-Wint-conversion]”. You apparently ignored the warning. Do not do that. When the compiler warns you about something, pay attention, diagnose the problem, and fix it.

The result is that the pointer is converted to an int, and this int is passed to fputc. That may result in some non-ASCII character being written to the file, which in turn causes the file command to diagnose the file as binary.

To fix this, change the string "!" to a single character '!', so that you pass a single character to fputc, with fputc('!',fp2);.

Additionally, main should not be declared with void main(). Declare it with int main(void) or int main(int argc, char *argv[]) or another implementation-defined manner.

On Unix systems, the resulting files with the corrected code will be identical. Core Unix does not distinguish between text and binary files, except that some applications may use metadata (such as “extended attributes”) to characterize files in various ways. The files resulting from the incorrect code may or may not be identical, because identical string literals in different places may or may not have the same address, so the resulting pointer may or may not have the same value.

Answer 2

C provides a distinction in principle between binary and text streams. Data traversing a text stream may be subject to implementation-dependent conversions:

Characters may have to be added, altered, or deleted on input and output to conform to differing conventions for representing text in the host environment. Thus, there need not be a one- to-one correspondence between the characters in a stream and those in the external representation. Data read in from a text stream will necessarily compare equal to the data that were earlier written out to that stream only if: the data consist only of printing characters and the control characters horizontal tab and new-line; no new-line character is immediately preceded by space characters; and the last character is a new-line character. Whether space characters that are written out immediately before a new-line character appear when read in is implementation-defined.

(C2011, 7.21.2/2)

In practice, however, the only conversion you will see for byte-oriented streams on any system you're likely to meet is line terminator conversions on systems (primarily Windows) that use carriage return / newline pairs for line terminators in text files. C text mode streams will convert between that external representation and C's newline-only internal representation.

On Linux and modern BSD-based macOS, however, there isn't even that -- these operating systems make no distinction in practice between text and binary files, and it is not at all surprising that your two mechanisms for producing a file yield identical files.

It is an entirely separate question how an external program that attempts to guess at file types might interpret any given file, especially a very short one. Your chances are better for a file to be detected as text if it contains genuine text in the form of words and sentences.