Re: bart again (UCX64)

From	Kaz Kylheku <864-117-4973@kylheku.com>
Newsgroups	comp.lang.c
Subject	Re: bart again (UCX64)
Date	2023-09-07 06:10 +0000
Organization	A noiseless patient Spider
Message-ID	<20230906223634.465@kylheku.com> (permalink)
References	(17 earlier) <ud5gkt$1kj5t$1@dont-email.me> <87tts9sbo8.fsf@bsb.me.uk> <b9e00c9c-e879-49d2-a00a-05256b87d766n@googlegroups.com> <87v8coqcpa.fsf@bsb.me.uk> <86zg1ymvvv.fsf@linuxsc.com>

Show all headers | View raw

On 2023-09-07, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
> [...]
>
>>> Compilers will still accept functions which return
>>> garbage values.  Presumably for backwards compatibility,
>>
>> I suspect it's also because detecting the cases that are actual
>> errors is hard [...]
>
> Besides being theoretically impossible, it's not practical
> because of C allowing separate compilation.  To get an answer
> (potentially) requires examining the entire program.

But why would that even be a goal?

If you need to know what a function in another translation unit
does in order to know whether or not the function "falls off the end",
that's a code smell.

Diagnostics that flag some correct programs are par for the course
in static checking. That's what you accept in order to find problems
without running the program.

For instance, this snippet requires diagnosis:

  int x = 3;
  char *cpx = &x;
  int *ipx = cpx;
  printf("%s\n", *cpx); // assumed to be declared properly

The rule of thub in C is that most pointer conversions are a code smell,
and so are diagnosed. The requirement for diagnosis is all which is
rendering the code incorrect; without it, it would be correct, as 
would an edited version with casts put in.

That's a clear example of a diagnostic rule which is not accurate
(and we take it for granted that way, even like it).

No I can see that the bar has to be fairly high for making something a
required diagnostic in the international language standard, given that
implementors can already diagnose whatever they want.

The users who want diagnostics about ends of value-returning functions
being reached (and even stop the program in that situation) are getting
them from compilers.

However you look at it, there doesn't seem to be a pressing need to push
that into the language. Sure.

> Most C
> programs are split into several translation units, with only one
> being compiled at a time.  I hope I don't have to explain that
> any kind of whole-program diagnostic like this is a non-starter
> given the C compilation model.

It's not just that, but run-time conditions:

    if ((*gpio32_ptr & FOO_MASK) != 0)
      return 42;
  }

I'm quite puzzled by your angle which seems to be that if the
reachability diagnostic cannot be done accurately, due to theory,
translation units and run-time conditions/inputs, then it's
a bad diagnostic not worth doing (or at least not worth having
right in the language). Pardon me if I'm misconstruing antyhing.

Do you have in mind examples of situations in which false positives
would cause problems, or even just irk the programmer?

Say under some simple rule requiring that that if reaching the end of a
function is conditional on the value of one or more expressions,
they must be constant expressions whose values prevent that.

What would be undesirable about working with that?

Say that mountains of legacy code aren't an issue. (Or that they
are, but what else?)

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

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

Thread

Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 18:11 +0100
  Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-03 11:31 -0700
  Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-03 20:07 +0100
    Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-03 22:08 +0100
      Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 03:16 +0100
  Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 10:54 +0200
    Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 11:06 +0100
      Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-04 14:54 +0100
        Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-04 22:02 +0100
          Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-05 01:31 +0100
            Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-05 02:24 +0100
              Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 04:29 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-05 21:06 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 01:03 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 20:58 +0100
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-06 19:21 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 20:18 +0100
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-06 13:07 +0100
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 22:41 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 15:56 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 00:53 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-06 18:47 -0700
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 17:25 -0700
            Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-04 18:30 -0700
              Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-06 03:04 +0100
                Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-06 21:48 -0700
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 06:10 +0000
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-07 02:06 -0700
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 15:52 +0000
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:18 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 15:28 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-07 16:54 +0200
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:02 +0100
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-07 16:12 +0000
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:17 +0000
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:37 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 14:51 -0700
                Re: bart again (UCX64) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2023-09-08 00:46 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:06 +0200
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 10:19 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 15:55 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 15:16 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:02 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 16:15 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 17:51 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:24 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:53 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:34 +0000
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:25 +0000
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 21:37 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 21:02 +0000
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:14 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 16:09 -0700
                Re: bart again (UCX64) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-07 17:34 +0100
                Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-07 17:22 +0000
                Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-07 11:44 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 15:16 -0700
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-07 23:48 +0100
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-07 17:16 -0700
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 11:16 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 10:51 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 13:00 +0200
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:05 +0100
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:11 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:56 +0000
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 00:47 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:49 +0200
                Re: bart again (UCX64) Richard Damon <Richard@Damon-Family.org> - 2023-09-09 10:27 -0700
                Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-08 05:03 -0700
                Re: bart again (UCX64) Bart <bc@freeuk.com> - 2023-09-08 13:39 +0100
                Re: bart again (UCX64) candycanearter07 <no@thanks.net> - 2023-09-08 07:49 -0500
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:07 +0000
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-09 18:51 +0200
                Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-08 16:35 +0200
                Re: bart again (UCX64) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-09 01:04 +0000
      Re: bart again (UCX64) scott@slp53.sl.home (Scott Lurndal) - 2023-09-04 14:14 +0000
      Re: bart again (UCX64) David Brown <david.brown@hesbynett.no> - 2023-09-04 16:59 +0200
        Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 15:41 -0700
          Re: bart again (UCX64) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-04 18:15 -0700
            Re: bart again (UCX64) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-04 18:57 -0700

csiph-web