• State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 21 subscribers
  • Views 6456 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

C51 warning C322: unknown identifier

Robert Wilcox

I am porting some code to 8051 and the existing code uses #define to determine whether or not some functionality is available

i.e. ....

#define HAVE_STRING_H
.
.
.
.

#ifndef HAVE_STRING_H
#include <string.H
#else
#include <homegrown/string.h>
#endif
Any suggestions on how I can suppress or correct C322?

Obviously, I can change
#define HAVE_STRING_H
to
#define HAVE_STRING_H 1
and then change
#ifdef HAVE_STRING_H
to
#if HAVE_STRING_H
but I am trying to preserve as much of the original code as I can.

Any help is appreciated and thanks in advance.

Robert

Parents Reply Children
  • 0 in reply to Drew Davis

    "I'm more a fan of the ANSI style"

    Yes, me too.

    I notice that modern compilers seem to deal sensibly with this:

    #if SYMBOL
    ...
    #endif

    If SYMBOL has not been defined you get an 'undefined symbol' error.

    At least one ancient compiler I use from time to time treats SYMBOL as false in this situation, which is a real nuisance.

    Stefan

  • 0 in reply to John Donaldson

    "If SYMBOL has not been defined you get an 'undefined symbol' error."

    Not with an ANSI/ISO compliant compiler. If an undefined macro name appears in the constant-expression of #if or #elif, it is replaced by the integer constant 0.

  • 0 in reply to Dan Henry

    "Not with an ANSI/ISO compliant compiler. If an undefined macro name appears in the constant-expression of #if or #elif, it is replaced by the integer constant 0."

    Well there you go, I'd never realised that was supposed to happen. I realise now that the modern compilers I use issue a warning rather than an error (making them compliant - I understand that 'Warning: Cup of tea required at line 37' is permitted by the standard).

    In this case it seems very sensible to issue a warning...

    Stefan

  • 0 in reply to John Donaldson

    I'd never realised [undefined substituted with 0] was supposed to happen

    Good ol' K&R behavior. It helps contribute to the popular trap when people try to use the conditionals with nice readable string values instead of integers:

    -DPLATFORM=EVAL

    #if PLATFORM == EVAL
    #elif PLATFORM == SIM
    #endif

    Works like a charm, since PLATFORM becomes EVAL, and then EVAL on both sides of the first == becomes 0. 0 == 0, so off you go with the first branch, even if you -DPLATFORM=SIM. A warning can be a good thing.

    (You can actually make this work if you #define a series of constants for EVAL, SIM, etc., in a header, and are sure to include that header.)