BL51: '*** WARNING L1: UNRESOLVED EXTERNAL SYMBOL'

which I must ignore. Because L1 is only a warning;
Many decide to ignore warnings, that may be OK during development, but there is a difference between "ignore" and "not read"
I may ignore warnings during development, but I ALWAYS read them

I can't think of any scenario where I would want the a) build to continue with missing source modules, b) yet I can find no tool that would allow me to make L1 an error instead of a warning.
a) the warning is NOT "missing source module" but "missing reference" I often accept a build when that comes up. e.g. in the first stages of a debug, you may have a function that is not called with an unresolved reference. b) such an option might be nice.

Erik

which I must ignore. Because L1 is only a warning;
Many decide to ignore warnings, that may be OK during development, but there is a difference between "ignore" and "not read"
I may ignore warnings during development, but I ALWAYS read them

I can't think of any scenario where I would want the a) build to continue with missing source modules, b) yet I can find no tool that would allow me to make L1 an error instead of a warning.
a) the warning is NOT "missing source module" but "missing reference" I often accept a build when that comes up. e.g. in the first stages of a debug, you may have a function that is not called with an unresolved reference. b) such an option might be nice.

Erik

"I implement a state machine with a table of function pointers. This interacts with an idiosyncracy of BL51 to make it jump to the (erroneous) conclusion my functions are calling themselves recursively. Keil has an app note detailing a workaround for this, but it is such a hassle to get the syntax right, I frequently let BL51 whine."

I'd say that's almost certainly the reason why your application failed in the first place!!

You've read the app note, so you know that this is due to a fundamental feature of the 8051 architecture. If you disregard that and and just plough on regardless, you are positively asking for trouble!

Yes, tables of function pointers are great for implementing state machines - but you have to weigh this against their cost on the 8051 (ie, having to cope with the Linker's foibles).

If getting the tools configured is too much for you, then you need to look for another solution.

Personally, I'd have loved to have used my normal function-pointer table approach to FSMs, but found all the manual Linker tweaking far too risky - so I used switches instead.

Your call.

There seems to be two communities of users of the Keil '51 software:

There is the "C is C" community that refuse to accept that the '51 is weak in certain respects which makes it advisable to avoid certain constructs. I guess that those also do not use the unique features of the '51 that makes it strong in other respects:
I implement a state machine with a table of function pointers

Then there is those that adapt to the realities:
Personally, I'd have loved to have used my normal function-pointer table approach to FSMs, but found all the manual Linker tweaking far too risky - so I used switches instead.

Erik

I think it should be possible to use function pointers in C51 without having to manually tweak the Linker's call tree?

On the other hand, I know that the switch approach works.

Hence my choice!

I think it should be possible to use function pointers in C51 without having to manually tweak the Linker's call tree?

But you have nevertheless accepted reality :)

Everyone has something they would like to see different, it may and may not be included in the next release. Do I have 'things', absolutely. Do I sit doen and whine about them? abaolutely not.

Now, for a real BUG. I would send 47 e-mails every day till it was fixed.

Erik