Bug#835542: flex: comparison between signed and unsigned integer expressions

[Alexander Koeppe]

On Fri, 06 Oct 2017 10:58:32 +0200 Pedro Gimeno
 wrote:
> I'm getting the same issue reported in message #5 with flex 2.6.1-1.3
amd64.
>
> $ echo %% | flex ; gcc -c -Wsign-compare lex.yy.c
> lex.yy.c: In function ‘yy_get_next_buffer’:
> lex.yy.c:557:18: warning: comparison between signed and unsigned
integer expressions [-Wsign-compare]
> for ( n = 0; n < max_size && \
> ^
> lex.yy.c:960:3: note: in expansion of macro ‘YY_INPUT’
> YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> ^~~~
>
> Downgrading to 2.6.1-1.2 did not solve the issue.
>
>

I'm facing exactly the same issue. Seem the bug went back into the package.

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Pedro Gimeno]

I'm getting the same issue reported in message #5 with flex 2.6.1-1.3 amd64.

$ echo %% | flex ; gcc -c -Wsign-compare lex.yy.c
lex.yy.c: In function ‘yy_get_next_buffer’:
lex.yy.c:557:18: warning: comparison between signed and unsigned integer 
expressions [-Wsign-compare]
   for ( n = 0; n < max_size && \
  ^
lex.yy.c:960:3: note: in expansion of macro ‘YY_INPUT’
   YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
   ^~~~

Downgrading to 2.6.1-1.2 did not solve the issue.

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Christoph Berg]

Control: tag -1 patch pending

Re: Vladimír Čunát 2016-09-27 

> I'm curious: will there be a fix for 2.6.1?

I've just uploaded flex_2.6.1-1.2_source.changes fixing this to
delayed/5, patch attached.

 debian/NEWS.Debian |2 +-
 debian/changelog   |   12 +
 src/flex.skl   |   10 
 src/gen.c  |2 +-
 src/skel.c |   70 ++--
 5 files changed, 54 insertions(+), 42 deletions(-)

The net change is in flex.skl + gen.c; skel.c is generated from these.

Christoph

No differences were encountered between the control files

diff -Nru flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
@@ -1,3 +1,15 @@
+flex (2.6.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick 1da19feba7c957e0f0af0c3eeadc29e8c82b0ca3,
+cf4121fa97abac8aeaa5e08b8fc0b2380228494e and
+8c098febc9a599397921e9b6938b7fb85e38cc7e from upstream to fix comparison
+between signed and unsigned integer expressions in generated lexer
+(Closes: #835542).
+  * Fix distribution in last upload's NEWS.Debian.
+
+ -- Christoph Berg   Fri, 30 Dec 2016 20:29:41 +0100
+
 flex (2.6.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru flex-2.6.1/debian/NEWS.Debian flex-2.6.1/debian/NEWS.Debian
--- flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
@@ -1,4 +1,4 @@
-flex (2.6.1-1.1) UNRELEASED; urgency=medium
+flex (2.6.1-1.1) unstable; urgency=medium
 
In this upload, the flex package drops its dependency on libfl-dev, because
it is impossible to forward the correct architecture constraint. It contains
diff -Nru flex-2.6.1/src/flex.skl flex-2.6.1/src/flex.skl
--- flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
@@ -1661,7 +1661,7 @@
 M4_YY_DECL_GUTS_VAR();
 	char *dest = YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
 	char *source = YY_G(yytext_ptr);
-	yy_size_t number_to_move, i;
+	int number_to_move, i;
 	int ret_val;
 
 	if ( YY_G(yy_c_buf_p) > _CURRENT_BUFFER_LVALUE->yy_ch_buf[YY_G(yy_n_chars) + 1] )
@@ -1690,7 +1690,7 @@
 	/* Try to read more data. */
 
 	/* First move last chars to start of buffer. */
-	number_to_move = (yy_size_t) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr)) - 1;
+	number_to_move = (int) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr) - 1);
 
 	for ( i = 0; i < number_to_move; ++i )
 		*(dest++) = *(source++);
@@ -1778,7 +1778,7 @@
 	else
 		ret_val = EOB_ACT_CONTINUE_SCAN;
 
-	if ((int) (YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
+	if ((YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
 		/* Extend the array by 50%, plus the number we really need. */
 		int new_size = YY_G(yy_n_chars) + number_to_move + (YY_G(yy_n_chars) >> 1);
 		YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) yyrealloc(
@@ -2451,11 +2451,11 @@
 	YY_BUFFER_STATE b;
 	char *buf;
 	yy_size_t n;
-	yy_size_t i;
+	int i;
 m4_dnl M4_YY_DECL_GUTS_VAR();
 
 	/* Get memory for full buffer, including space for trailing EOB's. */
-	n = (yy_size_t) _yybytes_len + 2;
+	n = (yy_size_t) (_yybytes_len + 2);
 	buf = (char *) yyalloc( n M4_YY_CALL_LAST_ARG );
 	if ( ! buf )
 		YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" );
diff -Nru flex-2.6.1/src/gen.c flex-2.6.1/src/gen.c
--- flex-2.6.1/src/gen.c	2016-03-01 12:08:30.0 +0100
+++ flex-2.6.1/src/gen.c	2016-12-30 23:28:29.0 +0100
@@ -1973,7 +1973,7 @@
 		("if ( yy_act != YY_END_OF_BUFFER && yy_rule_can_match_eol[yy_act] )");
 	++indent_level;
 	indent_puts ("{");
-	indent_puts ("yy_size_t yyl;");
+	indent_puts ("int yyl;");
 	do_indent ();
 	out_str ("for ( yyl = %s; yyl < yyleng; ++yyl )\n",
 		 yymore_used ? (yytext_is_array ? "YY_G(yy_prev_more_offset)" :
diff -Nru flex-2.6.1/src/skel.c flex-2.6.1/src/skel.c
--- flex-2.6.1/src/skel.c	2016-03-02 01:54:10.0 +0100
+++ flex-2.6.1/src/skel.c	2016-12-30 23:28:29.0 +0100
@@ -18,10 +18,10 @@
   "%#  through m4. Macros beginning with `m4_' will be processed.",
   "%#  The quoting is \"[[\" and \"]]\" so we don't interfere with",
   "%#  user code.",
-  "%# ",
+  "%#",
   "%# All generate macros for the m4 stage contain the text \"m4\" or \"M4\"",
   "%# in them. This is to distinguish them from CPP macros.",
-  "%# The exception to this rule is YY_G, which is an m4 macro, ",
+  "%# The exception to this rule is YY_G, which is an m4 macro,",
   "%# but it needs to be remain short because it is used everywhere.",
   "%#",
   "/* A lexical scanner generated by flex */",
@@ -34,7 +34,7 @@
   "m4_changequote",
   "m4_changequote([[, ]])",
   "",
-  "%# ",
+  "%#",
   "%# 

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Vladimír Čunát]

I'm curious: will there be a fix for 2.6.1?

Thanks
--Vladimir

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On Sat, Sep 03, 2016 at 10:57:13PM +0200, Frank Heckenbach wrote:
> >
> > Will this fix be pushed by security.debian.org as well now, or will
> > I have to install it manually?
> 
> It will be pushed via security.debian.org archive "soon", since we
> have not confirmation. It's not intended that you will have to fix
> those manually on your machines. We will issue a follow-up DSA for it.
> 
> > I'm asking because I'm involved with a number of machines that
> > probably all have gotten the bad update by now, if I have to patch
> > them all myself now. (I'm also asking because I found another bug in
> > a security update of another package, incidentally on the same day
> > as this one?!) What's the usual procedure for non-security bugs
> > introduced by security updates? (Couldn't find anything about it on
> > the web site.)
> 
> I guess it is about a regression in the imagemagick update? If so it's
> as well already on security team's radar, and we will need to issue a
> regression update for that (there are filled bugs for those, e.g.
> #835488, #835650, #836189).

Yes, I meant this one (#835650 is from me).

Thanks for the info. I'll await the updates then.

Frank

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Salvatore Bonaccorso]

Hi,

On Sat, Sep 03, 2016 at 10:57:13PM +0200, Frank Heckenbach wrote:
> Hi,
> 
> > On 02/09/16 06:31, Salvatore Bonaccorso wrote:
> > > On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> > >> Alternatively, I'm pretty sure that adding the resulting changes to 
> > >> skel.c
> > >> in 0006-CVE-2016-6354.patch would work too.
> > >
> > > I uploaded new varaiants of the builds and the corresponding source
> > > package to the same location. Still subject to testing/review before
> > > doing any other steps.
> > 
> > FWIW, I've tested the new packages you've uploaded and can confirm that 
> > they fix the reported compile warning.
> 
> Me too.
> 
> Will this fix be pushed by security.debian.org as well now, or will
> I have to install it manually?

It will be pushed via security.debian.org archive "soon", since we
have not confirmation. It's not intended that you will have to fix
those manually on your machines. We will issue a follow-up DSA for it.

> I'm asking because I'm involved with a number of machines that
> probably all have gotten the bad update by now, if I have to patch
> them all myself now. (I'm also asking because I found another bug in
> a security update of another package, incidentally on the same day
> as this one?!) What's the usual procedure for non-security bugs
> introduced by security updates? (Couldn't find anything about it on
> the web site.)

I guess it is about a regression in the imagemagick update? If so it's
as well already on security team's radar, and we will need to issue a
regression update for that (there are filled bugs for those, e.g.
#835488, #835650, #836189).

Regards,
Salvatore


signature.asc
Description: PGP signature

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Hi,

> On 02/09/16 06:31, Salvatore Bonaccorso wrote:
> > On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> >> Alternatively, I'm pretty sure that adding the resulting changes to skel.c
> >> in 0006-CVE-2016-6354.patch would work too.
> >
> > I uploaded new varaiants of the builds and the corresponding source
> > package to the same location. Still subject to testing/review before
> > doing any other steps.
> 
> FWIW, I've tested the new packages you've uploaded and can confirm that 
> they fix the reported compile warning.

Me too.

Will this fix be pushed by security.debian.org as well now, or will
I have to install it manually?

I'm asking because I'm involved with a number of machines that
probably all have gotten the bad update by now, if I have to patch
them all myself now. (I'm also asking because I found another bug in
a security update of another package, incidentally on the same day
as this one?!) What's the usual procedure for non-security bugs
introduced by security updates? (Couldn't find anything about it on
the web site.)

Frank

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Robert Shearman]

Hi Salvatore,

On 02/09/16 06:31, Salvatore Bonaccorso wrote:

On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:

Alternatively, I'm pretty sure that adding the resulting changes to skel.c
in 0006-CVE-2016-6354.patch would work too.


I decided to actually patch skel.c, since that was the strategy
choosed by Manoj for the previous patches and not to diverge here/to
be consistent.

I uploaded new varaiants of the builds and the corresponding source
package to the same location. Still subject to testing/review before
doing any other steps.


FWIW, I've tested the new packages you've uploaded and can confirm that 
they fix the reported compile warning.


Thanks,
Rob

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Salvatore Bonaccorso]

Hi Rob,

On Thu, Sep 01, 2016 at 12:14:02PM +0100, Robert Shearman wrote:
> On 01/09/16 05:34, Salvatore Bonaccorso wrote:
> >Hi,
> >
> >On Tue, Aug 30, 2016 at 10:11:33AM +0100, Robert Shearman wrote:
> >>On Fri, 26 Aug 2016 21:52:11 +0200 Frank Heckenbach
> >> wrote:
> >>>Package: flex
> >>>Version: 2.5.39-8+deb8u1
> >>>Severity: normal
> >>>
> >>>After this update, I get the following warning when compiling the
> >>>flex generated code with gcc, which I didn't get before:
> >>>
> >>>scan.cpp: In function ??int yy_get_next_buffer(yyscan_t)??:
> >>>scan.cpp:758:18: error: comparison between signed and unsigned integer 
> >>>expressions [-Werror=sign-compare]
> >>>scan.cpp:1384:3: note: in expansion of macro ??YY_INPUT??
> >>>
> >>>Looking at the code:
> >>>
> >>>#define YY_INPUT(buf,result,max_size) \
> >>>   if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
> >>>   { \
> >>>   int c = '*'; \
> >>>   size_t n; \
> >>>   for ( n = 0; n < max_size && \
> >>>
> >>>Invoked as:
> >>>
> >>>int num_to_read = ...
> >>>YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> >>>   yyg->yy_n_chars, num_to_read );
> >>>
> >>>So indeed an unsigned value (n) is compared with a signed one
> >>>(num_to_read). If this is correct, the warning can be silenced with
> >>>a cast of the appropriate one of them.
> >>
> >>I've run into the same bug and agree with Frank's analysis. I've confirmed
> >>that the following upstream commit fixes it:
> >>
> >>https://github.com/westes/flex/commit/3946924ed5e77420c453bf841603c7278766093a
> >
> >Could you test the following packages:
> >
> >https://people.debian.org/~carnil/tmp/flex/
> 
> Thanks for the quick response. Unfortunately, so those packages don't fix
> the warning:
> 
> src/npf/npf_scan.c: In function ‘yy_get_next_buffer’:
> src/npf/npf_scan.c:852:18: error: comparison between signed and unsigned
> integer expressions [-Werror=sign-compare]
>for ( n = 0; n < max_size && \
>   ^
> src/npf/npf_scan.c:1623:3: note: in expansion of macro ‘YY_INPUT’
>YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
>^
> 
> However, the warning is actually because while the type of n has been fixed,
> num_to_read has reverted to yy_size_t:
> 
> #define YY_INPUT(buf,result,max_size) \
> if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
> { \
> int c = '*'; \
> int n; \
> for ( n = 0; n < max_size && \
>  (c = getc( yyin )) != EOF && c != '\n'; ++n ) \
> 
> ...
> 
> yy_size_t num_to_read =
> YY_CURRENT_BUFFER_LVALUE->yy_buf_size -
> number_to_move -
>  1;
> 
> So the effect is that 0006-CVE-2016-6354.patch isn't getting applied.
> 
> Rebuilding from the sources you also posted, I see that the reason for this
> is that skel.c isn't getting rebuilt, which it should be based on the
> contents of flex.skl. The root cause of this is that skel.c is getting
> patched by quilt at the same time as flex.skl is, so make doesn't see a
> difference in the timestamps.
> 
> I've verified that by removing the changes to skel.c from
> 0002-Finish-fixing-the-ia64-buffer-issue.patch and
> 0003-ia64-buffer-fix-Some-more-fixes-for-the-ia64-buffer-.patch results in a
> package being built where the fix works and I don't see the sign comparison
> warning being output from compile of the .c file generated by flex.

You are right, apologies not having spotted it.

> Alternatively, I'm pretty sure that adding the resulting changes to skel.c
> in 0006-CVE-2016-6354.patch would work too.

I decided to actually patch skel.c, since that was the strategy
choosed by Manoj for the previous patches and not to diverge here/to
be consistent.

I uploaded new varaiants of the builds and the corresponding source
package to the same location. Still subject to testing/review before
doing any other steps.

Regards,
Salvatore

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Robert Shearman]

On 01/09/16 05:34, Salvatore Bonaccorso wrote:

Hi,

On Tue, Aug 30, 2016 at 10:11:33AM +0100, Robert Shearman wrote:

On Fri, 26 Aug 2016 21:52:11 +0200 Frank Heckenbach
 wrote:

Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal

After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:

scan.cpp: In function ??int yy_get_next_buffer(yyscan_t)??:
scan.cpp:758:18: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
scan.cpp:1384:3: note: in expansion of macro ??YY_INPUT??

Looking at the code:

#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \

Invoked as:

int num_to_read = ...
YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, num_to_read );

So indeed an unsigned value (n) is compared with a signed one
(num_to_read). If this is correct, the warning can be silenced with
a cast of the appropriate one of them.


I've run into the same bug and agree with Frank's analysis. I've confirmed
that the following upstream commit fixes it:

https://github.com/westes/flex/commit/3946924ed5e77420c453bf841603c7278766093a


Could you test the following packages:

https://people.debian.org/~carnil/tmp/flex/


Thanks for the quick response. Unfortunately, so those packages don't 
fix the warning:


src/npf/npf_scan.c: In function ‘yy_get_next_buffer’:
src/npf/npf_scan.c:852:18: error: comparison between signed and unsigned 
integer expressions [-Werror=sign-compare]

   for ( n = 0; n < max_size && \
  ^
src/npf/npf_scan.c:1623:3: note: in expansion of macro ‘YY_INPUT’
   YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
   ^

However, the warning is actually because while the type of n has been 
fixed, num_to_read has reverted to yy_size_t:


#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
int n; \
for ( n = 0; n < max_size && \
 (c = getc( yyin )) != EOF && c != '\n'; 
++n ) \


...

yy_size_t num_to_read =
YY_CURRENT_BUFFER_LVALUE->yy_buf_size - 
number_to_move -

 1;

So the effect is that 0006-CVE-2016-6354.patch isn't getting applied.

Rebuilding from the sources you also posted, I see that the reason for 
this is that skel.c isn't getting rebuilt, which it should be based on 
the contents of flex.skl. The root cause of this is that skel.c is 
getting patched by quilt at the same time as flex.skl is, so make 
doesn't see a difference in the timestamps.


I've verified that by removing the changes to skel.c from 
0002-Finish-fixing-the-ia64-buffer-issue.patch and 
0003-ia64-buffer-fix-Some-more-fixes-for-the-ia64-buffer-.patch results 
in a package being built where the fix works and I don't see the sign 
comparison warning being output from compile of the .c file generated by 
flex.


Alternatively, I'm pretty sure that adding the resulting changes to 
skel.c in 0006-CVE-2016-6354.patch would work too.


Thanks,
Rob

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Salvatore Bonaccorso]

Hi,

On Tue, Aug 30, 2016 at 10:11:33AM +0100, Robert Shearman wrote:
> On Fri, 26 Aug 2016 21:52:11 +0200 Frank Heckenbach
>  wrote:
> > Package: flex
> > Version: 2.5.39-8+deb8u1
> > Severity: normal
> > 
> > After this update, I get the following warning when compiling the
> > flex generated code with gcc, which I didn't get before:
> > 
> > scan.cpp: In function ??int yy_get_next_buffer(yyscan_t)??:
> > scan.cpp:758:18: error: comparison between signed and unsigned integer 
> > expressions [-Werror=sign-compare]
> > scan.cpp:1384:3: note: in expansion of macro ??YY_INPUT??
> > 
> > Looking at the code:
> > 
> > #define YY_INPUT(buf,result,max_size) \
> > if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
> > { \
> > int c = '*'; \
> > size_t n; \
> > for ( n = 0; n < max_size && \
> > 
> > Invoked as:
> > 
> > int num_to_read = ...
> > YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
> > yyg->yy_n_chars, num_to_read );
> > 
> > So indeed an unsigned value (n) is compared with a signed one
> > (num_to_read). If this is correct, the warning can be silenced with
> > a cast of the appropriate one of them.
> 
> I've run into the same bug and agree with Frank's analysis. I've confirmed
> that the following upstream commit fixes it:
> 
> https://github.com/westes/flex/commit/3946924ed5e77420c453bf841603c7278766093a

Could you test the following packages:

https://people.debian.org/~carnil/tmp/flex/

Regards,
Salvatore

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Robert Shearman]

On Fri, 26 Aug 2016 21:52:11 +0200 Frank Heckenbach 
 wrote:

Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal

After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:

scan.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
scan.cpp:758:18: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
scan.cpp:1384:3: note: in expansion of macro ‘YY_INPUT’

Looking at the code:

#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \

Invoked as:

int num_to_read = ...
YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, num_to_read );

So indeed an unsigned value (n) is compared with a signed one
(num_to_read). If this is correct, the warning can be silenced with
a cast of the appropriate one of them.


I've run into the same bug and agree with Frank's analysis. I've 
confirmed that the following upstream commit fixes it:


https://github.com/westes/flex/commit/3946924ed5e77420c453bf841603c7278766093a

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Frank Heckenbach]

Package: flex
Version: 2.5.39-8+deb8u1
Severity: normal

After this update, I get the following warning when compiling the
flex generated code with gcc, which I didn't get before:

scan.cpp: In function ‘int yy_get_next_buffer(yyscan_t)’:
scan.cpp:758:18: error: comparison between signed and unsigned integer 
expressions [-Werror=sign-compare]
scan.cpp:1384:3: note: in expansion of macro ‘YY_INPUT’

Looking at the code:

#define YY_INPUT(buf,result,max_size) \
if ( YY_CURRENT_BUFFER_LVALUE->yy_is_interactive ) \
{ \
int c = '*'; \
size_t n; \
for ( n = 0; n < max_size && \

Invoked as:

int num_to_read = ...
YY_INPUT( (_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
yyg->yy_n_chars, num_to_read );

So indeed an unsigned value (n) is compared with a signed one
(num_to_read). If this is correct, the warning can be silenced with
a cast of the appropriate one of them.

flex hasn't exactly been known for generating warning-free code,
but what really worries me is that this is a security update. Fixing
a security problem by introducing a sign-problem seems fishy to me.

-- System Information:
Debian Release: 8.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flex depends on:
ii  debconf [debconf-2.0]  1.5.56
ii  dpkg   1.17.27
ii  install-info   5.2.0.dfsg.1-6
ii  libc6  2.19-18+deb8u5
ii  libfl-dev  2.5.39-8+deb8u1
ii  m4 1.4.17-4

Versions of packages flex recommends:
ii  clang-3.5 [c-compiler]  1:3.5-10
ii  gcc [c-compiler]4:4.9.2-2
ii  gcc-4.8 [c-compiler]4.8.4-1
ii  gcc-4.9 [c-compiler]4.9.2-10

Versions of packages flex suggests:
ii  bison2:3.0.2.dfsg-2
ii  build-essential  11.7

-- no debconf information