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

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

GCC and const-correctness

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

Contents

  GCC and const-correctness Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-11 12:17 +0300
    Re: GCC and const-correctness Philipp Klaus Krause <pkk@spth.de> - 2018-10-11 11:22 +0200
      Re: GCC and const-correctness Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-11 13:17 +0300
    Re: GCC and const-correctness Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-11 02:40 -0700
    Re: GCC and const-correctness Spiros Bousbouras <spibou@gmail.com> - 2018-10-11 10:17 +0000
      Re: GCC and const-correctness Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-11 13:28 +0300
        Re: GCC and const-correctness Spiros Bousbouras <spibou@gmail.com> - 2018-10-11 10:58 +0000
          Re: GCC and const-correctness jameskuyper@alumni.caltech.edu - 2018-10-11 08:21 -0700
      Re: GCC and const-correctness David Brown <david.brown@hesbynett.no> - 2018-10-11 12:39 +0200
      Re: GCC and const-correctness Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-11 15:02 +0000
        Re: GCC and const-correctness Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-11 18:06 +0300
        Re: GCC and const-correctness Wouter Verhelst <w@uter.be> - 2018-10-11 17:23 +0200
          Re: GCC and const-correctness Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-12 10:16 +0000
            Re: GCC and const-correctness David Brown <david.brown@hesbynett.no> - 2018-10-12 13:21 +0200
              Re: GCC and const-correctness Wouter Verhelst <w@uter.be> - 2018-10-13 09:33 +0200
                Re: GCC and const-correctness David Brown <david.brown@hesbynett.no> - 2018-10-13 13:11 +0200
      Re: Empty functions (was: GCC and const-correctness) Wouter Verhelst <w@uter.be> - 2018-10-11 17:25 +0200
        Re: Empty functions (was: GCC and const-correctness) Keith Thompson <kst-u@mib.org> - 2018-10-11 09:23 -0700
          Re: Empty functions (was: GCC and const-correctness) Keith Thompson <kst-u@mib.org> - 2018-10-11 10:54 -0700
          Re: Empty functions (was: GCC and const-correctness) Wouter Verhelst <w@uter.be> - 2018-10-11 19:56 +0200
            Re: Empty functions David Brown <david.brown@hesbynett.no> - 2018-10-11 20:19 +0200
            Re: Empty functions (was: GCC and const-correctness) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-12 02:43 -0700
      Re: Empty functions (was: GCC and const-correctness) Anton Shepelev <ant0n.txt@gmai1.c0m> - 2018-10-11 19:16 +0300

Page 1 of 2  [1] 2  Next page →

#136611 — GCC and const-correctness

Hello, all

Shall the following program compile with nary a error nor a
warning?

#include <stdio.h>
static void test( const char * s )
{}

int main( int argc, char** argv )
{  char * s;
   s = NULL;
   test( s );
   return 0;
}

I was expecting at least a hint about a violation of const-
correctness, because test accepts a pointer to const char,
whereas a pointer to char is passed, but

   gcc -Wall -Wpedantic

has no objections.  Why?

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [next] | [standalone]

#136612

Am 11.10.2018 um 11:17 schrieb Anton Shepelev:
> Hello, all
> 
> Shall the following program compile with nary a error nor a
> warning?
> 
> #include <stdio.h>
> static void test( const char * s )
> {}
> 
> int main( int argc, char** argv )
> {  char * s;
>    s = NULL;
>    test( s );
>    return 0;
> }
> 
> I was expecting at least a hint about a violation of const-
> correctness, because test accepts a pointer to const char,
> whereas a pointer to char is passed, but
> 
>    gcc -Wall -Wpedantic
> 
> has no objections.  Why?
> 

An implicit cast adding a const is fine wrt. const-correctness. Only the
opposite would be a problem.

After all, just because something is not const doesn't mean you have to
write it.

Philipp

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

#136620

Philipp Klaus Krause to Anton Shepelev:

>>Shall the following program compile with nary a error nor
>>a warning?
>>
>>#include <stdio.h>
>>static void test( const char * s )
>>{}
>>
>>int main( int argc, char** argv )
>>{  char * s;
>>   s = NULL;
>>   test( s );
>>   return 0;
>>}
>>
>>I was expecting at least a hint about a violation of
>>const-correctness, because test accepts a pointer to const
>>char, whereas a pointer to char is passed, but
>>
>>   gcc -Wall -Wpedantic
>>
>>has no objections.  Why?
>
>An implicit cast adding a const is fine wrt. const-
>correctness. Only the opposite would be a problem.
>
>After all, just because something is not const doesn't mean
>you have to write it.

Thank you, Philipp and Malcolm.  It was brain slip.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#136616

On Thursday, October 11, 2018 at 10:17:47 AM UTC+1, Anton Shepelev wrote:
> Hello, all
> 
> Shall the following program compile with nary a error nor a
> warning?
> 
> #include <stdio.h>
> static void test( const char * s )
> {}
> 
> int main( int argc, char** argv )
> {  char * s;
>    s = NULL;
>    test( s );
>    return 0;
> }
> 
> I was expecting at least a hint about a violation of const-
> correctness, because test accepts a pointer to const char,
> whereas a pointer to char is passed, but
> 
>    gcc -Wall -Wpedantic
> 
> has no objections.  Why?
> 
Because you can pass a modifiable string to a function which does not
modify it, but you can't do the opposite: pass a non-modifiable string
to a function which does modify it.

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

#136619

On Thu, 11 Oct 2018 12:17:31 +0300
Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Hello, all
> 
> Shall the following program compile with nary a error nor a
> warning?
> 
> #include <stdio.h>
> static void test( const char * s )
> {}
> 
> int main( int argc, char** argv )
> {  char * s;
>    s = NULL;
>    test( s );
>    return 0;
> }
> 
> I was expecting at least a hint about a violation of const-
> correctness, because test accepts a pointer to const char,
> whereas a pointer to char is passed, but
> 
>    gcc -Wall -Wpedantic
> 
> has no objections.  Why?

Because what you're doing violates neither the letter of the standard nor the
spirit of what  const  is about. The spirit is as follows :

... test( const char * s )   offers an assurance to the rest of the
code that  test()  will not attempt to modify  *s .What the rest of the code
does with  *s  is up to the rest of the code including what declarations the
rest of the code has. You can see the same principle in action in the
following code :

    int main(void) {
        char a = 'a' ;
        const char *cs1 , *cs2 = &a ;
        char *s = &a ;
        cs1 = s ;  // OK
        s = cs2 ;  // Gives warning with 3 different compilers.
        return 0 ;
    }

By the way , if I were a compiler writer I would offer a warning for a
function with no code and also offer some way to disable such warnings.

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

#136622

Spiros Bousbouras to Anton Shepelev:

>>Shall the following program compile with nary a error nor
>>a warning?
>>
>>#include <stdio.h>
>>static void test( const char * s )
>>{}
>>
>>int main( int argc, char** argv )
>>{  char * s;
>>   s = NULL;
>>   test( s );
>>   return 0;
>>}
>>
>>I was expecting at least a hint about a violation of
>>const-correctness, because test accepts a pointer to const
>>char, whereas a pointer to char is passed, but
>>
>>   gcc -Wall -Wpedantic
>>
>>has no objections.  Why?
>
>Because what you're doing violates neither the letter of
>the standard nor the spirit of what  const  is about. [...]

Understood.  Is the distinction between warnings and error
purely a compiler convention, or is it used in the Standard?

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#136625

On Thu, 11 Oct 2018 13:28:15 +0300
Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> Understood.  Is the distinction between warnings and error
> purely a compiler convention, or is it used in the Standard?

Convention. The standard only talks about diagnostics :

  5.1.1.3 Diagnostics

  1 A conforming implementation shall produce at least one diagnostic
    message (identified in an implementation-defined manner) if a
    preprocessing translation unit or translation unit contains a violation
    of any syntax rule or constraint, even if the behavior is also
    explicitly specified as undefined or implementation-defined. Diagnostic
    messages need not be produced in other circumstances. 9)

And footnote 9 :

    9) The intent is that an implementation should identify the nature
       of, and where possible localize, each violation. Of course, an
       implementation is free to produce any number of diagnostics as long
       as a valid program is still correctly translated. It may also
       successfully translate an invalid program.

Which makes me wonder what it would mean to unsuccessfully translate an
invalid program  :-)

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

#136652

On Thursday, October 11, 2018 at 6:58:13 AM UTC-4, Spiros Bousbouras wrote:
> On Thu, 11 Oct 2018 13:28:15 +0300
> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> > Understood.  Is the distinction between warnings and error
> > purely a compiler convention, or is it used in the Standard?
> 
> Convention. The standard only talks about diagnostics :
> 
>   5.1.1.3 Diagnostics
> 
>   1 A conforming implementation shall produce at least one diagnostic
>     message (identified in an implementation-defined manner) if a
>     preprocessing translation unit or translation unit contains a violation
>     of any syntax rule or constraint, even if the behavior is also
>     explicitly specified as undefined or implementation-defined. Diagnostic
>     messages need not be produced in other circumstances. 9)
> 
> And footnote 9 :
> 
>     9) The intent is that an implementation should identify the nature
>        of, and where possible localize, each violation. Of course, an
>        implementation is free to produce any number of diagnostics as long
>        as a valid program is still correctly translated. It may also
>        successfully translate an invalid program.
> 
> Which makes me wonder what it would mean to unsuccessfully translate an
> invalid program  :-)

The same as for a valid program: terminating translation without having generated a translated program. Keep in mind that, the way the standard is worded, there's no requirements that the generated program has to meet, so in particular, there's nothing wrong, as far as the standard is concerned, if the translated program gives an alternative meaning to whatever feature(s) the source code contained that rendered it invalid.

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

#136623

On 11/10/18 12:17, Spiros Bousbouras wrote:

> By the way , if I were a compiler writer I would offer a warning for a
> function with no code and also offer some way to disable such warnings.
> 

gcc can do that sometimes too, if you know the secret incantations.
"-Wunused-parameter", part of "-Wextra", warns that the parameter to
"test" is not used.

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

#136645

On Thu, 2018-10-11, Spiros Bousbouras wrote:
> On Thu, 11 Oct 2018 12:17:31 +0300
> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
...
>> static void test( const char * s )
>> {}
...

> By the way , if I were a compiler writer I would offer a warning for a
> function with no code and also offer some way to disable such warnings.

Better IMO to not habitually create empty functions.  If you just
/declare/ a function as a placeholder instead of /define/ it, you
can't forget to go back and fill it in.

/Jorgen

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

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

#136646

Jorgen Grahn:

>Better IMO to not habitually create empty functions.  If
>you just /declare/ a function as a placeholder instead of
>/define/ it, you can't forget to go back and fill it in.

Sound advice, thanks.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

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

#136654

On 11/10/18 17:02, Jorgen Grahn wrote:
> On Thu, 2018-10-11, Spiros Bousbouras wrote:
>> On Thu, 11 Oct 2018 12:17:31 +0300
>> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> ...
>>> static void test( const char * s )
>>> {}
> ...
> 
>> By the way , if I were a compiler writer I would offer a warning for a
>> function with no code and also offer some way to disable such warnings.
> 
> Better IMO to not habitually create empty functions.  If you just
> /declare/ a function as a placeholder instead of /define/ it, you
> can't forget to go back and fill it in.

The downside of that is that this makes it impossible for you to link
the program as soon as you use one of the declared-but-not-implemented
functions. That makes it harder to test the parts of the application
that you *did* write.

Instead, I think it's better to stub out such functions, but also make
them log a message that makes it obvious what's going on, and add a
comment with an easy-to-grep marker (something like "TODO" springs to
mind) that you can then search for later when you want to see what else
you have left to do.

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

#136714

On Thu, 2018-10-11, Wouter Verhelst wrote:
> On 11/10/18 17:02, Jorgen Grahn wrote:
>> On Thu, 2018-10-11, Spiros Bousbouras wrote:
>>> On Thu, 11 Oct 2018 12:17:31 +0300
>>> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> ...
>>>> static void test( const char * s )
>>>> {}
>> ...
>> 
>>> By the way , if I were a compiler writer I would offer a warning for a
>>> function with no code and also offer some way to disable such warnings.
>> 
>> Better IMO to not habitually create empty functions.  If you just
>> /declare/ a function as a placeholder instead of /define/ it, you
>> can't forget to go back and fill it in.
>
> The downside of that is that this makes it impossible for you to link
> the program as soon as you use one of the declared-but-not-implemented
> functions. That makes it harder to test the parts of the application
> that you *did* write.

It's also the upside: as a rule, I don't want the code to link if it's
that incomplete.

I may write unit tests for the other parts.  Or, if I *do* have unit tests
which fail because of it, I can accept having an empty function definition
like you suggest.

And of course: YMMV.

/Jorgen

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

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

#136720

On 12/10/18 12:16, Jorgen Grahn wrote:
> On Thu, 2018-10-11, Wouter Verhelst wrote:
>> On 11/10/18 17:02, Jorgen Grahn wrote:
>>> On Thu, 2018-10-11, Spiros Bousbouras wrote:
>>>> On Thu, 11 Oct 2018 12:17:31 +0300
>>>> Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>>> ...
>>>>> static void test( const char * s )
>>>>> {}
>>> ...
>>>
>>>> By the way , if I were a compiler writer I would offer a warning for a
>>>> function with no code and also offer some way to disable such warnings.
>>>
>>> Better IMO to not habitually create empty functions.  If you just
>>> /declare/ a function as a placeholder instead of /define/ it, you
>>> can't forget to go back and fill it in.
>>
>> The downside of that is that this makes it impossible for you to link
>> the program as soon as you use one of the declared-but-not-implemented
>> functions. That makes it harder to test the parts of the application
>> that you *did* write.
> 
> It's also the upside: as a rule, I don't want the code to link if it's
> that incomplete.

A convenient method is to use :

void test(void) {
#warning Function "test" is not yet implemented
}

In early stages of development, when you might want compiling and
linking to work despite known problems, you let this and other warning
messages slide.  Once the program starts to take shape and you need to
get more details in place, put "-Werror" in your Makefile and (to Bart's
joy) do a clean build.  From now on, these unimplemented functions will
fail to compile and can't be forgotten.

> 
> I may write unit tests for the other parts.  Or, if I *do* have unit tests
> which fail because of it, I can accept having an empty function definition
> like you suggest.
> 
> And of course: YMMV.
> 
> /Jorgen
> 

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

#136742

On 12/10/18 13:21, David Brown wrote:
> On 12/10/18 12:16, Jorgen Grahn wrote:
>> On Thu, 2018-10-11, Wouter Verhelst wrote:
>>> The downside of that is that this makes it impossible for you to link
>>> the program as soon as you use one of the declared-but-not-implemented
>>> functions. That makes it harder to test the parts of the application
>>> that you *did* write.
>>
>> It's also the upside: as a rule, I don't want the code to link if it's
>> that incomplete.
> 
> A convenient method is to use :
> 
> void test(void) {
> #warning Function "test" is not yet implemented
> }
> 
> In early stages of development, when you might want compiling and
> linking to work despite known problems, you let this and other warning
> messages slide.  Once the program starts to take shape and you need to
> get more details in place, put "-Werror" in your Makefile and (to Bart's
> joy) do a clean build.  From now on, these unimplemented functions will
> fail to compile and can't be forgotten.

That's an awesome trick; thanks.

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

#136748

On 13/10/18 09:33, Wouter Verhelst wrote:
> On 12/10/18 13:21, David Brown wrote:
>> On 12/10/18 12:16, Jorgen Grahn wrote:
>>> On Thu, 2018-10-11, Wouter Verhelst wrote:
>>>> The downside of that is that this makes it impossible for you to link
>>>> the program as soon as you use one of the declared-but-not-implemented
>>>> functions. That makes it harder to test the parts of the application
>>>> that you *did* write.
>>>
>>> It's also the upside: as a rule, I don't want the code to link if it's
>>> that incomplete.
>>
>> A convenient method is to use :
>>
>> void test(void) {
>> #warning Function "test" is not yet implemented
>> }
>>
>> In early stages of development, when you might want compiling and
>> linking to work despite known problems, you let this and other warning
>> messages slide.  Once the program starts to take shape and you need to
>> get more details in place, put "-Werror" in your Makefile and (to Bart's
>> joy) do a clean build.  From now on, these unimplemented functions will
>> fail to compile and can't be forgotten.
> 
> That's an awesome trick; thanks.
> 

Glad to help.

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

#136656 — Re: Empty functions (was: GCC and const-correctness)

On 11/10/18 17:19, Stefan Ram wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>> By the way , if I were a compiler writer I would offer a warning for a
>> function with no code and also offer some way to disable such warnings.
> 
>   When it comes to empty functions, we should not forget that
>   another reasonable reason for an empty function can be seen
>   in a situation where one can pass in a function as a
>   /callback/ to a call for something to be done, say at a
>   certain point. When you want /nothing/ to be done at that
>   point, you would pass in an /empty function/ (albeit with
>   the correct type) into that call. Such an empty function is
>   not a placeholder to be filled in later, but it is intended
>   to stay empty.

In most such cases, you can pass in NULL as the callback, which then has
the same effect. In fact, I would say that code which does not act that
way is buggy, and should be fixed.

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

#136661 — Re: Empty functions (was: GCC and const-correctness)

Wouter Verhelst <w@uter.be> writes:
> On 11/10/18 17:19, Stefan Ram wrote:
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>> By the way , if I were a compiler writer I would offer a warning for a
>>> function with no code and also offer some way to disable such warnings.
>> 
>>   When it comes to empty functions, we should not forget that
>>   another reasonable reason for an empty function can be seen
>>   in a situation where one can pass in a function as a
>>   /callback/ to a call for something to be done, say at a
>>   certain point. When you want /nothing/ to be done at that
>>   point, you would pass in an /empty function/ (albeit with
>>   the correct type) into that call. Such an empty function is
>>   not a placeholder to be filled in later, but it is intended
>>   to stay empty.
>
> In most such cases, you can pass in NULL as the callback, which then has
> the same effect. In fact, I would say that code which does not act that
> way is buggy, and should be fixed.

A null pointer (which doesn't point to a function) is not the same
as a function that does nothing.  A function that takes a pointer
to a callback function should document what it does with it.  In my
opinion it's perfectly reasonable to require the passed pointer to
be non-null (or perhaps for a null pointer to have some distinct
meaning).

-- 
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]

#136669 — Re: Empty functions (was: GCC and const-correctness)

Keith Thompson <kst-u@mib.org> writes:
[...]
> A null pointer (which doesn't point to a function) is not the same
> as a function that does nothing.

What I meant to say is that a null pointer is not the same as *a pointer
to* a function that does nothing.

>                                   A function that takes a pointer
> to a callback function should document what it does with it.  In my
> opinion it's perfectly reasonable to require the passed pointer to
> be non-null (or perhaps for a null pointer to have some distinct
> meaning).

-- 
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]

#136671 — Re: Empty functions (was: GCC and const-correctness)

On 11/10/18 18:23, Keith Thompson wrote:
> Wouter Verhelst <w@uter.be> writes:
>> On 11/10/18 17:19, Stefan Ram wrote:
>>> Spiros Bousbouras <spibou@gmail.com> writes:
>>>> By the way , if I were a compiler writer I would offer a warning for a
>>>> function with no code and also offer some way to disable such warnings.
>>>
>>>   When it comes to empty functions, we should not forget that
>>>   another reasonable reason for an empty function can be seen
>>>   in a situation where one can pass in a function as a
>>>   /callback/ to a call for something to be done, say at a
>>>   certain point. When you want /nothing/ to be done at that
>>>   point, you would pass in an /empty function/ (albeit with
>>>   the correct type) into that call. Such an empty function is
>>>   not a placeholder to be filled in later, but it is intended
>>>   to stay empty.
>>
>> In most such cases, you can pass in NULL as the callback, which then has
>> the same effect. In fact, I would say that code which does not act that
>> way is buggy, and should be fixed.
> 
> A null pointer (which doesn't point to a function) is not the same
> as a function that does nothing.

Sure, but that's not what I meant.

I mean that most code which I've seen that accepts a pointer to a
callback, will also accept a NULL pointer to declare "no callback is
necessary here, please don't do anything", and that code which accepts
callbacks but which does not do so is buggy, in my opinion.

>  A function that takes a pointer
> to a callback function should document what it does with it.

Yes, of course.

> In my
> opinion it's perfectly reasonable to require the passed pointer to
> be non-null (or perhaps for a null pointer to have some distinct
> meaning).

Well, I guess we disagree on that, then. That's perfectly fine, of course :)

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web