37

Any one knows what is the ASCII value of i.

I try printf("%d",EOF);

but its print -1

and also try printf("%c",EOF);

but its print blank screen.

so anyone know which key for EOF.

phoxis
  • 60,131
  • 14
  • 81
  • 117
Patel Nik
  • 380
  • 1
  • 3
  • 8
  • 25
    EOF is not a character ! – nos Oct 01 '11 at 20:20
  • 1
    All of the defined ASCII characters (which equals the "base page" of Unicode) are specified [here](http://www.asciitable.com/). There are "control" characters such as "End of transmission" (EOT), but no EOF. – Hot Licks Sep 25 '14 at 20:37
  • 1
    *Sidenote:* If EOF had an ASCII value, one would have a really hard time reading file content, passed it's first appearance in the file ^^ – Levite Dec 03 '14 at 09:31

7 Answers7

56

EOF (as defined in the C language) is not a character/not an ASCII value. That's why getc returns an int and not an unsigned char - because the character read could have any value in the range of unsigned char, and the return value of getc also needs to be able to represent the non-character value EOF (which is necessarily negative).

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
  • why *must* it be negative? Is it simply the standard or is there a reason? – Alexander Mar 16 '15 at 21:24
  • 2
    It's simply a requirement of the C language. One guess at a historical motivation is that testing `x<0` was/is typically cheaper than testing equality with a nonzero constant. By requiring `EOF` to be negative and all meaningful character values to be non-negative, programmers can check `x<0` for EOF. – R.. GitHub STOP HELPING ICE Mar 16 '15 at 21:38
  • What did you mean by "non-character value"? If you mean "value of non-character type", then OK, but then `'a'` is a non-character value too. – M.M Feb 26 '16 at 01:42
  • @M.M: I'm using the word *value* in the purely numeric sense where it does not have any type associated with it. `'a'` is a value (97 on any reasonable implementation) that matches the numeric value of some character in the execution character set and thus is a "character value". `EOF` is necessarily distinct from any value matching a character since it's negative and the latter are all non-negative. – R.. GitHub STOP HELPING ICE Feb 26 '16 at 02:23
  • OK, you're only talking in the context of the return value of `getc` and related functions there. There may indeed be a `char` with the same value as `EOF`. – M.M Feb 26 '16 at 02:42
  • @M.M: If `char` is signed, then of course it's possible for a `char` type object/expression to have the same value as `EOF` but this is not a *character value* in the sense that I'm using. – R.. GitHub STOP HELPING ICE Feb 26 '16 at 03:52
  • @R.. Wonder what the EOF mentioned at http://www.softwareforeducation.com/sms32v50/sms32v50_manual/220-ascii.htm is? – Sanketh Mar 28 '17 at 16:44
  • Also this line in git source code mentions EOF as 26 (decimal) or 32 (octal). Ref: https://github.com/git/git/blob/master/convert.c#L82 Not sure if I'm missing something – Sanketh Mar 28 '17 at 16:47
  • @sanketh: It's an ASCII control code that has nothing to do with C's `EOF`. Historically some C implementations for DOS interpreted the ASCII EOF character as the end of the file (ignoring further contents) in text mode; I'm not aware of any modern implementations that do, and POSIX-conforming ones can't (because text mode is required to behave the same as binary mode). – R.. GitHub STOP HELPING ICE Mar 29 '17 at 01:33
  • @R.. Thanks for the explanation :) – Sanketh Mar 29 '17 at 03:07
14

The actual value of EOF is system defined and not part of the standard.

EOF is an int with negative value and if you want to print it you should use the %d format string. Note that this will only tell you its value on your system. You should not care what its value is.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • 3
    Why the downvote. I'd like to know if I got the details wrong. – David Heffernan Oct 01 '11 at 20:24
  • 1
    There are systems where `int` is the same width as `char` (DSPs, old Cray supercomputers) but they are rare. – Dietrich Epp Oct 01 '11 at 20:27
  • @Dietrich Epp And are the C systems on those platforms compliant with the C standard. – David Heffernan Oct 01 '11 at 20:28
  • 1
    The current C standard does not require `EOF` to be disjoint from the possible non-EOF return values from `getc`, bizarrely enough. Theoretically, after checking that `getc` returns `EOF` you must also check that `feof` and `ferror` return nonzero. Of course, almost nobody does that, which is fine. (`EOF` is only required to be negative, which ensures that it is disjoint on systems with wider `int` than `char`.) – Dietrich Epp Oct 01 '11 at 20:39
  • @Dietrich Thank you for clarifying. According to you, R.. got it wrong too. – David Heffernan Oct 01 '11 at 20:42
  • @Dietrich: The only way a non-EOF character could turn out equal to `EOF` when returned by `getc` is if the range of values representable in `unsigned char` is larger than the range of `int`, which could only really happen on a pathologically broken implementation. I have a question on SO about this very topic: http://stackoverflow.com/questions/3860943/can-sizeofint-ever-be-1-on-a-hosted-implementation – R.. GitHub STOP HELPING ICE Oct 01 '11 at 20:54
  • Note that `getc` returns either a character value (a value in the range of `unsigned char`) or `EOF`, *converted to type `int`*. Since the values of `unsigned char` are all non-negative, the only way one could masquerade as `EOF` is if the conversion to `int` were non-value-preserving, for example in the case what `UCHAR_MAX>INT_MAX` and the implementation-defined conversion to `int` maps a value onto `EOF`. – R.. GitHub STOP HELPING ICE Oct 01 '11 at 20:56
  • @R.. Is it not possible for `sizeof(int) == sizeof(unsigned char)`? – David Heffernan Oct 01 '11 at 20:57
  • The question I posted a link to is about that exact situation. – R.. GitHub STOP HELPING ICE Oct 01 '11 at 21:02
2

there is not such thing as ascii value of EOF. There is a ASCII standard that includes 127 characters, EOF is not one of them. EOF is -1 because that's what they decided to #defined as in that particular compiler, it could be anything else.

nos
  • 223,662
  • 58
  • 417
  • 506
daniel
  • 9,732
  • 7
  • 42
  • 57
  • In fact there is an ascii EOF... on DOS systems, at least http://www.softwareforeducation.com/sms32v50/sms32v50_manual/220-ascii.htm . It has nothing to do with EOF in C, though. – JavaLatte Feb 04 '19 at 04:08
2

As Heffernan said, it's system defined. You can access it via the EOF constant (is it a constand?):

#include <stdio.h>

int main(void)
{
    printf("%d\n", EOF);
}

After compiling:

c:\>a.exe
-1
c:\>
BlackBear
  • 22,411
  • 10
  • 48
  • 86
1

EOF do not have ASCII value as they said .... no problem with this

also you can avoid the strange character that appear in the end (which is the numeric representation of EOF ) by making if condition here is an example:

#include <stdio.h>

int main(void)
{
 FILE *file  = fopen("/home/abdulrhman/Documents/bash_history.log", "r");
 FILE *file2 = fopen("/home/abdulrhman/Documents/result.txt", "w");
 file  = 
 file2 = 
 char hold = 'A';

 while(hold != EOF)
  {
    hold = getc(file);
    if(hold == EOF) break; // to prevent EOF from print to the stream
    fputc(hold, file2);
  }

 fclose(file);
 return 0;
}

that is it

1

EOF is not an ASCII character. Its size is not 1 byte as against size of a character and this can be checked by

int main() {
    printf("%lu", sizeof(EOF));
    return 0;
}

However, it is always defined to be -1. Try

int main() {
    printf("%d",EOF);  
    return 0;
}

The key combination for EOF is Crtl+D. The character equivalent of EOF is machine dependent. That can be checked by following:

int main() {
    printf("%c", EOF)
    return 0;
}
wittich
  • 2,079
  • 2
  • 27
  • 50
Vineet Kapoor
  • 8,249
  • 1
  • 11
  • 14
  • 1
    `EOF` may be any negative `int` value. The page you linked to is not very accurate – M.M Feb 26 '16 at 01:39
  • @M.M: The standard permits `EOF` to have any negative value of type `int`. But it's entirely possible that all existing implementations happen to define it as `-1` (actually `(-1)`, the macro definition needs the parentheses). You shouldn't *depend* on it being equal to `-1`, but saying that it's always `-1` could well be technically accurate. – Keith Thompson May 09 '16 at 19:30
  • 1
    This is wrong. EOF can be any negative values, not only -1. See [Actual implementation of EOF different from -1](https://stackoverflow.com/q/48583103/995714), [Is EOF always negative?](https://stackoverflow.com/q/1624051/995714), [why in c language EOF IS -1?](https://stackoverflow.com/q/4569066/995714), [C EOF symbolic value and signed character](https://stackoverflow.com/q/7058902/995714) – phuclv Apr 27 '19 at 04:51
-6

for all intents and purposes 0x04 EOT (end of transmission as this will normaly signal and read function to stop and cut off file at that point.

  • 2
    On *some* systems, typing Ctrl-D will send character `0x04`, which will trigger and end-of-file condition. But the value of `EOF` is *not* `0x04`, even on such systems. – Keith Thompson May 09 '16 at 19:32