If I am using standard preprocessing then I may perform an indirect quote by:
#define foo bar
#define quoteme_(x) #x
#define quoteme(x) quoteme_(x)
and then just use quoteme(foo) to obtain "bar"
I want to do this, but using the pre-processor in traditional mode. I have attempted to just replace #x with 'x' but quoteme(foo) just returns 'foo'.
Any help is much appreciated.
Using the cpp that comes with GCC (4.8.1 tested), and the code (example.c):
#define foo bar
#define quoteme_(x) "x"
#define quoteme(x) quoteme_(x)
quoteme(foo)
The relevant part of the output from cpp -traditional example.c is:
"foo"
(and you can use single quotes in the replacement for quoteme_(x) similarly to obtain 'foo'). This is what you observed in the question.
AFAIK, there isn't a way to get 'bar' or "bar" out of the traditional preprocessor system. The pre-standard (traditional) systems were not standardized, and there were details where different systems behaved differently. However, macro arguments were expanded after replacement, rather than before as in C89 and later, which is what leads to the result you're seeing.
Related
I am writing a lexical analyser for a toy programming language with toy keywords. I wish to print "keyword" for every keyword the analyser bumps into. To make my code cleaner, I defined the term "keyword" for all keywords above the rule section.
%{
#include <stdio.h>
%}
keyword program | begin | ... | end
where the ... implies rest of the keywords.
In the rules section, I wrote the following rule:
{keyword} {
printf("keyword\n");
}
Then finally I wrote the main function and yywrap function.
However, when I compile the generated lex.yy.c file, I get the following error.
use of undeclared identifier 'keyword'
{keyword} {
^
Please help me with this error, I am new to this scanner-generating language.
You will get better answers here if you copy and paste the precise text of your program into your question. Otherwise, you force anyone answering to guess what the original text is. This is my guess:
Probably the line that is being complained about was indented in your flex input file. Make sure that all rules start exactly at the left margin. (Any indented text is copied verbatim into the output file, as though it were C code. The most common use for this feature is to add comments to your Flex rules.)
Also, you cannot use unquoted spaces in a macro definition; you would need:
keyword program|begin|...|end
Otherwise, flex will throw an error when it expands the macro. (It didn't expand the macro in this case, presumably because of the first problem.)
I'm trying to find any information parentheses syntax for macro arguments in GNU Assembler. E.g. I have following code:
.macro do_block, enc, in, rounds, rk, rkp, i
eor \in\().16b, \in\().16b, v15.16b
...
(taken from here)
What does paretheses in \in\().16b mean? Where to find documentaion for this syntax?
Okay, I've found the answer. This is special syntax to escape macro-argument name.
From the documentation:
Note that since each of the macargs can be an identifier exactly as any other one permitted by the target architecture, there may be occasional problems if the target hand-crafts special meanings to certain characters when they occur in a special position. For example:
...
problems might occur with the period character (‘.’) which is often allowed inside opcode names (and hence identifier names). So for example constructing a macro to build an opcode from a base name and a length specifier like this:
.macro opcode base length
\base.\length
.endm
and invoking it as ‘opcode store l’ will not create a ‘store.l’ instruction but instead > generate some kind of error as the assembler tries to interpret the text \base.\length.
The string \() can be used to separate the end of a macro argument from the following text. eg:
.macro opcode base length
\base\().\length
.endm
I see use experimental 'postderef' being used in Moxie here on line 8. I'm just confused at what it does. The man pages for experimental are pretty vague too,
allow the use of postfix dereferencing expressions, including in interpolating strings
Can anyone show what you would have to do without the pragma, and what the pragma makes easier or possible?
What is it
It's simple. It's syntactic sugar with ups and downs. The pragma is no longer needed as the feature is core in 5.24. But in order for the feature to be supported in between 5.20 and 5.24, it had to be enabled with: use experimental 'postderef'. In the provided example, in Moxie, it's used in one line which has $meta->mro->#*; without it you'd have to write #{$meta->mro}.
Synopsis
These are straight from D Foy's blog, along with Idiomatic Perl for comparison that I've written.
D Foy example Idiomatic Perl
$gimme_a_ref->()->#[0]->%* %{ $gimme_a_ref->()[0] }
$array_ref->#* #{ $array_ref }
get_hashref()->#{ qw(cat dog) } #{ get_hashref() }{ qw(cat dog) }
These examples totally provided by D Foy,
D Foy example Idiomatic Perl
$array_ref->[0][0]->#* #{ $array_ref->[0][0] }
$sub->&* &some_sub
Arguments-for
postderef allows chaining.
postderef_qq makes complex interpolation into scalar strings easier.
Arguments-against
not at all provided by D Foy
Loses sigil significance. Whereas before you knew what the "type" was by looking at the sigil on the left-most side. Now, you don't know until you read the whole chain. This seems to undermine any argument for the sigil, by forcing you to read the whole chain before you know what is expected. Perhaps the days of arguing that sigils are a good design decision are over? But, then again, perl6 is still all about them. Lack of consistency here.
Overloads -> to mean, as type. So now you have $type->[0][1]->#* to mean dereference as $type, and also coerce to type.
Slices do not have an similar syntax on primitives.
my #foo = qw/foo bar baz quz quuz quuuz/;
my $bar = \#foo;
# Idiomatic perl array-slices with inclusive-range slicing
say #$bar[2..4]; # From reference; returns bazquzquuz
say #foo[2..4]; # From primitive; returns bazquzquuz
# Whizbang thing which has exclusive-range slicing
say $bar->#[2,4]; # From reference; returns bazquz
# Nothing.
Sources
Brian D Foy in 2014..
Brian D Foy in 2016..
I'm trying to define a macro like this:
#define SOME_DEF [[TTys getString] isEqualToString:ANOTHER_STRING]
and then doing the following:
#if SOME_DEF
...
#endif
[TTys getString] returns an NSString
ANOTHER_STRING is defined earlier as #define ANOTHER_STRING "hello"
I get the following error on the #if SOME_DEF line:
Invalid token at start of a preprocessor expression
Based on this SO question this might be caused by something that can't be resolved at compile time, but I have everything defined. My suspect is
the isEqualToString method, but I don't know of another way to do this.
When you write #if SOME_DEF the preprocessor resolves it into:
#if [[TTys getString] isEqualToString:ANOTHER_STRING]
This is not a valid condition for the #if preprocessor directive:
The ‘#if’ directive allows you to test the value of an arithmetic
expression, rather than the mere existence of one macro. Its syntax is
#if expression
controlled text
#endif /* expression */
expression is a C expression of integer type, subject to stringent restrictions. It may contain
Integer constants.
Character constants, which are interpreted as they
would be in normal code.
Arithmetic operators for addition,
subtraction, multiplication, division, bitwise operations, shifts,
comparisons, and logical operations (&& and ||). The latter two obey
the usual short-circuiting rules of standard C.
Macros. All macros in
the expression are expanded before actual computation of the
expression's value begins.
Uses of the defined operator, which lets
you check whether macros are defined in the middle of an ‘#if’.
Identifiers that are not macros, which are all considered to be the
number zero. This allows you to write #if MACRO instead of #ifdef
MACRO, if you know that MACRO, when defined, will always have a
nonzero value. Function-like macros used without their function call
parentheses are also treated as zero.
From the GCC documentation.
What you can do instead is using a runtime-evaluated regular if-statement:
if(SOME_DEF) {
...
}
I have compiled ruby 64 bit on an AIX Box.
There doesn't seem to be any issue except when I use some specific regular expressions in my code.
Here is an example:
/([0-9]){1000}/.match("2")
results in:
RegexpError: too big quantifier in {,}: /([0-9]*){1000}/
When I try reducing the number of repetitions, it seems to work.
I tried digging into the ruby code. But could not understand the reason.
Is this some dependency or restriction that we have in AIX/64 bit ruby?
Thanks in advance :)
I almost immediately found the answer.
The first thing I did was to search in the ruby source code for the error being thrown. I found that regex.h was responsible for this.
In regex.h, the code flow is something like this:
/* Maximum number of duplicates an interval can allow. */
#ifndef RE_DUP_MAX
#define RE_DUP_MAX ((1 << 15) - 1)
#endif
Now the problem here is RE_DUP_MAX. On AIX box, the same constant has been defined somewhere in /usr/include. I searched for it and found in
/usr/include/NLregexp.h
/usr/include/sys/limits.h
/usr/include/unistd.h
I am not sure which of the three is being used(most probably NLregexp.h). In these headers, the value of RE_DUP_MAX has been set to 255! So there is a cap placed on the number of repetitions of a regex!
In short, the reason is the compilation taking the system defined value than that we define in regex.h!
Hence the issue was solved by reassigning the value of RE_DUP_MAX in regex.h
i.e
# ifdef RE_DUP_MAX
# undef RE_DUP_MAX
# endif
# define RE_DUP_MAX ((1 << 15) - 1)
Cheers!