1

Consider the following C code (online available io.c):

#include <stdio.h>
int main () {
  float f;
  char c;
  
  scanf ("%f%c", &f, &c);
  printf ("%f \t %c", f, c);

  return 0;
}

When the input is 100f, it outputs 100.000000 f. However, when the input is 100e, it outputs only 100.000000, without e followed. What is going on here? Isn't 100e an invalid floating-point number?

hengxin
  • 1,867
  • 2
  • 21
  • 42
  • I actually do get ```100.000000 e``` on one system I tried. There is an existing answer on this topic: [How to scanf a float followed immediately by the letter 'e' in c?](https://stackoverflow.com/questions/36086616/how-to-scanf-a-float-followed-immediately-by-the-letter-e-in-c) – sj95126 Oct 03 '21 at 16:16
  • Both of you are getting `100.000000 e`? [I'm not](https://godbolt.org/z/ofbfEdKxx), on godbolt or on my personal system. If I choose another character besides `e`, then it prints. I strongly suspect the `e` is being interpreted as `e+0` for a scientific notation input (`100e+2` outputs `10000.00000`), but in this case I can't explain why `scanf` is returning 2 ... ? – yano Oct 03 '21 at 16:22
  • 1
    @yano: I get ```e``` under Cygwin (gcc 10.2), no ```e``` on Linux (gcc 10.3). In the case where there's no ```e```, ```c``` is set to ```'\n'``` so ```scanf``` returns 2 either way. – sj95126 Oct 03 '21 at 16:25
  • @sj95126 ahh, yes, `'\n'` explains the 2nd match, of course. Interesting deviation of behavior .. my personal box is fedora, gcc v11.2.1 – yano Oct 03 '21 at 16:27
  • It must be interpreting the input with `e` as scientific notation https://stackoverflow.com/a/35422323/3476780 – yano Oct 03 '21 at 16:30
  • According to Page 374 of the book "The Standard C Library" by P.J. Plaucer, `count = scanf("%f%20s of %20s", ...)` against input `100ergs of energy` produces `count = 0`, since "`100e` fails to match `%f`". @yano – hengxin Oct 03 '21 at 16:36
  • [not what I'm seeing](https://godbolt.org/z/nfP49dhrb). Looks like it matches `100e` for `"%f"`, then `rgs` for `"s", stops reading at the space apparently. But no return of 0. – yano Oct 03 '21 at 16:49
  • 1
    [Possibly related](https://stackoverflow.com/q/1425730/60281) with an answer from Fred J. Tydeman, Vice-char of PL22.11 (ANSI "C"). – DevSolar Oct 03 '21 at 18:36

4 Answers4

4

This is (arguably) a glibc bug.

This behaviour clearly goes against the standard. However it is exhibited by other implementations. Some people consider it a bug in the standard instead.

Per the standard, An input item is defined as the longest sequence of input characters which does not exceed any specified field width and which is, or is a prefix of, a matching input sequence. So 100e is an input item because it is a prefix of a matching input sequence, say, 100e1, but any longer sequence of characters from the input isn't. Further, If the input item is not a matching sequence, the execution of the directive fails: this condition is a matching failure. 100e is not a matching sequence so the standard requires the directive to fail.

The standard cannot tell scanf to accept 100 and continue scanning from e, as some people would expect, because stdio has a limited push-back of just one character. So having read 100e, the implementation would have to read at least one more character, say a newline to be specific, and then push back both newline and e, which it cannot always do.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243
  • 1
    This is correct, but the answer should contain more explanation. Per C 2018 7.21.6.2 9, `fscanf` (and family) scans as long as the current sequence matches an expected form or its prefix. (Obviously, having read “100e”, which matches a possible “100e+3”, we have to keep scanning even though “100e” by itself is not a correct full match, because we do not know whether the next character [or EOF] will break the match.) But note 291 notes that `fscanf` is limited to pushing back a single character. Thus, with “100e+x”, it has a dilemma… – Eric Postpischil Oct 03 '21 at 17:54
  • 1
    … Having read “100e+”, it has to continue. But the “x” breaks it. The “x” can be pushed back, but the “+” and the “e” cannot. Therefore, it cannot just accept “100” and resume scanning at the “e”. It must declare a matching failure and return 0. That is the proper behavior, and glibc is broken for failing to do that. With “100e”, we are in the same situation—we have to scan after the “e”. When we get the EOF or new-line character or whatever follows the “e”, it is too late to push back the “e”, so it ought to report matching failure, returning 0 for zero completed matches. – Eric Postpischil Oct 03 '21 at 17:57
  • If the glibc people rather go with "existing practice" (huh?) instead of the standard, they should consider not defining `__STDC__` either... – DevSolar Oct 03 '21 at 18:40
  • @DevSolar Codifying existing practice is in the charter of the C standards committee. – n. m. could be an AI Oct 03 '21 at 20:43
  • 1
    @n. 1.8e9 And having implemented the standard is what defining `__STDC__` promises. Also, "existing practice" is decided by the committee, and not one implementor. That part we are referring to here has been in the standard literally forever, and by doing it this way around, glibc is breaking TWO promises of the standard -- they can only consider "100e" to be a matching success by putting *two* characters back into the stream. That s why "existing practice" is to not use scanf ("scan formatted") on potentially malformed input in the first place... – DevSolar Oct 03 '21 at 21:13
  • @DevSolar gcc and glibc are intentionally non-conforming in many other ways. I think their rationale to define __STDC__ was documented somewhere but I cannot find it; in a nutshell, it is a pragmatic decision that allows more existing programs to compile. – n. m. could be an AI Oct 04 '21 at 03:40
  • @n.1.8e9-where's-my-sharem.: \_\_ in comments marks bold. Quote an underscore with a backslash to keep it literal. – Eric Postpischil Oct 04 '21 at 23:17
4

I'd say this is pretty clearly a pretty unclear, gray area.

If you're an implementor of a C library (or a member of the X3J11 committee), you have to worry about this sort of thing — sometimes a lot. You have to worry about the edge cases, and sometimes the edge cases can be particularly edgy.

However, you did not tag your question with the "language lawyer" tag, so perhaps you're not worried about a scrupulously correct, official interpretation.

If you're not an implementor of a C library or a member of the X3J11 committee, I'd say: don't worry what the "right" answer here is! You don't have to worry, because you don't care, because you'd be crazy to write code which is sensitive to this question — precisely because it's such an obvious gray area. (Even if you do figure out what the right behavior here is, do you trust every implementor of every C library in the world to always implement that behavior?)

I'd say there are three things you can do in the category of "not worrying", and not writing code which is sensitive to this question.

  1. Don't use scanf at all (for anything). It's an odious, imprecise, imperfect function, that's not good for anything except — perhaps — getting numbers into the first few programs you ever write while you're first learning C. After that, scanf has no use in any serious program.

  2. Don't arrange your code and data such that it has to confront ambiguous input like "100e" in the first place. Where is it coming from, anyway? Is it input the user might type? Data being read in from a data file? Is it expected or unexpected, correct or incorrect input? If you're reading a data file, do you have control over the code that writes the data file? Can you guarantee that floating-point fields will always be delimited appropriately, will not occasionally have random alphabetic characters appended?

  3. If you do have to parse input that might contain a valid floating-point number, might have random alphabetic characters appended, and might therefore be ambiguous like this, I'd encourage you to use strtod instead, which is likely to be both better-defined and better-implemented.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
-1

From the C Standard (6.4.4.2 Floating constants)

decimal-floating-constant:
    fractional-constant exponent-partopt floating-suffixopt
    digit-sequence exponent-part floating-suffixopt

and

exponent-part:
    e signopt digit-sequence
    E signopt digit-sequence

If you will change the call of printf the following way

printf ("%e \t %d\n", f, c);

you will get the output

1.000000e+02     10

that is the variable c has gotten the new line character '\n'.

It seems that the implementation of scanf is made such a way that the symbol e is interpreted as a part of a floating number though there is no digit after the symbol.

According to the C Standard (7.21.6.2 The fscanf function)

9 An input item is read from the stream, unless the specification includes an n specifier. An input item is defined as the longest sequence of input characters which does not exceed any specified field width and which is, or is a prefix of, a matching input sequence.278) The first character, if any, after the input item remains unread.

So 100e is a matching input sequence of characters for a floating number.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
-1

Give a space between "%f %c" like that and also when you are going to enter input make sure to have a space between two inputs. I am assuming you just want to print a character.

AncientPro
  • 100
  • 1
  • 12