Redirect stdin ?

Re: Redirect stdin ?

On Dec 31, 1:40 pm, Lothar Behrens <lothar.behr... @lollisoft.de>
wrote:
If you are okay with using gcc extensions, here's a section
from the glibc info pages you might find interesting:

Here is an example of using `fmemopen' to create a stream for
reading from a string:

#include <stdio.h>

static char buffer[] = "foobar";

int
main (void)
{
int ch;
FILE *stream;

stream = fmemopen (buffer, strlen (buffer), "r");
while ((ch = fgetc (stream)) != EOF)
printf ("Got %c\n", ch);
fclose (stream);

return 0;
}

This program produces the following output:

Got f
Got o
Got o
Got b
Got a
Got r

Re: Redirect stdin ?



Lothar Behrens wrote:lex uses three macros that can be #defined by the user named 'input',
'unput' and 'output'. It is designed with the intention that you can
override those macros as needed to define different input sources. I
don't know if that meets your needs; it requires a change in the
source code you give to lex, which means that lex will generate
different output code, which is technically a violation of your
requirements. Depending upon the reasons for your requirements, it
might be better to modify your requirements than to use the more
complicated approaches needed to conform to those requirements.
Your 'input' macro could refer to a function that stores only as much
of the file as can actually fit into your buffer at any given time. As
long as your buffer is a least big enough to hold the longest look-
ahead required by your grammar, that shouldn't be a problem.

Re: Redirect stdin ?

On Dec 31, 7:00 pm, jameskuy...@ver izon.net wrote:I do understand these macros as callbacks where I could do the
feeding.

My requirements were not to modify the generated code from lex and
yacc to
get a workaround (as of I wouldn't be aware of Lex & Yacc a bit)

Currently I have changed the grammar. There was a problem with the
supported
syntax of my SQL code. So I tend to change it as you supposed.
As of the case I handle SQL statements, the lookahead buffer may be
big enough,
when I allocate 100 bytes. That will be enough for a small query.

In case not, where do I see the size of this buffer ?

Thank you,

Lothar

Re: Redirect stdin ?

In article <e4bcc6d9-3b30-46af-875d-e4a44a18a8db@v4 g2000hsf.google groups.com>,
Lothar Behrens <lothar.behrens @lollisoft.dewr ote:
There are two different interpretations to "not to modify the
generated code from lex and yacc".

One interpretation is that you do not want to hand-modify the C code
that lex and yacc generate: if that is the interpretation, then you can
solve the problem along the lines James gave, by altering the input
macros (or, alternately, by supplying your own yyin() routine).
You supply lex and yacc with an input routine and the code lex and
yacc would generate would take the supplied input routine into account.
This is the interpretation of your requirements if the emphasis
in your requirement is on "modify".

The second possible interpretation of your requirement is that
for some reason or other you require that whatever solution is
arrived at must have the lex and yacc sections compile to exactly
the same object code as would be the case if you were working with
a regular file instead of a string. This is the interpretation of
your requirements if the emphasis in your requirements is on
"generated" -- that the *generated* code must be exactly the same.
This might be the case if, for example, you intended to call the same
lex and yacc routines, sometimes supplying input from a string
and sometimes providing input from a file. James noted that
his suggestion did not technically meet your requirements because
if you modify the input macros then even though the C source output
by lex and yacc might look the same (except perhaps a line or two),
when the compiler got through with it, the object code generated
would be different, in violation of your constraint to not modify
the *generated* code: modifying the macros before running lex and
yacc would result in different code being generated. Anyhow, if this
is your requirement, then I believe you could meet the those
terms by supplying your own yyin() function; if I recall, yyin()
is function which is linked against, so the object code would not
change.
--
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth