Re: Flex size_t sizes

[Hans Åberg]

> On 13 Nov 2021, at 22:04, Kaz Kylheku <kaz@kylheku.com> wrote:
> 
> [Replying to HTML with HTML] 

Normally, text is expected on these types of lists, even though many probably 
can use styled text.

> On 2021-11-13 02:17, Hans Åberg wrote: 
> 
>> On 12 Nov 2021, at 23:41, Kaz Kylheku <kaz@kylheku.com> wrote: 
>> 
>>> 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.

Not it isn't. If you decide to ship the original header, then a compiled 
version may ot work. Akim though made a header that checks the Flex version and 
adapts—see his reply in this thread.

> 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. 

This works as long as nobody tries to compile the .ll file with an incompatible 
Flex version even in the case the header is shipped.

It should have been as in Bison, which always includes the correct header. But 
Flex isn't developed, so it is what it is.