Hrm, I'm disinclined to merge this because its a hack to fix something broken elsewhere the way it sounds, has this been reported to emscripten and confirmed? I don't have anything handy to test emscripten with but if it behaves as you say, its definitely an emscripten bug (or at least, not libRocket).

I'd not be against merging it if it was wrapped in #ifdefs making it clear that it was a hack to fix a broken emscripten part.

I guess not even gcc/clang do handle this special case in a right manner but better than emscripten. I tested it with this code:

#include <stdio.h>
#include <stdlib.h>

int main()
{
   float floatVal;
   char unit[20],dtm[20];

   strcpy( dtm, "10.0em" );
   sscanf( dtm, "%f%s", &floatVal,unit );

   printf("value:%f unit:%s\n",floatVal,unit );

   return(0);
}

gcc/clang do return: 10.0000 / 'm' (consuming the e-character)
emscripten: 0.00000 / empty-string

I posted the issue to emscripten and surrounded the hack with an #ifdef.

hmm, okay, let me investigate some more and see whats going on. I may be misinterpreting the scanf parsing. Thanks for the updated patch, but with your example code I want to investigate a little more and find out exactly what the problem is and why it seems to work with gcc/llvm but your test code shows that it shouldn't.

Stay tuned

To be honest I didn't use scanf yet and usually when I come to the point that I'm sure there is a bug in a major framework, it is still me who is wrong. :)

This looks like a duplicate of the problem I already fixed in librocket earlier but which was also not accepted. VS2015's scanf fails the same way without it. Surely they all can't be wrong.

Emscripten and VS2015's scanf are correct conforming implementations, but gcc and llvm are wrong.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

Interpretation of format specifiers:

a,e,f,g Matches an optionally signed floating-point number,infinity,or NaN, whose format is the same as expected for the subject sequence of the strtod function. The corresponding argument shall be a pointer to floating.

Parsting the format specifier:

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. 251) The first character,if any,after the input item remains unread. If the length of the input item is zero, the execution of the directive fails; this condition is a matching failure unless end-of-file, an encoding error,or a read error prevented input from the stream, in which case it is an input failure.

Note that:

251. fscanf pushes back at most one input character onto the input stream. Therefore, some sequences that are acceptable to strtod, strtol,etc., are unacceptable to fscanf.

From strtod:

The expected form of the subject sequence is an optional plus or minus sign, then one of the following:
—a nonempty sequence of decimal digits optionally containing a decimal-point character,then an optional exponent part as defined in 6.4.4.2;

The grammar of a floating point number

(6.4.4.2) floating-constant: decimal-floating-constant hexadecimal-floating-constant
(6.4.4.2) decimal-floating-constant: fractional-constant exponent-partopt floating-suffixopt digit-sequence exponent-part floating-suffixopt
§A.1.5 Language syntax summary 405
ISO/IEC 9899:TC3 Committee Draft — Septermber 7, 2007 WG14/N1256
(6.4.4.2) hexadecimal-floating-constant: hexadecimal-prefix hexadecimal-fractional-constant binary-exponent-part floating-suffixopt hexadecimal-prefix hexadecimal-digit-sequence binary-exponent-part floating-suffixopt
(6.4.4.2) fractional-constant: digit-sequenceopt . digit-sequence digit-sequence .
(6.4.4.2) exponent-part: e signopt digit-sequence E signopt digit-sequence
(6.4.4.2) sign: one of +
(6.4.4.2) digit-sequence: digit digit-sequence digit

Note that this grammar REQUIRES a number after the "e".

So the parsing of "10em" will FAIL when using scanf() because it would need to support pushing 2 characters back onto the input stream instead of just 1.

This code should be changed to use strtod. strtod is defined to parse a floating point number using:

The subject sequence is defined as the longest initial subsequence of the input string, starting with the first non-white-space character,that is of the expected form. The subject sequence contains no characters if the input string is not of the expected form

So strtod() will work properly in this case.