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

Groups > comp.lang.c > #120518 > unrolled thread

const and the C type system

Back to article view | Back to comp.lang.c

Contents

  const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-28 19:51 -0700
    Re: const and the C type system Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-09-28 21:32 -0600
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 05:45 -0700
        Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 14:05 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:17 -0700
      Re: const and the C type system asetofsymbols@gmail.com - 2017-10-01 22:35 -0700
    Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-29 10:59 +0200
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:06 -0700
        Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 14:24 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 06:52 -0700
            Re: const and the C type system jameskuyper@verizon.net - 2017-09-29 09:17 -0700
              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 10:50 -0700
                Re: const and the C type system jameskuyper@verizon.net - 2017-09-29 11:06 -0700
                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 11:27 -0700
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 13:13 -0700
              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 13:31 -0700
          Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-29 09:10 -0700
            Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-29 18:33 +0100
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 11:10 -0700
          Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-09-30 08:29 +1300
          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-30 18:48 +0200
            Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 18:44 +0100
              Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 09:12 +1300
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 21:50 +0100
                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 10:10 +1300
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 23:17 +0100
                      Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 11:38 +1300
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 00:44 +0100
                          Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-01 14:33 +1300
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 10:42 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 19:58 +0200
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:30 +0100
                                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-02 17:48 +1300
                                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 11:14 +0100
                                      Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-02 23:22 +1300
                              Re: const and the C type system Richard Damon <Richard@Damon-Family.org> - 2017-10-01 13:58 -0400
                      Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 18:20 +0200
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 18:41 +0100
                          Re: const and the C type system supercat@casperkitty.com - 2017-10-01 12:03 -0700
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:05 +0200
                            Re: const and the C type system supercat@casperkitty.com - 2017-10-01 15:58 -0700
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 09:56 +0200
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 00:24 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:20 +0200
                                Re: const and the C type system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-10-02 06:03 -0700
                                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 06:34 -0700
                                Re: const and the C type system supercat@casperkitty.com - 2017-10-02 23:38 -0700
                        Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 13:03 -0700
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:12 +0200
                    Re: const and the C type system supercat@casperkitty.com - 2017-10-01 11:12 -0700
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 13:48 +0200
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 14:13 +0100
                    Re: const and the C type system supercat <flatfinger@casperkitty.com> - 2017-10-01 10:32 -0700
                Re: const and the C type system supercat@casperkitty.com - 2017-09-30 13:52 -0700
              Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-30 13:35 -0700
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-09-30 21:58 +0100
                  Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 12:03 +0100
                Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 14:00 -0700
                  Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-09-30 15:33 -0700
                  Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 12:45 -0700
              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 13:13 +0200
                Re: const and the C type system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-10-01 05:22 -0700
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 20:06 +0200
                    Re: const and the C type system supercat@casperkitty.com - 2017-10-01 12:16 -0700
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:01 +0100
                      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-01 13:21 -0700
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:50 +0100
                          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 05:35 -0700
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 14:01 +0100
                              Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 06:29 -0700
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 15:19 +0100
                      Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 23:19 +0200
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 22:33 +0100
                          Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 00:10 +0200
                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 14:13 +0100
                  Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-01 22:46 +0200
                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 21:57 +0100
                      Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-01 14:09 -0700
                        Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-01 23:54 +0100
                          Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-01 19:12 -0700
                            Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 11:36 +0100
                              Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:45 +0200
                              Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-02 09:40 -0700
                                Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 19:33 +0100
                                  Re: const and the C type system scott@slp53.sl.home (Scott Lurndal) - 2017-10-02 19:09 +0000
                                  Re: const and the C type system Ian Collins <ian-news@hotmail.com> - 2017-10-03 08:12 +1300
                                    Re: const and the C type system bartc <bc@freeuk.com> - 2017-10-02 20:30 +0100
                                    Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-02 12:37 -0700
                                  Re: const and the C type system jadill33@gmail.com - 2017-10-02 12:49 -0700
                                Re: const and the C type system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-10-06 20:47 +0000
                                  Re: const and the C type system Keith Thompson <kst-u@mib.org> - 2017-10-06 15:41 -0700
                            Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-10-02 12:42 +0200
                Re: const and the C type system Gareth Owen <gwowen@gmail.com> - 2017-10-01 21:18 +0100
            Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-30 12:22 -0700
        Re: const and the C type system David Brown <david.brown@hesbynett.no> - 2017-09-30 18:44 +0200
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 07:01 -0700
        Re: const and the C type system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 20:18 +0100
          Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-09-29 12:40 -0700
            Re: const and the C type system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-29 21:28 +0100
    Re: const and the C type system fir <profesor.fir@gmail.com> - 2017-09-29 08:21 -0700
      Re: const and the C type system fir <profesor.fir@gmail.com> - 2017-09-29 08:38 -0700
    Re: const and the C type system John Bode <jfbode1029@gmail.com> - 2017-10-02 09:20 -0700
      Re: const and the C type system Thiago Adams <thiago.adams@gmail.com> - 2017-10-02 09:53 -0700
      Re: const and the C type system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-10-09 13:27 +0000

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#120684

On 02/10/2017 03:12, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> OK, I understand: this is a problem at file-scope. And it's the same
>> problem that stops you using such a value for a fixed array bound or for
>> a case-label.
> 
> Do you understand that the initializer for a static object must be a
> constant expression either at file scope or at block scope?  You say you
> didn't get a complaint from gcc.  I'm skeptical.  Did you try that exact
> code, or did you omit the "static" keyword?  Please try it again with
> the exact code that you posted above.

c:\c>type c.c
#include <stdio.h>

int main(void){
   static const int a = 100;
   static const double b = 200.1;
   static const double c = a+b;
   static const long long int d = 5000000000;
   static const double e = d*c;
   static const unsigned long long f = 0xffffffffffffffff;

   printf("a=%d\n",a);
   printf("b=%f\n",b);
   printf("c=%f\n",c);
   printf("d=%lld\n",d);
   printf("e=%f\n",e);
   printf("f=%llX\n",f);
}

c:\c>\tdm\bin\gcc -O3 c.c

The problem seems to be the -O3 option. Without it, gcc will complain as 
you say. So it's a gcc problem.

No doubt you guys will again try to twist things around and say that 
it's a Bart problem, but the fact reminds that with -O3, nothing was 
said, so that I genuinely thought a,b,c,d,e,f were all just synonyms for 
their values. If I specify this lot, it still says nothing about it 
(I've no idea what those format warnings are about):

c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c

c.c: In function 'main':
c.c:14:10: warning: unknown conversion type character 'l' in format
            [-Wformat=]
    printf("d=%lld\n",d);
           ^
c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]
c.c:16:10: warning: unknown conversion type character 'l' in format
            [-Wformat=]
    printf("f=%llX\n",f);
           ^
c.c:16:10: warning: too many arguments for format [-Wformat-extra-args]

> The point is that static objects are created and initialized before
> main() begins, and C has no mechanism for running code at that point.

So how does gcc manage it with -O3? The above program worked.

>> (But it demonstrates my concern that using static/const rather than a
>> dedicated feature, you might not be entirely sure what is happening.
>> With I tried it and it worked, I thought those names were genuinely
>> constants.)
> 
> Knowing that "const" doesn't mean "constant" might have prevented that
> misunderstanding.

THIS IS THE WHOLE POINT! You're TRYING to use 'const' to implement 
something equivalent to (my) 'constant'.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#120686

On 02/10/17 12:36, bartc wrote:
> On 02/10/2017 03:12, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
> 
>>> OK, I understand: this is a problem at file-scope. And it's the same
>>> problem that stops you using such a value for a fixed array bound or for
>>> a case-label.
>>
>> Do you understand that the initializer for a static object must be a
>> constant expression either at file scope or at block scope?  You say you
>> didn't get a complaint from gcc.  I'm skeptical.  Did you try that exact
>> code, or did you omit the "static" keyword?  Please try it again with
>> the exact code that you posted above.
> 
> c:\c>type c.c
> #include <stdio.h>
> 
> int main(void){
>   static const int a = 100;
>   static const double b = 200.1;
>   static const double c = a+b;
>   static const long long int d = 5000000000;
>   static const double e = d*c;
>   static const unsigned long long f = 0xffffffffffffffff;
> 
>   printf("a=%d\n",a);
>   printf("b=%f\n",b);
>   printf("c=%f\n",c);
>   printf("d=%lld\n",d);
>   printf("e=%f\n",e);
>   printf("f=%llX\n",f);
> }
> 
> c:\c>\tdm\bin\gcc -O3 c.c
> 
> The problem seems to be the -O3 option. Without it, gcc will complain as
> you say. So it's a gcc problem.
> 
> No doubt you guys will again try to twist things around and say that
> it's a Bart problem, but the fact reminds that with -O3, nothing was
> said, so that I genuinely thought a,b,c,d,e,f were all just synonyms for
> their values. If I specify this lot, it still says nothing about it
> (I've no idea what those format warnings are about):
> 

-O1 is enough to get the effect.  I think this might be a
non-conformance bug in gcc - but I will leave it to Keith to say that
(he has a better understanding of these subtleties than I do).
Certainly it is a surprise to find error messages when compiling with
optimisation disabled, and none when optimisation is enabled.

[toc] | [prev] | [next] | [standalone]

#120701

bartc <bc@freeuk.com> writes:
> On 02/10/2017 03:12, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> OK, I understand: this is a problem at file-scope. And it's the same
>>> problem that stops you using such a value for a fixed array bound or for
>>> a case-label.
>> 
>> Do you understand that the initializer for a static object must be a
>> constant expression either at file scope or at block scope?  You say you
>> didn't get a complaint from gcc.  I'm skeptical.  Did you try that exact
>> code, or did you omit the "static" keyword?  Please try it again with
>> the exact code that you posted above.
>
> c:\c>type c.c
> #include <stdio.h>
>
> int main(void){
>    static const int a = 100;
>    static const double b = 200.1;
>    static const double c = a+b;
>    static const long long int d = 5000000000;
>    static const double e = d*c;
>    static const unsigned long long f = 0xffffffffffffffff;
>
>    printf("a=%d\n",a);
>    printf("b=%f\n",b);
>    printf("c=%f\n",c);
>    printf("d=%lld\n",d);
>    printf("e=%f\n",e);
>    printf("f=%llX\n",f);
> }
>
> c:\c>\tdm\bin\gcc -O3 c.c
>
> The problem seems to be the -O3 option. Without it, gcc will complain as 
> you say. So it's a gcc problem.
>
> No doubt you guys will again try to twist things around and say that 
> it's a Bart problem,

No, it appears to be a bug in gcc.

C11 6.10p10 says:
    An implementation may accept other forms of constant expressions.
If gcc were taking advantage of that permission, the lack of a
diagnostic would necessarily be a conformance issue.  But the fact that
the behavior changes with optimization level make me think it's not a
deliberate feature.

So I think it's a bug in gcc; it's failing to diagnose a constraint
violation.  The commands you've shown don't actually demonstrate
a bug since gcc is not conforming by default, but when I compile
the same source with "gcc -std=c11 -pedantic -O3", it still fails
to produce a diagnostic.

>                      but the fact reminds that with -O3, nothing was 
> said, so that I genuinely thought a,b,c,d,e,f were all just synonyms for 
> their values. If I specify this lot, it still says nothing about it 
> (I've no idea what those format warnings are about):

OK, given that gcc didn't complain, it was probably reasonable for you
to assume that the code was valid.

> c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c
>
> c.c: In function 'main':
> c.c:14:10: warning: unknown conversion type character 'l' in format
>             [-Wformat=]
>     printf("d=%lld\n",d);
>            ^
> c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]
> c.c:16:10: warning: unknown conversion type character 'l' in format
>             [-Wformat=]
>     printf("f=%llX\n",f);
>            ^
> c.c:16:10: warning: too many arguments for format [-Wformat-extra-args]

That's weird.  What version of gcc are you using ("gcc --version")?

gcc 6.3.0 doesn't complain about the format strings.  An very
old version of gcc might not recognize the "%lld" format, which
was introduced in C99, but then it shouldn't have recognized the
"-std=c11" option.

>> The point is that static objects are created and initialized before
>> main() begins, and C has no mechanism for running code at that point.
>
> So how does gcc manage it with -O3? The above program worked.

Some expressions that are not constant expressions (as defined by the C
standard) can still be evaluated at compile time.  The value of a
const-qualfied object with a constant initializer is one such
expression.  A conforming compiler can generate code that reduces the
value of such an object to a constant, but it must still diagnose any
use of the name of such an object in a context that requires a constant
expression.  I suspect that gcc is internally failing to distinguish
between language-defined constant expressions and expressions that it
can evaluate at compile time; it's incorrectly discarding information
that it needs so it can produce a diagnostic.

[...]

>> Knowing that "const" doesn't mean "constant" might have prevented that
>> misunderstanding.
>
> THIS IS THE WHOLE POINT! You're TRYING to use 'const' to implement 
> something equivalent to (my) 'constant'.

I meant knowing that "const" doesn't mean "constant" *in C as it's
currently defined*.  For purposes of your test program, we're talking
about the requirements of C11, not of any proposed future changes.

C++ already uses "const" to implement something similar to your
proposed "constant".  As I've already said, the C++ feature blurs
the distinction between "const" and "constant", which is in my
opinion a drawback.  In spite of that, I think it's a worthwhile
addition just because it's useful functionality.  On the other
hand, I think that a limited form of C++'s more recent "constexpr"
might be a better solution (and, with the limitations I'm thinking
of, should be no more difficult to implement than your proposal).
Quite possibly if "constexpr" had been added to C++ sooner, there
would have been no need for it to change the semantics of "const".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#120703

On 02/10/2017 17:40, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> If I specify this lot, it still says nothing about it
>> (I've no idea what those format warnings are about):

>> c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c
>>
>> c.c: In function 'main':
>> c.c:14:10: warning: unknown conversion type character 'l' in format
>>              [-Wformat=]
>>      printf("d=%lld\n",d);
>>             ^
>> c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]

> That's weird.  What version of gcc are you using ("gcc --version")?
> 
> gcc 6.3.0 doesn't complain about the format strings.  An very
> old version of gcc might not recognize the "%lld" format, which
> was introduced in C99, but then it shouldn't have recognized the
> "-std=c11" option.

It was version 5.1.0 (tdm for Windows).

It can be reduced to this:

     printf("%lld",0LL);

then 'gcc -Wall -c' says 'unknown conversion type character 'l' in format'.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#120704

bartc <bc@freeuk.com> writes:
>On 02/10/2017 17:40, Keith Thompson wrote:

>> That's weird.  What version of gcc are you using ("gcc --version")?
>> 
>> gcc 6.3.0 doesn't complain about the format strings.  An very
>> old version of gcc might not recognize the "%lld" format, which
>> was introduced in C99, but then it shouldn't have recognized the
>> "-std=c11" option.
>
>It was version 5.1.0 (tdm for Windows).
>
>It can be reduced to this:
>
>     printf("%lld",0LL);
>
>then 'gcc -Wall -c' says 'unknown conversion type character 'l' in format'.

Version 4.8.3 compiles this without error or warning.

#include <stdio.h>

int
main(int argc, const char **argv, const char **envp)
{
    printf("%lld", 0LL);

    return 0;
}

I'd say that whoever built your version of gcc (tdm?) for windows
screwed it up somewhere along the way.

It also compiled just fine with gcc 4.5.3 under cygwin.

[toc] | [prev] | [next] | [standalone]

#120705

On 10/ 3/17 07:33 AM, bartc wrote:
> On 02/10/2017 17:40, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> If I specify this lot, it still says nothing about it
>>> (I've no idea what those format warnings are about):
>
>>> c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c
>>>
>>> c.c: In function 'main':
>>> c.c:14:10: warning: unknown conversion type character 'l' in format
>>>               [-Wformat=]
>>>       printf("d=%lld\n",d);
>>>              ^
>>> c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]
>
>> That's weird.  What version of gcc are you using ("gcc --version")?
>>
>> gcc 6.3.0 doesn't complain about the format strings.  An very
>> old version of gcc might not recognize the "%lld" format, which
>> was introduced in C99, but then it shouldn't have recognized the
>> "-std=c11" option.
>
> It was version 5.1.0 (tdm for Windows).
>
> It can be reduced to this:
>
>       printf("%lld",0LL);
>
> then 'gcc -Wall -c' says 'unknown conversion type character 'l' in format'.

Could this be a consequence of a windows library not supporting %lld?

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#120708

On 02/10/2017 20:12, Ian Collins wrote:
> On 10/ 3/17 07:33 AM, bartc wrote:

>> It was version 5.1.0 (tdm for Windows).
>>
>> It can be reduced to this:
>>
>>       printf("%lld",0LL);
>>
>> then 'gcc -Wall -c' says 'unknown conversion type character 'l' in 
>> format'.
> 
> Could this be a consequence of a windows library not supporting %lld?

The library (I assume msvcrt.dll) does support it, but maybe whatever 
code in gcc is responsible for checking formats think it doesn't.

I know there were some problems at one point, and you were supposted to 
use printf_mingw32() or something, but it seems alright now.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#120709

Ian Collins <ian-news@hotmail.com> writes:
> On 10/ 3/17 07:33 AM, bartc wrote:
>> On 02/10/2017 17:40, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>>
>>>> If I specify this lot, it still says nothing about it
>>>> (I've no idea what those format warnings are about):
>>
>>>> c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c
>>>>
>>>> c.c: In function 'main':
>>>> c.c:14:10: warning: unknown conversion type character 'l' in format
>>>>               [-Wformat=]
>>>>       printf("d=%lld\n",d);
>>>>              ^
>>>> c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]
>>
>>> That's weird.  What version of gcc are you using ("gcc --version")?
>>>
>>> gcc 6.3.0 doesn't complain about the format strings.  An very
>>> old version of gcc might not recognize the "%lld" format, which
>>> was introduced in C99, but then it shouldn't have recognized the
>>> "-std=c11" option.
>>
>> It was version 5.1.0 (tdm for Windows).
>>
>> It can be reduced to this:
>>
>>       printf("%lld",0LL);
>>
>> then 'gcc -Wall -c' says 'unknown conversion type character 'l' in format'.
>
> Could this be a consequence of a windows library not supporting %lld?

Ah, that's a possibility, though it would be an indirect consequence.
tdm-gcc <http://tdm-gcc.tdragon.net/> is based on MinGW-w64 with
some local patches.  Either the tdm developers or the MinGW-w64
developers might have modified gcc to force it *not* to recognize
"%lld".  (If the library actually does support "%lld", then this
is a bug but not a conformance issue.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#120710

On Monday, October 2, 2017 at 2:33:25 PM UTC-4, Bart wrote:
> On 02/10/2017 17:40, Keith Thompson wrote:
> > bartc <b...@freeuk.com> writes:
> 
> >> If I specify this lot, it still says nothing about it
> >> (I've no idea what those format warnings are about):
> 
> >> c:\c>\tdm\bin\gcc -O3 -std=c11 -Wall -Wextra -Wpedantic -c c.c
> >>
> >> c.c: In function 'main':
> >> c.c:14:10: warning: unknown conversion type character 'l' in format
> >>              [-Wformat=]
> >>      printf("d=%lld\n",d);
> >>             ^
> >> c.c:14:10: warning: too many arguments for format [-Wformat-extra-args]
> 
> > That's weird.  What version of gcc are you using ("gcc --version")?
> > 
> > gcc 6.3.0 doesn't complain about the format strings.  An very
> > old version of gcc might not recognize the "%lld" format, which
> > was introduced in C99, but then it shouldn't have recognized the
> > "-std=c11" option.
> 
> It was version 5.1.0 (tdm for Windows).
> 
> It can be reduced to this:
> 
>      printf("%lld",0LL);
> 
> then 'gcc -Wall -c' says 'unknown conversion type character 'l' in format'.

Have you tried printf("%I64d",0LL)?  Often times the Windows C library will support that modifier if %lld doesn't work.

[toc] | [prev] | [next] | [standalone]

#120755

On Mon, 2017-10-02, Keith Thompson wrote:
...
> C++ already uses "const" to implement something similar to your
> proposed "constant".  As I've already said, the C++ feature blurs
> the distinction between "const" and "constant", which is in my
> opinion a drawback.  In spite of that, I think it's a worthwhile
> addition just because it's useful functionality.  On the other
> hand, I think that a limited form of C++'s more recent "constexpr"
> might be a better solution (and, with the limitations I'm thinking
> of, should be no more difficult to implement than your proposal).
> Quite possibly if "constexpr" had been added to C++ sooner, there
> would have been no need for it to change the semantics of "const".

'const' came into C89 from early C++, so I think it was C that changed
the semantics. See e.g. p.6 of:

  http://www.stroustrup.com/sibling_rivalry.pdf

(Not that it matters in this discussion, except it shows there were
real people behind those semantics.)

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#120766

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Mon, 2017-10-02, Keith Thompson wrote:
> ...
>> C++ already uses "const" to implement something similar to your
>> proposed "constant".  As I've already said, the C++ feature blurs
>> the distinction between "const" and "constant", which is in my
>> opinion a drawback.  In spite of that, I think it's a worthwhile
>> addition just because it's useful functionality.  On the other
>> hand, I think that a limited form of C++'s more recent "constexpr"
>> might be a better solution (and, with the limitations I'm thinking
>> of, should be no more difficult to implement than your proposal).
>> Quite possibly if "constexpr" had been added to C++ sooner, there
>> would have been no need for it to change the semantics of "const".
>
> 'const' came into C89 from early C++, so I think it was C that changed
> the semantics. See e.g. p.6 of:
>
>   http://www.stroustrup.com/sibling_rivalry.pdf
>
> (Not that it matters in this discussion, except it shows there were
> real people behind those semantics.)

Interesting.  I had wondered whether C++ originally made the names
of const-qualified objects constant expressions; according to this,
it did.

I find C's treatment of const more consistent ("const" just means
"read-only"), but C++ making names of some const-qualified objects
usable in constant expressions is more practically useful.

I think that if C adopted a simplified version of C++'s "constexpr"
it would provide the desired functionality without muddying the
(admittedly often misunderstood) meaning of "const".

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#120685

On 02/10/17 04:12, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 01/10/2017 22:09, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>>>> On 01/10/2017 21:46, David Brown wrote:
>>>>> On 01/10/17 15:13, bartc wrote:
>>> [...]
>>>>>> Why didn't you define c and e in terms of a+b and d*c?
>>>>>
>>>>> Because it is not allowed in C? Isn't that a good enough reason?
>>>>
>>>> Are you sure? This seemed to work fine with gcc:
>>>>
>>>>    static const int a = 100;
>>>>    static const double b = 200.1;
>>>>    static const double c = a+b;
>>>>    static const long long int d = 5000000000;
>>>>    static const double e = d*c;
>>>>    static const unsigned long long f = 0xffffffffffffffff;
>>>>
>>>> (And yes gcc did tell me about the overflow.)
>>>
>>> On my system (Ubuntu 17.04, gcc 6.3.0, x86_64):
>>>
>>>      $ cat c.c
>>>      static const int a = 100;
>>>      static const double b = 200.1;
>>>      static const double c = a+b;
>>>      static const long long int d = 5000000000;
>>>      static const double e = d*c;
>>>      static const unsigned long long f = 0xffffffffffffffff;
>>>      $ gcc -c c.c
>>>      c.c:3:25: error: initializer element is not constant
>>>       static const double c = a+b;
>>>                               ^
>>>      c.c:5:25: error: initializer element is not constant
>>>       static const double e = d*c;
>>>                               ^
>>>      $
>>>
>>> I get the same error messages if the declarations are at block scope.
>>
>> OK, I understand: this is a problem at file-scope. And it's the same 
>> problem that stops you using such a value for a fixed array bound or for 
>> a case-label.
> 
> Do you understand that the initializer for a static object must be a
> constant expression either at file scope or at block scope?  You say you
> didn't get a complaint from gcc.  I'm skeptical.  Did you try that exact
> code, or did you omit the "static" keyword?  Please try it again with
> the exact code that you posted above.

I did a couple of tests, and saw a very interesting result.  When these
definitions are at file scope, gcc gives an error (as expected).  In
block scope, gcc gives an error if optimisation is not enabled, as some
of the initialisers are not constant.

However, when optimisation is enabled, the compiler can see that the
initialisation values can be calculated at compile time, and it uses the
pre-calculated values.  It then gives no error.  As far as I can see,
this should not be allowed - it is a syntax error in 6.7.9.  It is
arguably a useful extension, but I would have thought a diagnostic is
required (at least with -Wpedantic).


> 
> The point is that static objects are created and initialized before
> main() begins, and C has no mechanism for running code at that point.
> 
>> (But it demonstrates my concern that using static/const rather than a 
>> dedicated feature, you might not be entirely sure what is happening. 
>> With I tried it and it worked, I thought those names were genuinely 
>> constants.)
> 
> Knowing that "const" doesn't mean "constant" might have prevented that
> misunderstanding.
> 

[toc] | [prev] | [next] | [standalone]

#120660

David Brown <david.brown@hesbynett.no> writes:

> Discussions with you would be a lot easier if you dropped the "you are
> either for me or against me" attitude.  You are neither a Sith, an
> American Republican President, nor a religious nutcase - you have no
> excuse for that habit.

You missed "stupid".  Hanlon's Razor applies.

[toc] | [prev] | [next] | [standalone]

#120616

On Saturday, September 30, 2017 at 1:49:00 PM UTC-3, David Brown wrote:
... 
> The methods available in C for defining constants are not as good as 
> they could be - I have never seem anyone deny that.  But they are also 
> not nearly as bad as some people (such as yourself and Thiago) seem to 
> think.

Please note that my motivation was not const variables.
The 'constant var' subject is related with 'const' and may be 
affect by changes in 'const modifier' design. Consequently, I think 
these two cases must be analysed together, but the main motivation
was not 'const var'.

The main motivation was:
How to  allocate a const object on heap?

Why someone wants to do that?

I have a object ID that is logically const and the 
objects are allocated on heap.

struct Box
{
   const int id; //=1
}

The second motivation is to use const to work 
like encapsulation.

typedef const char* const String;

Some 'authorized' function like String_Set 
would remove const.

I was wondering the consequences of just remove this part
of standard.

" If an attempt is made to modify an object defined with a 
const-qualified type through use of an lvalue with 
non-const-qualified type, the behavior is undefined. "

The previous code still compatible. Right?

The problem is that some constants like

const int i = 1;
static const int i2 = 2;

would be generated on storage, and the previous versions
they weren't.

If we remove the 'const var' option to declare constants
we also need an alternative. (#define still one)

I don't like to use const int to declare constants because I 
am not sure if they will inlined. Then I use #define, and I 
would prefer something that is guarantee this.

Today if some code gets the address of the constant var then 
the constant var is on the storage,  right?

Proposing that is safe to remove const and access the variable
then :

If some code casts const away or gets the address then the const 
var is on the storage.
Maybe this works.

[toc] | [prev] | [next] | [standalone]

#120606

On 29/09/17 15:06, Thiago Adams wrote:
> On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:

>>>
>>> I think we need a specific storage modifier  for this.
>>> for instance:
>>>
>>> inline int C = 1;
>>
>> There is already "static const int C = 1;".  The compiler will usually
>> avoid giving this storage space, unless you take its address.  (C++17
>> added "inline variables" for a somewhat different reason.  It would IMHO
>> be a bad idea to add inline variables to C that are incompatible with
>> the C++ versions.)
> 
> Did you notice everyone use #define for constants?

As a C programmer who uses a variety of ways to created constants - no, 
I did not notice that "everyone" uses #define for constants.  I am a 
counter-example.  I usually use "static const int" style where possible, 
and enum for collections of related constants.  (I use enum for 
enumeration types as well.)

I dislike that there are some uses of constants in C for which #define 
is the only practical method.  But the best answer here is to adopt 
C++'s rules about const, rather than invent a new idea just for C.

Certainly /some/ C programmers use #define as their main way of making 
constants - equally certainly, but not all do so.

> C programmers could also use enuns but they use enum only
> when the values are enumerated.
> enum {CONST1 = 1};

I can't imagine why you think that.


> 
> For all other cases they use #define (in general)
> I think the reason (I can ask for those are reading this)
> is because we don't feel comfortable using const int i = 1;
> and hopping that his will not be placed at storage.
> 
> #define CONST1 1
> 
> give us what we want.

It is rare that a #define'd constant will be less efficient than a 
"const" or "static const" object.  But const objects have the advantage 
of being typed and having identifiers that follow normal scoping, and 
are thus preferable (to me, anyway) in many circumstances.

And there is a big difference, which you seem to have missed, between 
"const" and "static const".  (Perhaps it is from because you have used 
C++, where "const" objects at file/namespace scope are static by 
default.)  A "static const" object will normally /not/ be placed in 
storage, assuming as usual that you have a decent compiler.  It will be 
assigned storage if you take its address, or if that's the most 
efficient way to generate the code that uses it - but otherwise it will 
be used exactly as though it were a #define'd constant.

> 
> And I think they don't use enuns because they are an special case
> for ints and they don't want to have two styles then they
> use #define for ints also.
> 
> 
> I agree 'inline' variables would conflict with C++.
> But this is matter of syntax.
> 
> readonly int i;
> immutable int i;
> 
> I am not suggesting changing the const meaning at this moment
> and broke existing code.
> Just showing the cases and motivation, and asking what can we do
> today or how C could be improved.
> 
> 

[toc] | [prev] | [next] | [standalone]

#120538

On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
...
> You can cast away the const qualifier if you like.  Writing to an object
> that was /defined/ as a const is undefined behaviour - but casting away
> the const and then writing to something that was not originally defined
> as const, is fine.

I don't want to enter too much in C++, but just to show
how the rules must be different there.

struct X {
  int i;
  ~X() { i = 0; }
};

int main() {
  const X x;
  //destructor of X can change x's content
}

[toc] | [prev] | [next] | [standalone]

#120580

Thiago Adams <thiago.adams@gmail.com> writes:

> On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
> ...
>> You can cast away the const qualifier if you like.  Writing to an object
>> that was /defined/ as a const is undefined behaviour - but casting away
>> the const and then writing to something that was not originally defined
>> as const, is fine.
>
> I don't want to enter too much in C++, but just to show
> how the rules must be different there.
>
> struct X {
>   int i;
>   ~X() { i = 0; }

s/~//

> };
>
> int main() {
>   const X x;
>   //destructor of X can change x's content
> }

And in C you can use either

  const struct X x = {0};

or, of you need a function to calculate or abstract away the default
initial setting:

  const struct X x = default_X();

where default_X returns a suitable struct X object.

I can't see what you think C++ beings to this party.  Obviously C++ is
more complex overall, but on this particular point they seems to be
similar: you can't assign to a const object in either C or C++ but you
can initialise one in both C and C++ -- using a function in C if need
be.

(I get the feeling I'm missing the point.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#120583

On Friday, September 29, 2017 at 4:18:15 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams  writes:
> 
> > On Friday, September 29, 2017 at 5:59:53 AM UTC-3, David Brown wrote:
> > ...
> >> You can cast away the const qualifier if you like.  Writing to an object
> >> that was /defined/ as a const is undefined behaviour - but casting away
> >> the const and then writing to something that was not originally defined
> >> as const, is fine.
> >
> > I don't want to enter too much in C++, but just to show
> > how the rules must be different there.
> >
> > struct X {
> >   int i;
> >   ~X() { i = 0; }
> 
> s/~//
> 
> > };
> >
> > int main() {
> >   const X x;
> >   //destructor of X can change x's content
> > }
> 
> And in C you can use either
> 
>   const struct X x = {0};
> 
> or, of you need a function to calculate or abstract away the default
> initial setting:
> 
>   const struct X x = default_X();
> 
> where default_X returns a suitable struct X object.
> 
> I can't see what you think C++ beings to this party.  Obviously C++ is
> more complex overall, but on this particular point they seems to be
> similar: you can't assign to a const object in either C or C++ but you
> can initialise one in both C and C++ -- using a function in C if need
> be.
> 
> (I get the feeling I'm missing the point.)
> 

My sample shows that if C++ put the struct in a read only memory
it would be in trouble because the destructor is allowed to change
the values of 'this'. Consequently the rules must be different.

I think the rule (maybe in a read-only storage) for C applies for 
structs as well.

[toc] | [prev] | [next] | [standalone]

#120584

Thiago Adams <thiago.adams@gmail.com> writes:

> On Friday, September 29, 2017 at 4:18:15 PM UTC-3, Ben Bacarisse wrote:
<snip>
>> (I get the feeling I'm missing the point.)

> My sample shows that if C++ put the struct in a read only memory
> it would be in trouble because the destructor is allowed to change
> the values of 'this'. Consequently the rules must be different.

Ah, I /was/ missing the point.  I thought you had mis-typed the "~" but
you were actually talking about destructors.  I should have trusted that
feeling!

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#120544

one and only case that i use const in my c code 
is for array sizes - its the onlyu case i know where
c really NEEDS const 

hovever it some would redefine araays to holds it size in a way of tab.size it seems c would not need const at all (at least in 'hard' meaning of this word (and afaik))

c would need hovever more const-like words, i was sain on that, one would be relocable - it is very important to know if such given pointer or chunk adresses the momeory which is relocable or not

other subtle thing is distinction if given pointer or chunk is chengable or if memory pointed by that is changeble (thise are two separate meanings ) - this hovever seems not hardly needed

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | comp.lang.c

csiph-web