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

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

"Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide

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

Contents

  "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Lynn McGuire <lynnmcguire5@gmail.com> - 2020-08-12 13:54 -0500
    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-12 12:23 -0700
      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Elijah Stone <elronnd@elronnd.net> - 2020-08-12 15:05 -0700
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-12 19:15 -0400
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Philipp Klaus Krause <pkk@spth.de> - 2020-08-13 10:36 +0200
            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Poprocks <please@replytogroup.com> - 2020-08-13 14:23 +0000
              What do when -Werror gets in your way (Was: "Why the C Language Will Never Stop You from Making Mistakes") by JeanHeyd Meneide gazelle@shell.xmission.com (Kenny McCormack) - 2020-08-13 14:49 +0000
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-01 07:37 -0700
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide David Brown <david.brown@hesbynett.no> - 2020-09-01 17:36 +0200
            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-01 07:33 -0700
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Elijah Stone <elronnd@elronnd.net> - 2020-08-13 23:25 -0700
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-01 07:22 -0700
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Forkosh <forkosh@panix.com> - 2020-08-13 01:15 +0000
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-12 18:42 -0700
            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Forkosh <forkosh@panix.com> - 2020-08-13 06:15 +0000
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-12 23:23 -0700
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Forkosh <forkosh@panix.com> - 2020-08-13 06:44 +0000
                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Poprocks <please@replytogroup.com> - 2020-08-15 22:51 +0000
                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-15 19:41 -0400
                      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 02:02 +0100
                        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Forkosh <forkosh@panix.com> - 2020-08-16 05:47 +0000
                          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-08-16 12:03 +0100
                            Kinda by definition... (Was: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide) gazelle@shell.xmission.com (Kenny McCormack) - 2020-08-16 11:49 +0000
                          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-16 05:33 -0700
                            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Forkosh <forkosh@panix.com> - 2020-08-17 06:27 +0000
                          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-16 09:12 -0400
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-13 07:38 -0400
                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-13 09:33 -0400
                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-14 10:50 -0400
                      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-14 12:39 -0400
                        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-14 16:53 -0400
                          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-14 19:49 -0400
                            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-08-15 02:31 -0700
                              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-15 16:10 -0700
                                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-16 09:25 -0400
                                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-16 10:50 -0700
                                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-16 15:40 -0400
                                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Damon <Richard@Damon-Family.org> - 2020-08-16 19:39 -0400
                                      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-16 21:12 -0400
                                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Harnden <richard.nospam@gmail.com> - 2020-08-18 08:47 +0100
                                      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-18 08:26 -0400
                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-08-28 08:10 -0700
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide gazelle@shell.xmission.com (Kenny McCormack) - 2020-08-13 12:48 +0000
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide John Bode <jfbode1029@gmail.com> - 2020-08-13 09:46 -0700
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-08-13 06:14 +0000
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-01 06:27 -0700
      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Anton Shepelev <anton.txt@gmail.com> - 2020-08-13 01:19 +0300
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-12 16:18 -0700
      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Scott Newman <scott69@gmail.com> - 2020-08-13 09:25 +0200
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 00:41 -0700
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Scott Newman <scott69@gmail.com> - 2020-08-13 12:53 +0200
            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Richard Harnden <richard.nospam@gmail.com> - 2020-08-13 12:52 +0100
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide David Brown <david.brown@hesbynett.no> - 2020-08-13 15:17 +0200
            Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 10:38 -0700
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Scott Newman <scott69@gmail.com> - 2020-08-13 19:44 +0200
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Bart <bc@freeuk.com> - 2020-08-13 19:10 +0100
                Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-08-13 11:42 -0700
                  Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide scott@slp53.sl.home (Scott Lurndal) - 2020-08-14 05:56 +0000
                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Bonita Montero <Bonita.Montero@gmail.com> - 2020-08-14 09:14 +0200
                    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-08-14 08:45 -0400
                      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide gazelle@shell.xmission.com (Kenny McCormack) - 2020-08-14 16:51 +0000
              Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Ian Collins <ian-news@hotmail.com> - 2020-08-15 09:11 +1200
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-09-12 23:00 -0700
      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-08-24 16:58 -0700
    Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Philipp Klaus Krause <pkk@spth.de> - 2020-08-13 10:32 +0200
      Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-08-23 07:04 -0700
        Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Philipp Klaus Krause <pkk@spth.de> - 2020-09-10 20:44 +0200
          Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-09-12 21:57 -0700

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

#153709

On 8/18/20 3:47 AM, Richard Harnden wrote:
> On 16/08/2020 20:40, James Kuyper wrote:
>> On 8/16/20 9:25 AM, Richard Damon wrote:
>>> On 8/15/20 7:10 PM, James Kuyper wrote:
>>>> On Saturday, August 15, 2020 at 5:32:04 AM UTC-4, Malcolm McLean wrote:
>>>>> On Saturday, 15 August 2020 00:49:52 UTC+1, James Kuyper  wrote:
>> ...
>>>>> You don't seem to have answered Richard damon's point. To give a more
>>>>> concreate example.
>>>>>
>>>>> We have
>>>>> struct Point2
>>>>> {
>>>>>     double x;
>>>>>     double y;
>>>>> };
>>>>>
>>>>> and
>>>>>
>>>>> struct Point3
>>>>> {
>>>>>    double x;
>>>>>    double y;
>>>>>    double z;
>>>>> }
>>>>>
>>>>> Now we have correct code
>>>>>
>>>>> struct Point2 *p;
>>>>>
>>>>> p = malloc(count * sizeof *p);
>>>>> // create points at unit intervals
>>>>> for (i=0; i< count; i++)
>>>>> {
>>>>>     p[i].x = i;
>>>>>     p[i].y = 0;
>>>>> }
>>>>>
>>>>> Now we change it to
>>>>>
>>>>> struct Point3 *p;
>>>>>
>>>>> The code is now incorrect, we need to add the line p[i].z = 0; >>>
>>>> Yes, and what should immediately follow that change is a search through
>>>> the code for uses of ".y" or "->y", to identify locations where code
>>>> changes referring to .z might be needed. Note that many, perhaps most,
>>>> such places are nowhere near any malloc() call that allocates space for
>>>> such objects - only the ones that set the initial values are likely to
>>>> be anywhere near the malloc() call (and even that's not necessarily the
> 
> So why not change the struct temporarily ...
> 
> struct Point3
> {
>      double x_needs_z;
>      double y;
>      double z;
> };
> 
> ... and recompile?
> 
> Everywhere it complains about p has no member called x, it where you 
> need to check for a missing z.
> 
> Let the compilier do the searching.

Yes, that's one good way to do the search.

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

#154103

Richard Damon <Richard@Damon-Family.org> writes:

> On 8/13/20 2:23 AM, Keith Thompson wrote:
>
>> John Forkosh <forkosh@panix.com> writes:
>> [...]
>>
>>> I personally do bind the * to the *p_, but would also write it as,
>>>       typedef struct Meow  meow
>>>       meow *p_cat = (meow *)malloc(sizeof(meow));
>>> which is just how I personally like to read and write it.
>>> And if that faq doesn't like it, then it can just go rewrite
>>> itself:)
>>
>> OK, *why* do you like the cast?  What is the benefit of it?  Why do
>> you think having the cast is better than not having it?
>>
>> You are of course entitled to your opinion, I'm just wondering if
>> you have a basis for it.
>
> The basic argument against the cast is that if you forget the
> include/prototype (which in my opinion, that error should be
> configured to be a fatal errpr) the cast hides that error.
>
> The use of the cast detects if the type of the variable is the
> wrong type of pointer, maybe not as likely in the case where you
> are declaring the pointer, but if you are using an existing
> pointer isn't that hard.
>
> The idiom
>
> p = malloc(sizeof(*p));
>
> also doesn't protect from the 'wrong' type, yes, it will malloc
> for the right type for the pointer, but maybe not for the code
> that is using it.
>
> Using a macro like:
>
>
> #define NEW(T) (T *)malloc(sizeof T)
>
> allows the use of
>
> p = NEW(Foo)
>
> and if p isn't a Foo*, you get an error (or at least a constraint
> violation), and thus you know the code needs to be checked if it
> needs to change based on the new type of *p.

I have read through your postings in this thread on this topic.
Directly put, I disagree with your position and with your
proposal.

There are several factors or principles that argue against the
position.  Some of these are:

(1) Casting is bad.  Unnecessary casts should be avoided.

(2) It violates the factoring principle.  The type name T is
written in several places rather than just once, on the
declaration of the variable assigned the value.

(3) As a consequence of (2), it raises maintenance costs.  If a
change in type is needed, the source needs modifying in several
places rather than just one.

(4) As a general rule, we would like to avoid situations that
require multiple parts of a program to be kept "in sync".  This
rule is related to (2) but not exactly the same.  In some cases
being forced to synchronize two distinct parts of a program has
some benefit, but I don't see any benefit here relative to the
usual idiom `p = malloc( sizeof *p )`.

(5) The reasoning offered has an air (at least it does to me) of
being disingenuous.  The concern expressed is not for assigning
to p but later using p to initialize the allocated object.  If
the real concern is making sure the initialization matches the
type of *p then that concern should be addressed in the code that
performs the initialization, not the code that does the malloc()
call.  There are several ways we might effect such initializing
so that type correctness is ensured:

  (1) Have an appropriately typed initializing function:

        T *p = malloc( sizeof *p );
        initialize_T( p );

  (2) Have an appropriately typed value-generating function:

        T *p = malloc( sizeof *p );
        *p = some_T_value( x, y, z );

  (3) Use a compound literal:

        T *p = malloc( sizeof *p );
        *p = (T){  .foo = 1,  .bas = 0,  };

In addition to more directly addressing the true concern, these
patterns promote more reliable programming practices.

Turning to the proposal, here is a different one:

    #define NEW(p) (p) = malloc( sizeof *(p) )

We can use this pseudo-function as a expression-statement:

    T *p;

    ...

    NEW(p);

It also is usable in declarations:

    T *NEW(p);

I'm sure some people will react negatively to the declaration
pattern, and that's okay.  For those who don't mind it the
pattern is there.

One final comment:  although I disagree with some of your
comments I have not set out to persuade or convince anyone
otherwise.  My purpose is simply to express my disagreement
and put forth an alternative proposal, for those who may
be interested.  I am as always interested to hear whatever
reactions you might have but I'm not here to argue about
which approach is better.

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

#153598

In article <87k0y312ua.fsf@nosuchdomain.example.com>,
Keith Thompson  <Keith.S.Thompson+u@gmail.com> wrote:
>John Forkosh <forkosh@panix.com> writes:
>[...]
>> I personally do bind the * to the *p_, but would also write it as,
>>       typedef struct Meow  meow
>>       meow *p_cat = (meow *)malloc(sizeof(meow));
>> which is just how I personally like to read and write it.
>> And if that faq doesn't like it, then it can just go rewrite itself:)
>
>OK, *why* do you like the cast?  What is the benefit of it?  Why do you
>think having the cast is better than not having it?
>
>You are of course entitled to your opinion, I'm just wondering if
>you have a basis for it.

And here we are, back to the central topic of this newsgroup.

Next, we'll be discussing "void main"...

-- 
One should not believe everything posted to USENET.

    - Aharon (Arnold) Robbins                 arnold AT skeeve DOT com -
    - 4/15/19 -

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

#153603

On Thursday, August 13, 2020 at 1:15:19 AM UTC-5, John Forkosh wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> > John Forkosh <forkosh@panix.com> writes:
> >> Elijah Stone <elronnd@elronnd.net> wrote:
> >>> On Wed, 12 Aug 2020, Keith Thompson wrote:
> >>> 
> >>>> Casting the result of malloc is also disturbing.
> >>> Agreed.
> >>
> >> What's wrong with that? (Or are you suggesting that calloc()
> >> should be used instead?)
> > 
> > No, I'm not suggesting using calloc().
> > 
> > This is explained in section 7 of the comp.lang.c FAQ.
> > http://www.c-faq.com/
> 
> You specifically mean  http://www.c-faq.com/malloc/mallocnocast.html
> And that's way, way (,way...) too -pedantic. Sounds like it was
> written by some pompous, arrogant bully. I especially like the part
> where it says...
>     "the compiler is likely to assume that you know what you're doing"
> Heaven forbid!!! You know what you're doing???
> Never in a million years!!!
> 
> And I also like your sig where it says...
>     "Working, but not speaking, for ..."
> Yeah! Now you've got it! >>That's<< what the C compiler should be
> doing. It's working for me, and should do what I say, how I say it.
> A warning/suggestion here and there is fine, but no hard-and-fast
> pronouncements about style or anything else. And if I screw up,
> then that's on me. But in no way, shape or form, to follow the
> analogy suggested by the github example, should the tail be
> wagging the dog!!! Like you do (the faq does) right here...
> 
> > The article
> >    https://thephd.github.io/
> >    your-c-compiler-and-standard-library-will-not-help-you
> > has:
> >     struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
> > 
> > This would be better written as:
> >     struct Meow *p_cat = malloc(sizeof *p_cat);
> > 
> > The cast is unnecessary, since there's an implicit conversion from
> > void* to struct Meow*.  The type name "struct Meow" is written
> > 3 times.  An editing error could easily result in an inconsistency,
> > allocating the wrong size and/or using a pointer of the wrong type.
> > Using the size of *p_cat avoids having to name the type and allows
> > for changing the type without breaking the code.
> 
> The remark "An editing error could easily result in" a program error
> just sound like a half-elbowed excuse to shove the faq's pompous and
> bullying style down someone else's throat. Gee, an editing error
> can result in an error??? Really???
> 
> I personally do bind the * to the *p_, but would also write it as,
>       typedef struct Meow  meow
>       meow *p_cat = (meow *)malloc(sizeof(meow));
> which is just how I personally like to read and write it.
> And if that faq doesn't like it, then it can just go rewrite itself:)

My problem with that style is the level of needless redundancy - all it adds
is visual clutter.  It doesn't make the code any safer than

     p_cat = malloc( sizeof *p_cat );

and I will argue that using a cast and the type name in the sizeof expression
are *less* safe because it makes the human the strong link in the chain.  With
this style, if you change the type of p_cat, you don't have to change anything 
else.  It's one less thing to worry about.  

IMO, the only good reason to cast the result of *alloc is because you're 
porting your C code to C++, and you want to do the minimum work necessary to
get it running quickly.  Eventually you will want to rewrite that code to use
containers or C++-style memory management, but as a temporary solution it's
good enough.  

But in straight C code?  In my experience it creates more heartburn than it
saves.  

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

#153587

On Wed, 2020-08-12, Elijah Stone wrote:
> On Wed, 12 Aug 2020, Keith Thompson wrote:
>
>> There is a valid point here, that C's requirements for diagnostic are 
>> rather weak, but most or all compilers do provide options to enforce the 
>> rules strictly, and I think most production code is written to follow 
>> the rules.
>> 
>> C isn't nearly as lax as he implies it is.
>
> He spends a long time talking about this; see the section titled 'We 
> Consider Warning Changes, Breaking'.  They are unwilling to add new 
> warnings /because/ people compile with -Werror and the new warnings will 
> cause people's code to break.

I already dislike -Werror, but I hope this (stifling compiler
development) isn't yet another reason.  Does this "thephd" guy have
any special insights?  I didn't read the whole thing; it's not very
well written.

It's always the case, of course, that there's a balance between good
warnings and false positives.

/Jorgen

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

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

#154336

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Wed, 2020-08-12, Elijah Stone wrote:
>
>> On Wed, 12 Aug 2020, Keith Thompson wrote:
>>
>>> There is a valid point here, that C's requirements for diagnostic
>>> are rather weak, but most or all compilers do provide options to
>>> enforce the rules strictly, and I think most production code is
>>> written to follow the rules.
>>>
>>> C isn't nearly as lax as he implies it is.
>>
>> He spends a long time talking about this;  see the section titled
>> 'We Consider Warning Changes, Breaking'.  They are unwilling to add
>> new warnings /because/ people compile with -Werror and the new
>> warnings will cause people's code to break.
>
> I already dislike -Werror, but I hope this (stifling compiler
> development) isn't yet another reason.  Does this "thephd" guy
> have any special insights?  I didn't read the whole thing;  it's
> not very well written.
>
> It's always the case, of course, that there's a balance between
> good warnings and false positives.

I think an important insight is realizing that different points
on this spectrum serve different purposes, and it isn't necessary
to choose a single point for every compile.

Some diagnostic conditions give false positives so rarely that we
are willing to treat false positives as true positives, taking as
"errors" those statements that trigger the diagnostics even though
logically nothing bad occurs (or at least doesn't now).  Production
compiles can safely use just this set of tests for their chosen
options, and for those compilations -Werror is appropriate.

At the other end of the spectrum, sometimes we want to turn on
every diagnostic condition under the sun, as part of a quality
process, to find code that either is wrong or is sufficiently
questionable so that it would benefit from improvement.  In these
cases -Werror serves no purpose and would only get in the way.

In between those extremes, different work habits and different
development processes will settle on different sets of tests to
be done in different scenarios.  Depending on the set of tests
selected and the purpose being served, using -Werror might be
helpful or might be only annoying.  Some people like routine
compiles to give diagnostics fairly liberally, accepting that
most compiles will generate some flags;  others like routine
compiles to be free of any warning/error output, limiting the set
of conditions being tested to those thought severe enough to be
unacceptable.  Another important point in the process is just
before a commit (or a push) is done.  Similarly there should be a
shared understanding of what diagnostics are enabled as part of
code reviews.  Each of these different circumstances presents a
different case either for or against using -Werror, depending
on how many and which diagnostics are enabled.

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

#153580

Keith Thompson:

> C isn't nearly as lax as he implies it is.

I agree with you and Elijah.  C would be making a much
better impression but for slipshod programmers and compiler
writers that cater for them. It should be good tone and
taken for granted that compilers should not accept programs
with errors and underfined behavior. Instances of undefined
behavior should be considered individually and compilers
instructed to accept them on a case-by-case basis.

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

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

#153582

Anton Shepelev <anton.txt@gmail.com> writes:
> Keith Thompson:
>
>> C isn't nearly as lax as he implies it is.
>
> I agree with you and Elijah.  C would be making a much
> better impression but for slipshod programmers and compiler
> writers that cater for them. It should be good tone and
> taken for granted that compilers should not accept programs
> with errors and underfined behavior. Instances of undefined
> behavior should be considered individually and compilers
> instructed to accept them on a case-by-case basis.

In many (most?) cases, constructs that have undefined behavior
are defined that way because they're errors that are impossible to
detect in all cases.  Consider signed integer overflow, for example.

C only requires a diagnostic (which can be non-fatal) for a violation
of a syntax rule or constraint.  My personal preference would
have been to require all such errors to be fatal.  Compilers could
always have non-conforming options that tell them to allow bad code,
and it compilers could still be non-conforming by default.

But the current situation isn't too much different; it's mostly
just a matter of picking the right options.  Most compilers *can*
be invoked in a mode that rejects all syntax errors and constraint
violations with fatal errors.

The code in the article (that initialized a pointer object with
a value of a different pointer type) would almost certainly be
rejected on any real-world project.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#153591

> Of course the initialization of p_dog is a constraint violation.  There
> is no implicit conversion between incompatible pointer types (other than
> the special case of void*).

No, that's perfectl legal code.

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

#153592

Scott Newman <scott69@gmail.com> writes:
>> Of course the initialization of p_dog is a constraint violation.  There
>> is no implicit conversion between incompatible pointer types (other than
>> the special case of void*).
>
> No, that's perfectl legal code.

I suppose that depends on what you mean by "legal" (the C standard
doesn't use that word to refer to code).  But it's definitely a
constraint violation.

Here's the full program:

#include <stdlib.h>

struct Meow {
 int a;
};

struct Bark {
 double b;
 void* c;
};

int main (int argc, char* argv[]) {
 (void)argc;
 (void)argv;

 struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
 struct Bark* p_dog = p_cat;
 // :3
 
 return 0;
}

struct Meo and struct Bark are not compatible types, so the
initialization violates the constraint in N1570 6.5.16.1p1,
referenced in 6.7.9p11.

(Either that, or I've misunderstood something and the authors of
gcc and clang made the same mistake.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#153595

>   (void)argc;
>   (void)argv;

That's dangerous code !

>   struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>   struct Bark* p_dog = p_cat;

That works perfectly.

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

#153597

On 13/08/2020 11:53, Scott Newman wrote:
>>   (void)argc;
>>   (void)argv;
> 
> That's dangerous code !

int main(void) would've been better, but those are there to stop the 
'unused' warnings.
> 
>>   struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>   struct Bark* p_dog = p_cat;
> 
> That works perfectly.
> 

It doesn't.

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

#153599

On 13/08/2020 13:52, Richard Harnden wrote:
> On 13/08/2020 11:53, Scott Newman wrote:
>>>   (void)argc;
>>>   (void)argv;
>>
>> That's dangerous code !
> 
> int main(void) would've been better, but those are there to stop the
> 'unused' warnings.

It's also a common convention for saying "I am intentionally discarding
or ignoring these parameters".

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

#153605

Scott Newman <scott69@gmail.com> writes:
>>   (void)argc;
>>   (void)argv;
>
> That's dangerous code !
>
>>   struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>   struct Bark* p_dog = p_cat;
>
> That works perfectly.

Oh, I see.  You're a troll.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#153607

>>>    (void)argc;
>>>    (void)argv;

>> That's dangerous code !

>>>    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>>    struct Bark* p_dog = p_cat;

>> That works perfectly.

> Oh, I see.  You're a troll.

No, test it with a proper compiler.

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

#153609

On 13/08/2020 18:44, Scott Newman wrote:
>>>>    (void)argc;
>>>>    (void)argv;
> 
>>> That's dangerous code !
> 
>>>>    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>>>    struct Bark* p_dog = p_cat;
> 
>>> That works perfectly.

KT:
>> Oh, I see.  You're a troll.
> 
> No, test it with a proper compiler.

Which one is that?

Mine tells me that p_dog and p_cat are not compatible.

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

#153612

Scott Newman <scott69@gmail.com> writes:
>>>>    (void)argc;
>>>>    (void)argv;
>
>>> That's dangerous code !
>
>>>>    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>>>    struct Bark* p_dog = p_cat;
>
>>> That works perfectly.
>
>> Oh, I see.  You're a troll.
>
> No, test it with a proper compiler.

Please leave attribution lines in place when you post a followup.
I do not give permission to quote anything I write here without
proper attribution.

I posted citations to the standard that demonstrate that the
initialization is a constraint violation.  You ignored them.
Do you disagree with my interpretation, and if so why?

What exactly do you consider a "proper compiler"?  Invoked with
what options?  Whatever compiler you're talking about, do you assert
that it is a conforming implementation?

Oh, and how exactly are `(void)argc;` and `(void)argv;` dangerous?
What danger do you see?

I don't believe you're serious.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#153628

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Scott Newman <scott69@gmail.com> writes:
>>>>>    (void)argc;
>>>>>    (void)argv;
>>
>>>> That's dangerous code !
>>
>>>>>    struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow));
>>>>>    struct Bark* p_dog = p_cat;
>>
>>>> That works perfectly.
>>
>>> Oh, I see.  You're a troll.
>>
>> No, test it with a proper compiler.
>
>Please leave attribution lines in place when you post a followup.
>I do not give permission to quote anything I write here without
>proper attribution.

It's just bonita under a different name. Ignore it and it will go away.

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

#153630

> It's just bonita under a different name. Ignore it and it will go away.

I'm not Scott whatever.

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

#153636

On 8/14/20 1:56 AM, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Scott Newman <scott69@gmail.com> writes:
...
> It's just bonita under a different name. Ignore it and it will go away.

Bonita and Scott have very different styles of obnoxiousness - what led
you to the conclusion that they're the same person?

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

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

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

csiph-web