Re: How to fix: [-Wformat-nonliteral]

From	David Brown <david.brown@hesbynett.no>
Newsgroups	comp.lang.c
Subject	Re: How to fix: [-Wformat-nonliteral]
Date	2017-04-11 00:18 +0200
Organization	A noiseless patient Spider
Message-ID	<och05v$le7$1@dont-email.me> (permalink)
References	(2 earlier) <87mvbsv0tq.fsf@bsb.me.uk> <oc85gk$s8g$1@dont-email.me> <87h920ukud.fsf@bsb.me.uk> <ocai4l$lc8$1@dont-email.me> <4f2b7ab6-2fa0-4fc9-aea2-7912adf068b5@googlegroups.com>

Show all headers | View raw

On 10/04/17 22:52, supercat@casperkitty.com wrote:
> On Saturday, April 8, 2017 at 6:42:10 AM UTC-5, David Brown wrote:
>> I can't remember the details of the tools I had at that time.  But in
>> general, I have in the past used quite a number of compilers (and
>> libraries) that intentionally or unintentionally (i.e., toolchain bugs)
>> do not follow the rules of C.  Some of the fun ones include:
>>
>> Floating point only working for local variables, not statically
>> allocated variables.
>
> I can't think of any implementations with that restriction, though I recall
> one that didn't support floating-point types at all.  It might possibly have
> allowed floating-point computations in constant expressions, but if it did I
> never used that feature.  I can't think why only local variables could use
> floating-point, though.

It is highly unlikely that anyone would guess that situation - it was an 
odd one, due mainly to issues with the hardware on the board that meant 
access to external memory had problems, while the stack and local 
variables were on the small internal memory on the device.

>
>> Uninitialised data that is not zeroed before main().
>
> For some embedded systems, it's essential to have some storage which is
> not zeroed before main, since various events may cause the system to
> reset and re-execute main() from scratch but with the contents of memory
> undisturbed.  If a controller has a "power-on" hardware flag which gets
> set by hardware whenever the voltage falls below a safe operational level
> and can only be cleared by software when voltage is adequate for operation,
> software can use that flag to manually initialize things that need to be
> initialized.

If you are relying on the state of memory being preserved at the start 
of main(), then you are working outside of standard C.  There are three 
common ways to deal with that.  One is to use named sections for "no 
initialisation" data areas for the variables of interest.  Another is to 
fake that by using manually assigned addresses to ram that is outside of 
the areas used by C.  And a third is to put the relevant C code in 
sections or hooks for execution before the C runtime library clears the 
bss and sets up the data section.  These are, of course, all 
implementation-specific - but they will be clear and reliable methods.

There are some compiler manufactures (such as Texas Instruments) that 
seem to think it is a good idea not to zero out uninitialised data (the 
bss section) before main().  Their idea is that this makes startup 
faster, and that because their hardware watchdogs are often enabled out 
of reset (a questionable idea at best), they don't zero the bss to avoid 
a risk of the watchdog triggering before main() starts.  It is a silly 
idea, and has lead to much wailing and gnashing of teeth for developers 
who find their programs behaving differently from run to run until they 
learn of this "feature".

>
> The Standard regards as implementation-defined the nature and means by which
> an embedded program starts operation.  It allows systems to define alternate
> function signatures and startup patterns; I don't know whether a conforming
> implementation could refrain from initializing global variables before it
> called "int main(void)", but I think it document the behavior of "void main()"
> as being similar to "int main(void)" but without zero-initialization.

They /could/ document it - but it would then not be C, because C 
requires this zero initialisation (5.1.2, 6.7.9 p 10).  In at least one 
of TI's compiler manuals, I did see that it was documented - as a tiny 
footnote, deep within the middle of the manual, with a comment that the 
behaviour broke with the C standards.

>
>> "const" being treated as meaning "in flash", and using different
>> assembly instructions for access than ram data - thus casting a "char *"
>> pointer to a "const char *" pointer will break the program.
>
> I somewhat prefer the approach of using different qualifiers for things which
> are guaranteed to be in RAM, guaranteed to be in code space, or might be in
> either, but using "const" could be considered a practical approach even though
> it is non-conforming.

It was a terrible approach, because it silently broke code that used the 
good programming practice of using const pointers when a function does 
not change the data pointed at.  It is far better to use explicit 
extensions, such as a "flash" keyword, for that purpose.

>
>> Integer promotion rules aimed at being "helpful" to the programmer,
>> rather than following the standards.
>
> The Standard allows implementations some flexibility to be helpful with
> regard to signed integers.  Unsigned integer types have rigidly-defined
> behavior.
>

No, it does not allow such flexibility.  If you have a uint8_t or an 
int8_t, and you perform arithmetic, it is to be promoted to "int" before 
carrying out the operation.  A compiler that does not do that 
(logically, at least - it does not actually have to do the 16+ bit 
operations if only parts of the results are used) is a broken compiler 
that causes confusion and means code that should be portable and 
testable on different targets, no longer works.

In most cases, these things are done in the mistaken belief that the 
compiler writer is helping users, or making the tool easy for beginners, 
or making a more "natural" language for the particular target.  But it 
means that people who know what they are doing, are going to have 
trouble because the compiler does not work the way they expect.  And 
people who /don't/ know what they are doing, are going to have trouble - 
because they will refer to books, websites, and expert opinions which 
are all incompatible with the "helpful" compiler.

Thread

How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-07 12:20 +0430
  Re: How to fix: [-Wformat-nonliteral] Barry Schwarz <schwarzb@dqel.com> - 2017-04-07 01:28 -0700
  Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 11:58 +0200
    Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 11:43 +0100
      Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 13:35 +0200
    Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 13:50 +0100
      Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 15:54 +0200
        Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-07 19:35 +0100
          Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-08 13:41 +0200
            Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 13:52 -0700
              Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-11 00:18 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 15:43 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-10 16:10 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-10 16:26 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-11 11:33 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-11 08:37 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-13 00:20 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-12 15:55 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-12 18:17 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-14 12:27 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 11:57 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 18:08 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-17 09:38 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-12 18:13 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 07:37 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 08:43 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 11:24 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 11:49 -0700
                Re: How to fix: [-Wformat-nonliteral] Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 14:43 -0500
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 13:26 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-13 13:32 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 14:27 -0700
                Re: How to fix: [-Wformat-nonliteral] Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 17:39 -0500
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 16:16 -0700
                Re: How to fix: [-Wformat-nonliteral] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:53 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-13 13:19 -0700
                Re: How to fix: [-Wformat-nonliteral] Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:49 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 18:14 +0200
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-17 11:54 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-17 22:41 +0200
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-17 15:02 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-14 12:40 +0200
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 12:10 -0700
                Re: How to fix: [-Wformat-nonliteral] Keith Thompson <kst-u@mib.org> - 2017-04-14 13:22 -0700
                Re: How to fix: [-Wformat-nonliteral] supercat@casperkitty.com - 2017-04-14 17:14 -0700
                Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-13 00:20 +0200
      Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-07 20:29 +0430
        Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-07 18:42 +0200
          Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 08:04 +0430
            Re: How to fix: [-Wformat-nonliteral] Richard Heathfield <rjh@cpax.org.uk> - 2017-04-08 07:51 +0100
              Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 12:11 +0430
                Re: How to fix: [-Wformat-nonliteral] Richard Heathfield <rjh@cpax.org.uk> - 2017-04-08 11:38 +0100
                Re: How to fix: [-Wformat-nonliteral] Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-08 18:52 +0100
            Re: How to fix: [-Wformat-nonliteral] David Brown <david.brown@hesbynett.no> - 2017-04-08 13:48 +0200
              Re: How to fix: [-Wformat-nonliteral] MehdiAmini <atorrses@gmail.com> - 2017-04-08 20:34 +0430

csiph-web