strange function syntax

[GS]

I am doing my first real embedded programming project and the supplied
device libraries have a function definition that looks like this:

void FCN(void) = { INTDEF, INTABS, (unsigned short) PTRDEF};

where
INTDEF = some #defined integer
INTABS = some absolute integer (e.g. 2)
PTRDEF = some #defined pointer

The reason I ask is that my program is getting hung up (i.e. program
execution freezes without any exceptions/errors) on a call to this type of
function, but only when I compile with a certain amount of optimization
(everything works fine w/o optimization). This could be a compiler problem
I imagine but I'd like to know what the above statement does.

Thanks for your help.

 

[Eric Sosman]

I am doing my first real embedded programming project and the supplied
device libraries have a function definition that looks like this:

void FCN(void) = { INTDEF, INTABS, (unsigned short) PTRDEF};

where
INTDEF = some #defined integer
INTABS = some absolute integer (e.g. 2)
PTRDEF = some #defined pointer

The reason I ask is that my program is getting hung up (i.e. program
execution freezes without any exceptions/errors) on a call to this type of
function, but only when I compile with a certain amount of optimization
(everything works fine w/o optimization). This could be a compiler problem
I imagine but I'd like to know what the above statement does.

You're going to have to reveal more about `INTDEF' and
the like, and show their actual definitions. Otherwise,
people will just be making guesses.

 

[Case]

I am doing my first real embedded programming project and the supplied
device libraries have a function definition that looks like this:

void FCN(void) = { INTDEF, INTABS, (unsigned short) PTRDEF};

where
INTDEF = some #defined integer
INTABS = some absolute integer (e.g. 2)
PTRDEF = some #defined pointer

How is FCN #defined?

The reason I ask is that my program is getting hung up (i.e. program
execution freezes without any exceptions/errors) on a call to this type of
function, but only when I compile with a certain amount of optimization
(everything works fine w/o optimization). This could be a compiler problem
I imagine but I'd like to know what the above statement does.

A good strategy is to strip your program stepwise until you end up with
the smallest possible program that still shows this behaviour. Post the
resulting code here to allow for detailed help.

Some user programming errors [dis]appear when fiddling compiler/linker
options. I know we programmers tend to start looking for the fault in
'others' (e.g., libraries written by a colleague, the compiler or the
wheather). I've (almost) learned to first blame myself

Case

 

[GS]

FCN is just the function name, there's no #define of it.

How is FCN #defined?

options. I know we programmers tend to start looking for the fault in
'others' (e.g., libraries written by a colleague, the compiler or the
wheather). I've (almost) learned to first blame myself

Yes, well, this is a parallel effort to my personal code review.

Thanks again.

 

[GS]

OK but I don't know how it will help:

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F /* ptr to mem location */

this syntax compiles, shouldn't there be some general meaning??

 

[Eric Sosman]

A: Because people don't read from bottom to top.
Q: Why is top-posting deprecated?

OK but I don't know how it will help:

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F /* ptr to mem location */

this syntax compiles, shouldn't there be some general meaning??

Putting these definitions back into the original
code fragment, I get the still incomplete

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F /* ptr to mem location */
void FCN(void) = { INTDEF, INTABS, (unsigned short) PTRDEF};

.... which most definitely will compile. There must be more
#define's or other machinery lurking in the background, and you
haven't shown what it is.

"Doctor, it hurts!"

"What hurts?"

"I don't know how it will help you to know that, but it's
my knee that hurts."

"Your knee, eh? Which one?"

"What is this, the Spanish Inquisition?"

 

[Eric Sosman]

[..]
Putting these definitions back into the original
code fragment, I get the still incomplete

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F /* ptr to mem location */
void FCN(void) = { INTDEF, INTABS, (unsigned short) PTRDEF};

... which most definitely will compile. [...]

^
not

The Flying Fickle Finger of Fate fumbles the
keyboard yet again ...

 

[Dan Pop]

FCN is just the function name, there's no #define of it.

In this case, you don't have a C question: this is not valid C syntax.

Dan

 

[GS]

Putting these definitions back into the original
What more do you want?? change INTABS to 2 and you have the whole thing:

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F
void FCN(void) = {INTDEF, 2, (unsigned short) PTRDEF};

I believe that this is specifying a single instruction by its opcode and
arguments, however I've never seen this syntax before. Why the processor
would hang on this instruction is another mystery.

Thanks for all the jokes.

 

[GS]

In this case, you don't have a C question: this is not valid C syntax.

Well it does compile using Metrowerks codewarrior 9. I've never seen the
syntax before. The code isn't #defined for a particular compiler either, so
I'd be surprised if it was specific to metrowerks.

 

[Eric Sosman]

What more do you want?? change INTABS to 2 and you have the whole thing:

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F
void FCN(void) = {INTDEF, 2, (unsigned short) PTRDEF};

I believe that this is specifying a single instruction by its opcode and
arguments, however I've never seen this syntax before. Why the processor
would hang on this instruction is another mystery.

Why the compiler would accept it is another mystery,
as it isn't valid C. Not even close, not at all. End
of story, as far as the C language is concerned. If it's
some kind of compiler-specific non-conforming C-with-bells
extension, you'd better seek help on a newsgroup devoted
to the bell-bearing compiler in question.

Thanks for all the jokes.

You're welcome. Good bye.

 

[Case -]

FCN is just the function name, there's no #define of it.

Put

#undef FCN

right here (i.e., just before the presumable use of
macro FCN below). I wonder if it still compiles then.

Could you please show us the line of code where FCN is
called as a function. Or, what is the context in which
FCN exists? Are there any C preprocessor flags with -DFCN?
Is there any preprocessor invoked that was supplied by the
vendor of the OS, or whatever environment you use? Have
a close look at the build output of Metrowerks.

 

[Case -]

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F
void FCN(void) = {INTDEF, 2, (unsigned short) PTRDEF};

I believe that this is specifying a single instruction by its opcode and
arguments, however I've never seen this syntax before. Why the processor
would hang on this instruction is another mystery.

I have seen something similar as one of the winning
entries of the OCCC (Obfuscated C Code Contest) somewhere
in the 90s. It looked something like:

int main[] = { 0xeefa, 0xed48, 0x45ed, ....... };

Is this valid C? But is compiled and ran on a PDP11-70
printing "Hello world!" I believe.

Case

 

[Dan Pop]

Well it does compile using Metrowerks codewarrior 9.

Not if you invoke it as a standard C compiler. According to the
definition of the C programming language, this code:

1. Requires a diagnostic.

2. Has no defined semantics.

I've never seen the
syntax before. The code isn't #defined for a particular compiler either, so
I'd be surprised if it was specific to metrowerks.

As I said, not even metrowerks will silently accept it when invoked as a
C compiler.

Dan

 

[Default User]

A: Because people don't read from bottom to top.
Q: Why is top-posting deprecated?

Deprecated? It was never standard




Brian Rodenborn

 

[Arthur J. O'Dwyer]

I have seen something similar

Not similar to GS's code, since at least the IOCCC entry parses
correctly. The syntax

void foo(void) = { ... }

is quite simply invalid, whereas the syntax

int foo[] = { ... }

is a standard way to define an array.

as one of the winning
entries of the OCCC (Obfuscated C Code Contest) somewhere
in the 90s. It looked something like:

int main[] = { 0xeefa, 0xed48, 0x45ed, ....... };

Is this valid C? But is compiled and ran on a PDP11-70
printing "Hello world!" I believe.

It is not conforming C on a hosted implementation, according to
N869, because the declaration of 'main' as an array with external
linkage precludes the definition of 'main' as a function with
external linkage. Thus we have no 'main' function in a hosted
environment, which yields UB.
In a non-hosted environment, anything goes.
If you make it 'static int main[] = ...', then I think it is
valid C (assuming 'int main()' is defined in a different TU).

That this IOCCC code worked on a PDP-11 compiler is not surprising;
it might even work on a modern DOS-based compiler (with appropriate
adjustments to the machine-code part of the program). But since in
standard C, data is never code, this is definitely *not* guaranteed
to do anything in particular.

HTH,
-Arthur

 

[Keith Thompson]

#define INTDEF 0x08F8
#define PTRDEF 0xFFFFFA1F
void FCN(void) = {INTDEF, 2, (unsigned short) PTRDEF};
I believe that this is specifying a single instruction by its opcode
and
arguments, however I've never seen this syntax before. Why the processor
would hang on this instruction is another mystery.

I have seen something similar as one of the winning
entries of the OCCC (Obfuscated C Code Contest) somewhere
in the 90s. It looked something like:

int main[] = { 0xeefa, 0xed48, 0x45ed, ....... };

Is this valid C? But is compiled and ran on a PDP11-70
printing "Hello world!" I believe.

Actually, here's the program:

short main[] = {
277, 04735, -4129, 25, 0, 477, 1019, 0xbef, 0, 12800,
-113, 21119, 0x52d7, -1006, -7151, 0, 0x4bc, 020004,
14880, 10541, 2056, 04010, 4548, 3044, -6716, 0x9,
4407, 6, 5568, 1, -30460, 0, 0x9, 5570, 512, -30419,
0x7e82, 0760, 6, 0, 4, 02400, 15, 0, 4, 1280, 4, 0,
4, 0, 0, 0, 0x8, 0, 4, 0, ',', 0, 12, 0, 4, 0, '#',
0, 020, 0, 4, 0, 30, 0, 026, 0, 0x6176, 120, 25712,
'p', 072163, 'r', 29303, 29801, 'e'
};

It won the 1984 contest. The way the compiler and linker happened to
work on that particular system, it created a symbol called "main"
referring to a chunk of memory with those particular values, which
happened to be machine instructions. The runtime system didn't care
whether "main" was created by a function definition or by an array
definition, so it would execute the code.

Worse yet, the first word was a PDP-11 branch instruction; on a VAX,
execution would start at the second word. So the program would
execute on either a VAX or a PDP-11; the output was a smiley.

*However*, GS's code fragment has (what appears to be) a function
declaration, not an array declaration, so it's not doing the same
thing. Remove the '=' and add a semicolon before the '}', and you
have a legal function definition that doesn't do anything.

The fact that FCN is in all-caps makes me suspect that it's defined as
a macro. If FCN is not a macro, the code fragment is not legal C. If
FCN is a macro, it might conceivably be legal C, but I can't think of
a definition that would it legal. Probably GS's compiler implements
some extension for machine code insertions. Such extensions are
beyond the scope of this newsgroup, and we can't guess why the
processor is hanging.

 

[Keith Thompson]

Actually, here's the program:

short main[] = { [...]
};

[...]

Like all truly great IOCCC entries, it led to a rule change.
Excessively target-dependent entries were banned after the 1984
contest.

 

[Peter Nilsson]

... If it's some kind of compiler-specific non-conforming C-with-bells
extension...

Of course it's a compiler-specific C-with-bells extension. Of course
it's not _strictly_ conforming, but it is 'conforming' under the
definition of the standards.

 

[Olavi Sakari]

Though, this perfectly normal in comp.lang.postscript is.

Thanks,

Olle