regarding the datatype of yy_state_buf

[Robins_Lazer]

-----Original Message-----
From: address@hidden [mailto:address@hidden]
Sent: Saturday, August 17, 2002 4:03 PM
To: address@hidden
Subject: Help-flex digest, Vol 1 #253 - 2 msgs

Send Help-flex mailing list submissions to
        address@hidden

To subscribe or unsubscribe via the World Wide Web, visit
        http://mail.gnu.org/mailman/listinfo/help-flex
or, via email, send a message with subject or body 'help' to
        address@hidden

You can reach the person managing the list at
        address@hidden

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Help-flex digest..."

Today's Topics:

   1. Re: %option header (Was Re: flex 2.5.13 released) (John Millaway)
   2. Re: %option header (Was Re: flex 2.5.13 released) (Bruce Lilly)

--__--__--

Message: 1
Date: Fri, 16 Aug 2002 09:05:54 -0700 (PDT)
From: John Millaway <address@hidden>
Subject: Re: %option header (Was Re: flex 2.5.13 released)
To: flex list <address@hidden>

Thanks Bruce. Before I address each issue, let me explain the reasoning behind
the header generation. The header is meant to export only the EXTERNAL API, not
the internal guts. Flex generates many undocumented macros, but that doesn't
mean we're commiting to their existence in future versions. We may rename them
or remove them altogether as the skeleton evolves. The fact that the internal
macros appear in the header file is an undesirable side effect of the header
generation process. In order to undo that side effect, we squash those internal
macros by  #undefing them at the end of the header. This is to ensure that
users don't rely on those macros.

Protecting the namespace is equally as important as protecting the internals.
Flex should not export unprefixed symbols. The start conditions are not
prefixed in the scanner because the were never exported. If a user wants to
export start conditions in the header, then prefixes are a fact of life. As you
said, there is always `sed'.

> 1. yyset_debug is... unconditionally #undef'ed.
Thanks. I'll fix this.

> 2. start conditions are unconditionally #undef'ed.
The unprefixed ones are undef'd.

> 3. ... It would be nice to be able to avoid the following, none
>     of which are needed (outside of the generated .c file)
Thanks. I look into each one.

> 4. There are a bunch of comments that seem to add little but clutter:
>     various /* %c */, /* %+ */, /* %* */, etc. yy_get_next_buffer,
>     yy_get_previous_state, etc.

These are markers for skeleton hackers, and are invaluable when jumping from
generated code to the flex source to the skeleton and back again. The header is
never going to be remotely as concise and pretty as a human-generated header.

> 5. There are munged versions of start condition names...
>     a. I don't need munged versions; it would be nice to be able to
>        avoid them to prevent namespace clashes
Hello,

Is there any way that I can change the datatype of yy_state_buf from char
array to char * in the generated lexer file, and also where should I allocate the memory for this variable.

Regards
Robins
 
**************************************************************************
This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED. If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated.

**************************************************************************