Macros

[Ben Bacarisse]

Well, I've given up on that, because it's not up to the job. As I've said,
I'm using an external tool to convert source code in a kind of hybrid
language to what is considered normal C code.

You should have given up in it for it for other reasons, as you solution
illustrates perfectly: if syntax-disrupting macros are ever used, you
can't implement a simple syntax converter without either implementing a
full C pre-processor or running the source though one first. The former
is tedious and the latter makes it hard to keep things readable.

There is a fine tradition (on Unix at least) of writing what have become
know as "little languages" -- small syntax layers over a low-level
language to produce a higher-level one (ratfor and grap spring to mind,
but I am sure there are others) so you are in good company with this
solution. Lex and YACC were supposed to make this easy but they never
quite made it trivial (I'm looking forward to Perl 6 for this purpose).

<snip>

 

[Edward A. Falk]

Citation, please?

Hardly matters. Unless you're entering the obfuscated C programming
contest, doing this is a double-plus ungood idea, standard or no standard.

 

[James Kuyper]

Hardly matters. Unless you're entering the obfuscated C programming
contest, doing this is a double-plus ungood idea, standard or no standard.

It don't like the idea of doing it, but I also don't like saying
incorrect things about what does and does not violate the requirements
of the standard. Using language keywords does not violate any
requirements imposed by the C standard. Code which does such things
might be hard to read and understand, but it has well-defined behavior
according to the C standard (unless some other feature of the program is
problematic).

 

[Heikki Kallasjoki]

It don't like the idea of doing it, but I also don't like saying
incorrect things about what does and does not violate the requirements
of the standard. Using language keywords does not violate any
requirements imposed by the C standard. Code which does such things
might be hard to read and understand, but it has well-defined behavior
according to the C standard (unless some other feature of the program is
problematic).

There is, however, a slightly related rule in the standard about
keywords as macro names; one that might even be the source of the
(common?) belief stated above.

The program shall not have any macros with names lexically identical
to keywords currently defined prior to the inclusion of [any standard]
header or when any macro defined in the header is expanded.
(N1570 7.1.2p4)

It's not an outright ban, but it is a limitation.

 

[Eric Sosman]

Hardly matters. Unless you're entering the obfuscated C programming
contest, doing this is a double-plus ungood idea, standard or no standard.

It don't like the idea of doing it, but I also don't like saying
incorrect things about what does and does not violate the requirements
of the standard. Using language keywords does not violate any
requirements imposed by the C standard. [...]

7.1.2p4: "[...] The program shall not have any macros with
names lexically identical to keywords currently defined prior to
the inclusion of the header or when any macro defined in the header
is expanded."

So, yes: You *can* #define `if' or `void' or `case' et al., but
only in restricted circumstances:

#define int wuzzat
#include <stdio.h> // BZZZT!

#include <stdio.h>
#define int wuzzat
size_t whiffle = BUFSIZ; // BZZZT!

#include <setjmp.h>
#define int wuzzat
...
switch(setjmp(buf)) { // BZZZT!


#include <math.h>
#define int wuzzat
...
return sin(x); // BZZZT! (`(sin)(x)' would be OK)

Here's what I know: Anyone who engaged in this sort of thing,
even in formally permissible contexts, might not be fired after
the code review. He would, however, become a figure of fun and
an object of scorn, the butt of continuing jokes. (Did I mention
"companion of owls?" Probably best that I didn't.)

 

[James Kuyper]

requirements imposed by the C standard. Code which does such things
might be hard to read and understand, but it has well-defined behavior
according to the C standard (unless some other feature of the program is
problematic).

There is, however, a slightly related rule in the standard about
keywords as macro names; one that might even be the source of the
(common?) belief stated above.

The program shall not have any macros with names lexically identical
to keywords currently defined prior to the inclusion of [any standard]
header or when any macro defined in the header is expanded.
(N1570 7.1.2p4)

It's not an outright ban, but it is a limitation.

Yes, it is a limitation, but an avoidable one. With respect to my
earlier statement, violation of that limitation counts as "some other
feature of the program" that "is problematic".

 

[James Kuyper]

On 12/04/2012 08:03 PM, Eric Sosman wrote:
....

Here's what I know: Anyone who engaged in this sort of thing,
even in formally permissible contexts, might not be fired after
the code review. He would, however, become a figure of fun and
an object of scorn, the butt of continuing jokes. (Did I mention
"companion of owls?" Probably best that I didn't.)

That seems reasonable. I never defended is a good idea, I only objected
to the incorrect explanation of what was wrong with it.

 

[Phil Carmody]

On 12/04/2012 08:03 PM, Eric Sosman wrote:
...

That seems reasonable. I never defended is a good idea, I only objected
to the incorrect explanation of what was wrong with it.

And I'm glad you did. This has been an educational sub-thread.

To be frank, it might have been simpler if the standard had just
banned it outright, but that's just bikeshedding.

Phil

 

[Nick Keighley]

This preprocessor now 'works', and is transparent to the compilation
process.

(So long as the input is line-oriented and follows certain guidelines.)

But one small snag I hadn't thought of: modifying thousands of lines of
existing code to conform to this new format. I don't think it will help my
RSI much.)

Perl