Re: printf-like function.

[paulf]

- Original Message -
> You should look at https://en.cppreference.com/w/cpp/utility/format
> and the reference implementation https://fmt.dev/
> 
> There's no need for compiler magic.

This is fairly common. Qt just uses placeholders %1 %2 etc.

Also from memory, Stroustup's C++ Programming Language 4e has an example of a 
typesafe printf. (My copy is at work so I can't check).

A+
Paul

Re: GCC 10 and Coverity Scan

[paulf]

- Original Message -
> Hi
> 
> This isn't the perfect place to ask this but someone here may have
> insight.
> And getting help with Coverity Scan directly isn't easy. I'm hoping
> someone
> here has some insight or can point me to someone who does.
> 
> We have been using Coverity Scan a long time with RTEMS. It works
> fine
> using gcc 7.5.0 but Coverity appears to have a problem with gcc 10.
> This is
> what --version reports for both toolchains:
> 
> $ ~/rtems-work/tools/5/bin/sparc-rtems5-gcc --version
> sparc-rtems5-gcc (GCC) 7.5.0 20191114 (RTEMS 5, RSB 5 (cbae90a5817a),
> Newlib 7947581)
> 
> $ sparc-rtems6-gcc --version
> sparc-rtems6-gcc (GCC) 10.2.1 20201028 (RTEMS 6, RSB
> 4c5af1f7c1553e53739ca4e9892de26924ec2b3f, Newlib fcaaf40)

Hi

Putting aside politics (I used to work for Synopsys and now work
for a competitor, but not at all in the domain of static
analysis), I'll take a stab.

When you switched compilers, did you re-run cov-configure?

A+
Paul

Re: Solaris issues

[paulf]

- Original Message -
> Hi Paul,
> 

[Build issue on Solaris]

> 
> this is PR target/85994.  For the moment, you can just touch compare
> and
> resume the build.  Trivial patch forthcoming...

Hi Rainer

This worked a treat, thanks.

A+
Paul

Re: Solaris issues

[paulf]

- Original Message -
> Hi Paul,

[snip - lots of .rodata sections]
 
> 
> those sections are in libstdc++.so.  They can be found in the input
> objects used to created libstdc++.so on Linux and Solaris alike, due
> to
> the use of -fdata-sections (via SECTION_FLAGS) in libstdc++.
> 
> However, on Linux gld is usually used, which is driven by linker maps
> that often coalesce sections based on section name patters.  OTOH,
> Solaris ld (which I assume you used) usually doesn't care about
> section
> names, but does the bulk of its work based on section attributes
> alone.
> The ultimate result is the same (all .rodata* sections land in the
> read-only text segment at runtime), since sections don't matter to
> the
> kernel, only segments do.

I am indeed using Solaris ld - configured with "--without-gnu-ld 
--with-ld=/usr/ccs/bin/ld"


> You can read about the gory details on how Solaris ld does that part
> of
> its work at
> 
> https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc

I'll have a look. I probably read an older version in the distant past.

> (and doubtlessly somewhere on linker-aliens.org ;-)
> 
> In Solaris 11.4, there were some changes here for better GNU (bug)
> compatibility, so there's only a single .rodata section here.
>  However,
> there's nothing wrong with how Solaris ld behaved before: I'd claim
> this
> is a scalability bug in valgrind: ELF objects can have very large
> numbers of sections for all sorts of legitimate resons, so it needs
> to
> cope with them.
> 
>   Rainer

Hmm OK. Do you know what change caused this?

Since there's a patch for Valgrind to fix it, it looks like that would be the 
best solution.

A+
Paul