I'm dealing with a somewhat intractable problem. We're running dSPACE 7.4 (RTI 1006) on MATLAB 2011a, which I understand uses the dSPACE DS1006 C Compiler v. 2.2. When I try to compile one of our models, I wind up with a linker error claiming that fscanf is undefined (it's being invoked in a custom function). I have verified that stdio.h is where it should be in the system hierarchy and that it contains a definition for fscanf. Following are the steps I took to try to resolve the problem:

  • linker initially complains about undefined fscanf()
  • extra definition inserted in model-specific file where I know it will be compiled causes linker to complain about inconsistent definitions for fscanf()
  • commenting out fscanf() definition in stdio.h then allows successful compilation/linking
  • inserting stub definition into stdio.h and commenting out original (and stub in model-specific file) results in 'multiple definitions of fscanf' errors (this is the weirdest part of the whole story)

The stub definition (I am assured by a higher-up that this shouldn't break our model but I haven't yet had a chance to verify this) is as follows:

int fscanf(int a, char *cp, void *b, ...){return 0;}

So, if I'm reading it correctly it's a version of fscanf that won't actually do what fscanf is supposed to do. In summary, I have to hack my compiler's library to get this model to build, and I'm not entirely confident that it will run on our hardware at present. I also don't want to tell everyone in the office to modify their dSPACE installation and break fscanf unless I know that it works and it's the only way forward.

Can anyone give me some insight on this?

UPDATE: It does indeed run on our hardware. But I don't like breaking fscanf(), so I'd still like to figure this out.

  • $\begingroup$ This seems to be a programing question not an engineering one. $\endgroup$
    – hazzey
    Jun 19, 2017 at 17:54
  • $\begingroup$ More or less true, but since I'm running an automotive industry-specific software/hardware package that is not likely to be used by anyone outside of automotive engineering, this seemed like the best place to ask it. $\endgroup$
    – ZStamler
    Jun 19, 2017 at 17:56
  • $\begingroup$ stdio.h is just the header file you need to compile to code. To link it, the linker needs a "runtime library." with the correct version of fscanf. Note, the Matlab version of fscanf() NOT the same as the standard C version - it sounds like you are trying to mix and match the two versions somehow, which won't work. $\endgroup$
    – alephzero
    Jun 19, 2017 at 18:44
  • $\begingroup$ Well, it's very possible that that's true. Unfortunately, without any specific documentation from the manufacturer it's very difficult to figure out where to include any directives for the linker to use. I do know that a C header file called stdio.h is being used, as when I comment out the fscanf function there I can get the code to compile. However, if the linker is for some reason trying to access the MATLAB version of the function, I wouldn't be surprised at this point. $\endgroup$
    – ZStamler
    Jun 19, 2017 at 20:01
  • 1
    $\begingroup$ You can get almost anything to "compile" by not including any header files at all - but that doesn't mean it's the right way to go! If you paid money for a product with no documentation or support, you got scammed IMHO. $\endgroup$
    – alephzero
    Jun 19, 2017 at 20:31

1 Answer 1


This presumably worked before. So the fundamental first step is to regress any and all of the changes you made (you are using source control, right?) until you get it back to a known good state.

From there, you need to examine the change you made. C supports methods having identical names so long as they have different method signatures. I.e. the input parameters must be different between the two methods.

C also supports letting you define those two identically named methods in two different areas. So you can use the standard fscanf method as well as this custom implementation that you've run into.

The definition you mentioned:
int fscanf(int a, char *cp, void *b, ...){return 0;} is likely where you're having problems. And you likely have an additional definition of fscanf beyond the standard lib definition. And the two "home grown" fscanf methods likely have conflicting method signatures. The ... as the fourth parameter indicates that the method can take a variable number of inputs. My best guess is that there's another fscanf definition with 4 inputs defined and / or followed by the variable input indicator.

In short - hunt down all of the definitions you have in your application for fscanf. That's where you'll find the conflicting definition and the source of your linker error.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.