Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #108120

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

Show all headers | View raw

On 13/04/17 00:55, supercat@casperkitty.com wrote:
> On Wednesday, April 12, 2017 at 5:20:37 PM UTC-5, David Brown wrote:
>> On 11/04/17 17:37, supercat wrote:
>>> If some compiler Y were identical to X except that it *documented* that
>>> "void main()" would work as it does in compiler X, then "void main()" would
>>> not be UB on compiler Y, but I see no reason that compiler Y shouldn't be
>>> conforming.
>>
>> You are still making no sense.  The implementation's way of handling
>> main() cannot be undefined behaviour - it is defined by the
>> implementation.  It might not conform to the C standards, but it can
>> never be undefined behaviour.
>
> The Standard defines the behavior for "int main(void)".  Where does it define
> any behavior for "void main(void)"?

I still don't get your hang-up about main() here, or your idea of the 
implementation being undefined behaviour.

The standards make it clear that program lifetime objects without 
explicit initialisation are zero'ed before the start of the program.  A 
freestanding C implementation can use whatever it likes as a start 
function - it can be "void main(void)", or "int reset(int)", or whatever 
it wants.  That is for the implementation to decide.  And if the 
programmer uses a form that is not specified by the implementation, then 
/that/ is undefined behaviour.

>
>> The question /really/ is, is it better to have a compiler:
>>
>> 1. Accept normal C and work the way everyone expects a C compiler to
>> work, allowing good and safe code to work correctly.  For some bits of
>> code, extension keywords or other implementation-specific features must
>> be used for optimal efficiency due to limitations of the target
>> architecture.
>>
>> or
>>
>> 2. Change important keywords of C to work in a substantially different
>> way, breaking correct code, because you think it would be easier for
>> beginners to understand this non-standard variant of C.
>
> No implementation will be able to run all correct code.  Each of the above
> approaches will run some programs that the other would not.  If some
> particular program will run usefully on the second approach, but would be
> unable to run using the first because of resource constraints, then I would
> suggest the second implementation would be more useful for the purpose of
> running that program.
>

Clearly it is possible to write code that can be run by the second 
implementation.  And clearly it is possible to write code that /cannot/ 
be run by the first implementation (just use enough constant data to 
overflow the ram in the microcontroller, avoiding the 
implementation-specific features needed to keep that constant data in 
flash).  But with the second implementation, standard programs that 
should be able to run (i.e., they are within the limitations of ram, 
rom, etc.), will compile cleanly but have different and incorrect 
behaviour compared to other conforming C implementations.  And that is 
the vital difference.

>> I agree that for some targets, it can be better to make some breakage to
>> C standards conformity.  But that should be kept to the absolute
>> minimum, be well documented, not break working code silently, and
>> preferably require a command-line switch to activate it or give warnings
>> about the odd behaviour.  It is reasonable, for example, for a C
>> implementation on a small 8-bit micro to make "double" limited to 32
>> bits.  It is /not/ reasonable to change the meaning of a keyword like
>> "const" to mean something subtly different, or to skip the zeroing of
>> uninitialised data.
>
> Most code won't need to convert a const-qualified pointer to a non-qualified
> pointer and then later convert back to a const-qualified pointer and access
> ROM/flash.  While a compiler should have an option to make all pointers use
> the same format as const-qualified pointers, I would not expect that most
> programs would work better with that option disabled.

The problem is non-const data accessed through const qualified pointers. 
  And such code /is/ common:

extern int average(int noOfSamples, const int * pSamples);
int x[10];
int av = average(10, x);


>
>>> That's certainly a reasonable approach, and a quality compiler should
>>> probably offer it as an option, but for many purposes a non-conforming
>>> option that works like other compilers do may be more useful.
>>
>> No, the "break the const keyword" approach is not more useful.
>
> If a program would work correctly with or with or without that option, but
> be faster without, or if it would work correctly with that option but would
> not fit in the available code space without it, in what way would that
> option make the implementation more useful for purposes of running that
> program?

A C compiler should not be made to work only with a particular 
specialised variety of programs!  A compiler sold as a "C Compiler" 
should be made to correctly compile as many valid C programs as possible 
given the limitations of the target.

>
> If the Atmel can't use a const-qualified pointer to access RAM (I've not
> used that platform, so I don't know if it can), that would be a horribly
> broken abuse of the "const" keyword,

Exactly.  (The limitation is for one particular compiler for the AVR, 
not for all compilers for it.)

> but if "const"-qualified pointers
> can access either while unqualified pointers are limited to RAM, most
> programs would not be affected by an inability to round-trip const pointers
> through unqualified pointers nor directly use unqualified pointers to
> access ROM.
>

Certainly that would be much less of a problem.

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

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