Remove this ad

Lead

Mar 16 14 12:41 PM

Tags : :

I always had some problems on files generated by flex and usually I avoid to generate the corresponding .cpp/.h files and use the copies stored in SVN repository.

But today I checked and found the problem (lucky for me it is a stupid problem).

I guess the problem found depends on the version of compiler and of flex/bison used.

The problem found is the following:
- delete Scanner.cpp and Scanner.h
- run make (this should re-build the deleted files)
- all deleted files are re-built
- while compiling the Scanner.cpp file I have the following error

[code]
Scanner.cpp:1237:3: error: no matching function for call to 'ReadLexBuff'
YY_INPUT( (&YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[number_to_move]),
^~~~~~~~
./Scanner.l:25:20: note: expanded from macro 'YY_INPUT'
#define YY_INPUT ReadLexBuff
^~~~~~~~~~~
./Scanner.l:28:13: note: candidate function not viable: no known conversion from 'yy_size_t' (aka 'unsigned long') to 'int &' for 2nd argument
static void ReadLexBuff(char* pcBuff, int& riResult, size_t uMaxSize);

[/code]

So the problem is that the function is called with argument of type yy_size_t (that I guess is a typedef for C++ size_t/unsigned long).

Solution found: change the prototype of ReadLexBuff to use the predefined type of Flex "yy_size_t" so change from
[code]
static void ReadLexBuff(char* pcBuff, int& riResult, size_t uMaxSize);
[/code]
to
[code]
static void ReadLexBuff(char* pcBuff, yy_size_t& riResult, yy_size_t uMaxSize);
[/code]

(obviously the same fix must be applied later in the same file for the implementation of the function).

I did this after noticed that, in implementation of the function, all variables are "size_t" and the value stored in returned in "riResult" is in origin a size_t value.

I use flex 2.5.37 and as C++ compiler
[code]
Apple LLVM version 5.1 (clang-503.0.38) (based on LLVM 3.4svn
[/code]

on Mac OS (but I'm quite sure to have had the same problem with Linux).

Doubt: maybe a better prototype should use the flex type yy_size_t, so something as
[code]
static void ReadLexBuff(char* pcBuff, yy_size_t& riResult, yy_size_t uMaxSize);
[/code]

Bye,
Mr Hyde
Quote    Reply   
Remove this ad
Remove this ad

#1 [url]

Mar 16 14 1:29 PM

Re: Scanner.l little problem (and maybe a solution)

Ok, I found that flex in previous version has a mix of int and yy_size_t, so to maintain also older version maybe a better solution is to provide functions with int& and size_t&.
In attachment a proposal of patch (against current SVN version) for Scanner.l file

Remember that I have no experience at all with flex, so feel free to insult me at any time

Bye,
Mr Hyde
--------------------
Click here to view the attachment

Quote    Reply   

#2 [url]

Mar 22 14 1:29 PM

Re: Scanner.l little problem (and maybe a solution)

While I don't like the double function very much, well - if it does the trick...
What about the
#include // needed for std::min

There is no such call.

Quote    Reply   

#3 [url]

Mar 23 14 7:06 PM

Re: Scanner.l little problem (and maybe a solution)

Hi Stu!

The #include is something I forgot from an attempt of mines where I used
std::min(T a, T b)

[code]
size_t uCharsRead = std::min(uMaxSize, uCharsInBuff);
[/code]
instead of the original
[code]
size_t uCharsRead = min(uMaxSize, uCharsInBuff);
[/code]

but at the end I chose for "minimal" changes so I avoided to use it.

As always my memory is not good

Bye,
Mr Hyde

Quote    Reply   
Add Reply

Quick Reply

bbcode help