2

I'm attempting to use SourceTrails (https://www.sourcetrail.com/) to analyze embedded c from the MPLAB CX8 compiler. It's not entirely trouble-free, as the compiler uses a number of custom features, not found in the C standard.

One of these is the use of short long to indicate 24-bit variables in global includes, such as:

extern volatile unsigned short long     TBLPTR;

SourceTrail (using clang) shows this error: cannot combine with previous "short" declaration specifier.

For the analysis only, I'd like to specify something like on the top of the global include:

#define "short long" long

but obviously, this fails!

I might have to perform a search and replace, but it would be great if there were a simpler method?

fsteff
  • 543
  • 5
  • 19
  • 1
    You already know what actually works: a real macro, or a typedef. *in the headers*, with proper guards. This again is something that is *not* standard C. – Antti Haapala -- Слава Україні Oct 07 '20 at 09:17
  • Would it not be smarter to save the current version (either with VCS or make a copy) and then change every `short long` into ? – 12431234123412341234123 Oct 07 '20 at 12:38
  • @12431234123412341234123 These are the include files that came with the compiler, so they are not as such part of the project although the compiler relies on them. My current approach is to make a copy of the entire includes folder, use a script to modify the files and then setup a different global includes folder in Sourcetrail, and with this approach I now at about 50 fatal errors, down from about 5000. – fsteff Oct 07 '20 at 22:27

1 Answers1

2

You can use something like:

#define short int

short long variables will now be long, at least in mainstream compilers like gcc and clang.

Any short variables will now be int, the side effect is that short int declarations will now cause invalid combination error.


The solution found by the OP was to use #define short which will effectively remove short from the type declaration making it long.

The side effect is that variables declared short will have no type or storage class, and as such, will default to int.

In compilers like clang or gcc the type int long will default to long effectively making both solutions possible, minding the different side effects.

anastaciu
  • 23,467
  • 7
  • 28
  • 53
  • 1
    This will work for *as `long`* (no pun intended :P) as no one types `short int` anywhere :D – Antti Haapala -- Слава Україні Oct 07 '20 at 09:16
  • But they don't want to change the type. `short long` variables should be the type `short long`. This is a non-standard extension that can't be "fixed". – Lundin Oct 07 '20 at 09:28
  • Yes, @Lundin, unfortunately, I based my answer on the fact that the OP was trying something like `#ddefine "short long" long`, that of course will also not work, there is no perfect solution for this, as you pointed out. – anastaciu Oct 07 '20 at 09:41
  • @Lundin in that sense a duplicate of the previous [Q](https://stackoverflow.com/questions/64223961/configure-sourcetrail-to-accept-embedded-c-c-header-files-with-syntax/64224016#64224016) – Antti Haapala -- Слава Україні Oct 07 '20 at 09:45
  • @AnttiHaapala I saw this as a different question, albite with the same premiss: The MPLAB compiler. – fsteff Oct 07 '20 at 10:57
  • 1
    I ended up with `#define short`, which effectively changes the 24-bit `short long` into a 32-bit `long`. Your proposed `#define short int` would change the type into an unsupported `int long` type. – fsteff Oct 09 '20 at 08:29
  • 1
    @fsteff, I'm glad you solved it. I'm not familiar with mplab but in a "normal" c compiler `int long` is exactly the same as `long`, keep in mind that with your solution variables declared `short` will now have no type and will default to `int`. I'll appended this to my answer with context, this may be a good Q&A for future users. – anastaciu Oct 09 '20 at 08:53
  • 1
    Thank you. I summarized everything here: https://stackoverflow.com/questions/64278487/enable-usage-of-modern-code-analysis-tools-on-old-ish-embedded-c-c-code – fsteff Oct 09 '20 at 10:49