Info 768: global struct member 'xxx' 
(line yyy, file zzz.h) not referenced

Is there any possibility to have a single line 
suppression or selective suppression for this 
message in line yyy 
or near line yyy in file zzz???

It is “critical” software and there usually 
should be no unused struct members.
For those which are unused nevertheless, 
it should be explained that they are unused 
and why they are unused 
in the same file at the location of 
the struct in the header file. 
This is also requested to legitimize
the lint suppression with 
the smallest possible scope. 

I tried 
  /*lint !e768 */ 
  /*lint -esym(768,xxx) */ 
  /*lint --esym(768,xxx) */ 
in file zzz.h before and inside the struct

but the only thing what works is
/*lint -esym(768,xxx) */ in the *.lnt-file.

(lob file processing is used)

Hi Olaf, 

/*lint !e768 */ on the line of the symbol's declaration wouldn't 
work because 768 is given during Global Wrap-up processing.  
Single-line suppressions are supposed to be used for messages 
that would be given during general and specific walks (that is, at 
the time that lint actually processes the line containing the 
comment).  

This:

/*lint -esym(768,xxx) */

*should have* worked, assuming that xxx is really a name of the 
form: 

A::m

...where A is the tag-name of a struct and m is a member name 
of that struct. That is, in real life, the option should look like: 

/*lint -esym(768,A::m) */

... and the message from lint should likewise use that exact 
name (that is, "A::m", not just "m"). 

This should have worked regardless of where you put the 
comment in the source.  I'm surprised that it didn't work for you.  
Can you send us a reproducer?

Finally,

/*lint --esym(768,xxx) */ 

Should work.  It's an undocumented form (and therefore its 
precise semantics are subject to change), but currently, it means 
exactly the same thing as the single-hyphen form.

Hi James,

It is ANSI C90. So I didn’t think about any ::

/*lint –esym(768,reserved) */
typedef struct {
  UINT_BITFIELD   cmd:4;
  UINT_BITFIELD   flag:1;
  UINT_BITFIELD   sema:1;
  UINT_BITFIELD   reserved:2;
} teststruct;
with xxx = cmd, flag, sema or reserved

using /*lint -esym(768,xxx) */ 
works neither in *.h-file nor in the *.c-file 
if the global wrap up is produced via *.lob-
Files. 
If processing is done via *:c files without any 
*.lob 
it is both OK either in *.c-file or in the *.h-
file. 
I’m afraid the suppression was lost via lob file 
processing. 

Reproducing is possible with struct in L768.H 
file 
and include of L768.H in L768.C File.
First invocation of lint producing L768.LOB from 
L768.C 
and second invocation via *.LOB. 
If necessary, I’ll send you all files and all 
output via email. 

It seems similar to:
http://www.gimpel.com/Discussion.cfm?ThreadID=1087

Ah, I see -- so the example boils down to something much 
simpler: 

//[begin file t.cpp]
int i; //lint -esym(714,i)
//[end file t.cpp]

$ lint t.cpp 
FlexeLint for C/C++ (U32) Vers. 8.00t, Copyright Gimpel 
Software 1985-2005

--- Module:   t.cpp (C++)

--- Global Wrap-up

Note 900: Successful completion, 0 messages produced


==========================

$ lint -zero -oo t.cpp 
FlexeLint for C/C++ (U32) Vers. 8.00t, Copyright Gimpel 
Software 1985-2005

--- Module:   t.cpp (C++)
Outputting to file t.lob

--- Global Wrap-up

Note 900: Successful completion, 0 messages produced
==========================
 $ lint t.lob
FlexeLint for C/C++ (U32) Vers. 8.00t, Copyright Gimpel 
Software 1985-2005

--- Object:   t.lob

--- Global Wrap-up

Info 714: Symbol 'i' (line 3, file t.cpp) not referenced
t.cpp  3  Info 830: Location cited in prior message
Note 900: Successful completion, 2 messages produced

(My LINT environment variable points to a config file that turns 
on message 900, among other things.)

The reason why the suppression didn't take effect is simply that 
suppressions aren't stored in .lob files.  I've put in a feature 
request for it.  In the meantime, the thing to do is probably to 
use your favorite scripting language to extract Lint options from 
the source code and dump them into a .lnt file that you'll use 
when running Lint against .lob files.

Thanks for bringing this to our attention!

> is simply that suppressions 
> aren't stored in .lob files

treat this statement with care.
remember ThreadID=1087

-misra(1)
/*lint -esym(960,110) doesn't work at file scope*/
this one is lost during lob-file-processing
BUT
-misra(2) 
/*lint -esym(960,18.4)*/
this one works !!!!!!!!!!!!!!!!!!!!

I'm not able to elicit message 960 for rule 18.4 when linting a 
lob file that was created from a T.U. that defines a union.   E.g., 
if I have a T.U.: 

/*lint
 +e960
 -misra(2)
 */

union U { int i; char* s; }; 
int main( void ) { return 0; }

... and then lint with: 

lint -oo -zero t.c 

... I get the message that I've violated rule 18.4 and the file 't.lob' 
is created.  If I then run: 

lint -misra(2) +e960 t.lob

... I do not receive the 18.4 violation message.  The -esym() 
option cannot be said to have suppressed the message during 
the time when we read t.lob, because at that time, there was no 
message to suppress.  In fact, this message is only given when 
we scan the 'union' token, so there's no way we would issue it 
while reading a .lob file.   Likewise, the message for rule 110 is 
given when we parse the program text, not when we read .lob 
files, so neither of those -esym() options should have any effect 
when reading .lobs.

(Frankly, I can't see the utility in receiving the message at lob-
reading time.  The message can be given in the same run where 
we produce the .lob file, so would it not be redundant for us to 
issue it again when we read the .lob?)

Oh, by the way: the reason why we didn't scope the struct 
member names in your example had nothing to do with dialect.  
(For the purpose of producing diagnostics, the scope operator 
(::) is pretty useful when referring to symbols in either 
language.)  

It's because your struct is tagless.  We can't rightly say that 
'reserved' is a member of 'teststruct', because there's no explicit, 
implied, or "in-the-sprit-of-the-langauge" rule that requires 
typedef names to have the same type across translation units 
(although it's usually considered "good practice").  On the other 
hand, when you use a struct tag name, we can apply the ODR 
and always expect that the structure definition will be the same.