2000-12-12 04:39:15 +08:00
|
|
|
%{
|
2010-11-24 04:27:50 +08:00
|
|
|
/*
|
|
|
|
* A scanner for EMP-style numeric ranges
|
2010-09-21 04:08:53 +08:00
|
|
|
* contrib/cube/cubescan.l
|
2010-11-24 04:27:50 +08:00
|
|
|
*/
|
2000-12-12 04:39:15 +08:00
|
|
|
|
2017-08-11 11:33:47 +08:00
|
|
|
/* LCOV_EXCL_START */
|
|
|
|
|
2003-09-14 09:52:25 +08:00
|
|
|
/* No reason to constrain amount of data slurped */
|
|
|
|
#define YY_READ_BUF_SIZE 16777216
|
2000-12-12 04:39:15 +08:00
|
|
|
|
2003-05-30 06:30:02 +08:00
|
|
|
/* Avoid exit() on fatal scanner errors (a bit ugly -- see yy_fatal_error) */
|
2005-10-16 04:37:36 +08:00
|
|
|
#undef fprintf
|
Improve handling of ereport(ERROR) and elog(ERROR).
In commit 71450d7fd6c7cf7b3e38ac56e363bff6a681973c, we added code to inform
suitably-intelligent compilers that ereport() doesn't return if the elevel
is ERROR or higher. This patch extends that to elog(), and also fixes a
double-evaluation hazard that the previous commit created in ereport(),
as well as reducing the emitted code size.
The elog() improvement requires the compiler to support __VA_ARGS__, which
should be available in just about anything nowadays since it's required by
C99. But our minimum language baseline is still C89, so add a configure
test for that.
The previous commit assumed that ereport's elevel could be evaluated twice,
which isn't terribly safe --- there are already counterexamples in xlog.c.
On compilers that have __builtin_constant_p, we can use that to protect the
second test, since there's no possible optimization gain if the compiler
doesn't know the value of elevel. Otherwise, use a local variable inside
the macros to prevent double evaluation. The local-variable solution is
inferior because (a) it leads to useless code being emitted when elevel
isn't constant, and (b) it increases the optimization level needed for the
compiler to recognize that subsequent code is unreachable. But it seems
better than not teaching non-gcc compilers about unreachability at all.
Lastly, if the compiler has __builtin_unreachable(), we can use that
instead of abort(), resulting in a noticeable code savings since no
function call is actually emitted. However, it seems wise to do this only
in non-assert builds. In an assert build, continue to use abort(), so that
the behavior will be predictable and debuggable if the "impossible"
happens.
These changes involve making the ereport and elog macros emit do-while
statement blocks not just expressions, which forces small changes in
a few call sites.
Andres Freund, Tom Lane, Heikki Linnakangas
2013-01-14 07:39:20 +08:00
|
|
|
#define fprintf(file, fmt, msg) fprintf_to_ereport(fmt, msg)
|
|
|
|
|
|
|
|
static void
|
|
|
|
fprintf_to_ereport(const char *fmt, const char *msg)
|
|
|
|
{
|
|
|
|
ereport(ERROR, (errmsg_internal("%s", msg)));
|
|
|
|
}
|
2003-05-30 06:30:02 +08:00
|
|
|
|
2003-09-14 09:52:25 +08:00
|
|
|
/* Handles to the buffer that the lexer uses internally */
|
|
|
|
static YY_BUFFER_STATE scanbufhandle;
|
|
|
|
/* this is now declared in cubeparse.y: */
|
|
|
|
/* static char *scanbuf; */
|
|
|
|
/* static int scanbuflen; */
|
2000-12-12 04:39:15 +08:00
|
|
|
%}
|
|
|
|
|
2002-07-31 00:33:08 +08:00
|
|
|
%option 8bit
|
|
|
|
%option never-interactive
|
2004-02-25 06:06:32 +08:00
|
|
|
%option nodefault
|
2008-08-26 07:12:45 +08:00
|
|
|
%option noinput
|
2002-07-31 00:33:08 +08:00
|
|
|
%option nounput
|
|
|
|
%option noyywrap
|
2011-08-26 01:55:57 +08:00
|
|
|
%option warn
|
2003-09-14 09:52:25 +08:00
|
|
|
%option prefix="cube_yy"
|
2002-07-31 00:33:08 +08:00
|
|
|
|
|
|
|
|
2000-12-12 04:39:15 +08:00
|
|
|
n [0-9]+
|
|
|
|
integer [+-]?{n}
|
2002-08-30 07:03:58 +08:00
|
|
|
real [+-]?({n}\.{n}?|\.{n})
|
2000-12-12 04:39:15 +08:00
|
|
|
float ({integer}|{real})([eE]{integer})?
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
infinity [+-]?[iI][nN][fF]([iI][nN][iI][tT][yY])?
|
|
|
|
NaN [nN][aA][nN]
|
2000-12-12 04:39:15 +08:00
|
|
|
|
|
|
|
%%
|
|
|
|
|
2004-09-14 12:21:38 +08:00
|
|
|
{float} yylval = yytext; return CUBEFLOAT;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
{infinity} yylval = yytext; return CUBEFLOAT;
|
|
|
|
{NaN} yylval = yytext; return CUBEFLOAT;
|
2000-12-12 04:39:15 +08:00
|
|
|
\[ yylval = "("; return O_BRACKET;
|
|
|
|
\] yylval = ")"; return C_BRACKET;
|
|
|
|
\( yylval = "("; return O_PAREN;
|
|
|
|
\) yylval = ")"; return C_PAREN;
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
\, yylval = ","; return COMMA;
|
2004-02-25 06:06:32 +08:00
|
|
|
[ \t\n\r\f]+ /* discard spaces */
|
2000-12-12 04:39:15 +08:00
|
|
|
. return yytext[0]; /* alert parser of the garbage */
|
|
|
|
|
|
|
|
%%
|
|
|
|
|
2017-08-11 11:33:47 +08:00
|
|
|
/* LCOV_EXCL_STOP */
|
|
|
|
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
/* result is not used, but Bison expects this signature */
|
2015-03-27 02:03:19 +08:00
|
|
|
void
|
2013-07-29 22:42:37 +08:00
|
|
|
yyerror(NDBOX **result, const char *message)
|
2003-09-14 09:52:25 +08:00
|
|
|
{
|
|
|
|
if (*yytext == YY_END_OF_BUFFER_CHAR)
|
|
|
|
{
|
|
|
|
ereport(ERROR,
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for cube"),
|
2003-09-14 09:52:25 +08:00
|
|
|
/* translator: %s is typically "syntax error" */
|
|
|
|
errdetail("%s at end of input", message)));
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
ereport(ERROR,
|
Improve contrib/cube's handling of zero-D cubes, infinities, and NaNs.
It's always been possible to create a zero-dimensional cube by converting
from a zero-length float8 array, but cube_in failed to accept the '()'
representation that cube_out produced for that case, resulting in a
dump/reload hazard. Make it accept the case. Also fix a couple of
other places that didn't behave sanely for zero-dimensional cubes:
cube_size would produce 1.0 when surely the answer should be 0.0,
and g_cube_distance risked a divide-by-zero failure.
Likewise, it's always been possible to create cubes containing float8
infinity or NaN coordinate values, but cube_in couldn't parse such input,
and cube_out produced platform-dependent spellings of the values. Convert
them to use float8in_internal and float8out_internal so that the behavior
will be the same as for float8, as we recently did for the core geometric
types (cf commit 50861cd68). As in that commit, I don't pretend that this
patch fixes all insane corner-case behaviors that may exist for NaNs, but
it's a step forward.
(This change allows removal of the separate cube_1.out and cube_3.out
expected-files, as the platform dependency that previously required them
is now gone: an underflowing coordinate value will now produce an error
not plus or minus zero.)
Make errors from cube_in follow project conventions as to spelling
("invalid input syntax for cube" not "bad cube representation")
and errcode (INVALID_TEXT_REPRESENTATION not SYNTAX_ERROR).
Also a few marginal code cleanups and comment improvements.
Tom Lane, reviewed by Amul Sul
Discussion: <15085.1472494782@sss.pgh.pa.us>
2016-09-27 23:38:33 +08:00
|
|
|
(errcode(ERRCODE_INVALID_TEXT_REPRESENTATION),
|
|
|
|
errmsg("invalid input syntax for cube"),
|
2003-09-14 09:52:25 +08:00
|
|
|
/* translator: first %s is typically "syntax error" */
|
|
|
|
errdetail("%s at or near \"%s\"", message, yytext)));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called before any actual parsing is done
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
cube_scanner_init(const char *str)
|
|
|
|
{
|
|
|
|
Size slen = strlen(str);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Might be left over after ereport()
|
|
|
|
*/
|
|
|
|
if (YY_CURRENT_BUFFER)
|
|
|
|
yy_delete_buffer(YY_CURRENT_BUFFER);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make a scan buffer with special termination needed by flex.
|
|
|
|
*/
|
|
|
|
scanbuflen = slen;
|
|
|
|
scanbuf = palloc(slen + 2);
|
|
|
|
memcpy(scanbuf, str, slen);
|
|
|
|
scanbuf[slen] = scanbuf[slen + 1] = YY_END_OF_BUFFER_CHAR;
|
|
|
|
scanbufhandle = yy_scan_buffer(scanbuf, slen + 2);
|
|
|
|
|
|
|
|
BEGIN(INITIAL);
|
|
|
|
}
|
|
|
|
|
2000-12-12 04:39:15 +08:00
|
|
|
|
2003-09-14 09:52:25 +08:00
|
|
|
/*
|
|
|
|
* Called after parsing is done to clean up after cube_scanner_init()
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
cube_scanner_finish(void)
|
|
|
|
{
|
|
|
|
yy_delete_buffer(scanbufhandle);
|
|
|
|
pfree(scanbuf);
|
2000-12-12 04:39:15 +08:00
|
|
|
}
|