Your message dated Sat, 06 Sep 2008 13:54:19 -0500 with message-id <[EMAIL PROTECTED]> and subject line This has been rejected by upstream has caused the Debian Bug report #194904, regarding flex: YY_CURRENT_BUFFER unavailable to member functions to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [EMAIL PROTECTED] immediately.) -- 194904: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=194904 Debian Bug Tracking System Contact [EMAIL PROTECTED] with problems
--- Begin Message ---Package: flex Version: 2.5.31-8 Severity: normal Tags: patch -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux suffix 2.4.20 #1 Fri Apr 4 13:57:56 CEST 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages flex depends on: ii libc6 2.3.1-14 GNU C Library: Shared libraries an ii m4 1.4-14 a macro processing language Dear maintainer, In the Flex info-reader I read, in the section `Values Available To the User', that the following values should be avaiable in rule-actions: `char *yytext' ... `YY_CURRENT_BUFFER' Although there's nothing wrong here, a bit of confusion (and maybe a bug) is caused by the fact that the variables (yytext, yyleng, etc) are defined as protected members of the class FlexLexer, so they are available to member functions of derived classes as well whereas YY_CURRENT_BUFFER and YY_START aren't. In older versions, yy_current_buffer was available to member functions, but currently YY_CURRENT_BUFFER (and YY_START) aren't anymore, as they are defined as macros in the code generated by flex. I think this is unfortunate, as YY_CURRENT_BUFFER must now be passed as an argument to member functions requiring YY_CURRENT_BUFFER, even though (currenly) the value it is referring to *is* available as a data member to derived class' member functions. I suggest to make YY_CURRENT_BUFFER (and YY_START as well?) available to member functions of derived class' members, as are the other values mentioned in the said flex info reader page. A simple patch applied to FlexLexer.h solves this for YY_CURRENT_BUFFER and YY_START: it simply puts the two macros in FlexLexer.h: ------------------------------------------------------- 55a56,61 > #define YY_CURRENT_BUFFER ( (yy_buffer_stack) \ > ? (yy_buffer_stack)[(yy_buffer_stack_top)] \ > : NULL) > > #define YY_START (((yy_start) - 1) / 2) > ------------------------------------------------------- After including these macros in FlexLexer.h their definitions in the generated (C++) source can be removed. I don't have a patch for that readily available, though. Kind regards, Frank B. Brokken
--- End Message ---
--- Begin Message ---Hi, This was filed 5 years ago, and upstream responded by saying that: > We strongly recommend against using the FlexLexer class at all. It > may oj disappear entirely in the future, since it has proven to be a > maintenance liabilty. At this point, this report is not going anywhere, and no one should be using the FlexLexer class at all. manoj -- H. L. Mencken suffers from the hallucination that he is H. L. Mencken -- there is no cure for a disease of that magnitude. -- Maxwell Bodenheim Manoj Srivastava <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--- End Message ---
