bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: yylval and strdup() on a 64 bit system - yylval should be a 64 bit n


From: Kaz Kylheku
Subject: Re: yylval and strdup() on a 64 bit system - yylval should be a 64 bit number
Date: Thu, 14 Jul 2016 18:47:07 -0700
User-agent: Roundcube Webmail/0.9.2

On 14.07.2016 17:33, Richard Wicks wrote:
Minor bug - yylval cannot contain a 64 bit pointer, however this
doesn't actually effect most systems due to where the heap is located
in memory.

Do you have a minimal test case for this bug, along with a
description of the expected and actual behavior?

The default type of yylval, in a traditional non-reentrant
Yacc-generated parser, is int.

Indeed, that cannot portably hold a pointer.

Nobody in their right mind expects it to; if yylval is to hold a pointer,
its type should be configured accordingly.

If you want just one value type, but other than int, the classic
way is to define the preprocessor macro YYSTYPE.

  #define YYSTYPE char *

Now your yylval is not a number at all; it has char * type, which is a
64 bit pointer on a 64 bit system.

There is also the %union directive which makes YYSTYPE a union, and at the
same informs Bison about the member names, which are used to implement
a kind of semantic typing scheme, as well as to provide a convnienent
syntactic sugar for accessing the semantic values without having to use
the union member selection syntax explicitly.

You use this if you want some of your parse nodes to be numbers and
others something else, like symbols or strings.

It's all in the Bison manual, not to mention various tutorials and books on
Lex and Yacc, the manuals of other implementations, vast numbers
of open source examples of parsers, and not to mention the POSIX standard
which describes the requirements for a yacc utility:

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/yacc.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]