1

I did not dig enough on my own, thank you for your time and responses.

In the actual code (proprietary embedded) the header extern's are #ifdef'ed and the default was to not create them when the .c included the .h. When I set this option it did produce the warnings (errors actually) that I had wanted.

I have a header with:

extern int array[10];

and a source file with:

int array[2] = {0, 0};

Clearly this is incorrect. How can I cause the compiler to warn me? An error would be acceptable as well.

Compilers of interest to me are GCC (old, 3.4.5) and TASKING (not new, 2.3r3). Note that I generally succeed at not making this error but a supplier code generation application apparently does do this. Of course, getting the application fixed is important and I can also write a script to compare the files, but a general compile time solution that would catch this error in all cases would be preferred.

altendky
  • 4,176
  • 4
  • 29
  • 39
  • Have you tried `-Wall` with GCC? – Theodoros Chatzigiannakis Jan 31 '14 at 17:53
  • 2
    Actually I think such a like in a header file would be incorrect, it would define a new 10-element array in every translation unit it's included in (and violate the one definition rule along the way). I think `extern` should fix that. –  Jan 31 '14 at 17:54
  • @delnan Please post an answer. – unwind Jan 31 '14 at 17:54
  • @unwind Why? It doesn't answer the question AFAIK -- after adding `extern` the problem OP describes should persist. –  Jan 31 '14 at 17:54
  • @delnan Good catch. It was an erred exampled. Corrected. – altendky Jan 31 '14 at 17:55
  • @TheodorosChatzigiannakis `-Wall` was already set for my builds. That may be a good indication that GCC won't do it. `-pedantic` did not trigger anything either. – altendky Jan 31 '14 at 18:03
  • Is the `int` (size 2) within a function or outside of it? Likewise for the `extern`? I would need to see the actual structure of the source to have an idea of what's going on. If this is an array to be shared amongst different functions and even different source files, there needs to be one actual place that memory is allocated (CSECT) and everything else is a DSECT pointing to it. It's entirely possible that your code is syntactically legal (yet incorrect). – Phil Perry Jan 31 '14 at 18:07
  • 1
    If you include the header in the file that defines the variable, you should get a 'mismatched type' error. That would certainly be true under modern GCC (I used 4.8.2 on Mac OS X 10.9.1 with no warning options to verify that it fails); it should apply to GCC 3.4.5 too. If you aren't using the header to ensure that the definition matches the declaration, you're misunderstanding the value of headers for cross-checking. You should also aim to upgrade to a more modern compiler (but I'm sure you have reasons why you can't — thank you for including the compiler version info in the question). – Jonathan Leffler Jan 31 '14 at 18:50
  • You might care to look at [How do I share a variable between source files in C?](http://stackoverflow.com/questions/1433204/) – Jonathan Leffler Jan 31 '14 at 18:52
  • Given the deleted answer by the OP, which comments _'In the actual code (proprietary embedded and generated by a tool) the header extern's are #ifdef'ed and the default was to not create them when the .c included the .h. When I set this option it did produce the warnings (errors actually) that I had wanted.'_ I think this falls into the 'trivial typo' category of reasons for closure (_While similar questions may be on-topic here, this one was resolved in a manner unlikely to help future readers_). – Jonathan Leffler Feb 03 '14 at 18:10
  • @JonathanLeffler Yes, I failed to appropriately isolate my issue and now I fail to see the correct way to close it... I agree with your comment on it being a typo but don't see that option when I select 'close'. – altendky Feb 03 '14 at 20:11
  • 1
    It appears under 'off topic'…at least for people with enough reputation. – Jonathan Leffler Feb 03 '14 at 20:11

0 Answers0