Re: Flex size_t sizes

[Kaz Kylheku]

[Replying to HTML with HTML] 

On 2021-11-13 02:17, Hans Åberg wrote: 

> On 12 Nov 2021, at 23:41, Kaz Kylheku <kaz@kylheku.com> wrote: 
> 
>> I see that, for instance on a Ubuntu 18 system here, there is a
>> /usr/bin/FlexLexer.h file.
>> 
>> This is an incredibly, incredibly bad idea.
>> 
>> Generated parser or scanner code must be 100% self-contained. The 
>> Flex-generated
>> code cannot be depending on some /usr/include/FlexLexer.h.
> 
> It is what it is, and it Flex developed much, so it is better to use 
> something else.

But that is not true; there is a deployment problem here that is fairly
easily worked around. 

If the C++ flex is otherwise useful, why not. 

>> If there must be a FlexLexer.h, the thing to do is to arrange for the build
>> process to use a local copy of FlexLexer.h that is in your tree. As part of
>> generating the scanner, your Makefile (or whatever) steps should hunt down
>> this header file, stick it into your tree, and make the code refer to that
>> copy.
>> 
>> Check that copy into version control, and make sure downstream users have it
>> as part of the distribution, and that they can build the scanner without
>> having any portion of Flex installed on their system.
> 
> So this is a way, but if you do not want to ship it, then it must be present 
> elsewhere. And if you ship it, and the the .ll file is compiled with an 
> incompatible Flex version, it won't compile.

There is a subtlety here I might have buried in all my verbiage. 

This #include <FlexLexer.h> is an issue EVEN IF YOU TAKE THE PRUDENT
STEP OF SHIPPING THE GENERATED SCANNER.

That's the problem! 

There should not be a problem if you ship the lex source code, and
expect the user to have Flex and run it to generate the code. Their
installation of the utility should match their <FlexLexer.h> header. If
not, they have a bad/inconsistent installation. 
Shipping the scanner should be immune to this kind of problem.

But even you ship Flex-generated code, it is not self-contained by
default: that generated code wants a Flex-specific C++ header from the
system. That requires Flex to be installed, and the right version, which
spoils the whole idea of just shipping the C code.

Though that is quite ridiculous, you can easily work around it by
shipping that header and somehow making sure that your lex.yy.cc file
finds that copy of the header and not some system installed one.

That's what I'm saying.