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

Groups > comp.lang.c > #379503

Re: Call to a function

Show all headers | View raw

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2023-11-10, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Having a shared understanding on this threshold question is a
>> necessary prerequisite to addressing the larger question.  If you
>> can't or won't agree that not being strictly conforming is by
>> itself sufficient basis for not accepting a program, then there
>> seems little point in continuing, as my answer depends on that
>> premise for its conclusion.
>
> But the following isn't strictly confroming:
>
>  int x = 65536;
>
> do you think that an implementation whose int is 32 bits wide has
> grounds for rejecting it because it's not strictly conforming?
>
> We generally expect correct programs that make use of
> implementation-defined characteristics to be translated.
>
> The requirement to accept strictly conforming programs does not add up
> to a blanket permission to reject non-strictly conforming programs.

I think you are in effect asking two question.  The first question
is does the C standard allow non-strictly-conforming code not to be
accepted, even if the code is reasonable for the system being
targeted?  As I read the C standard, the answer to that question is
an unequivocal yes.

The second question is something like, is this a good idea?

Let me give a personal answer.  It doesn't bother me that the C
standard allows such programs not to be accepted (with implied
clause, by conforming implementations).  I say it doesn't bother me
in the same way that the C standard requires implementations to be
able to translate and execute only one program, and still be
conforming.  No compiler worth using is going to reject the
statement 'int x = 65536;' on a 32-bit platform.  Sure, the C
standard allows it, but nobody would use such a compiler, and it's
so much effort to write a C compiler that no one would do that,
except maybe as a joke.  If that's what they want, more power to
them - it will be funny for about 5 minutes.

On the other hand, consider this statement

    long pbits = 0240404242004042424254;

This statement compiles fine on my colo server, which runs linux,
and has 64-bit longs.  But if I were to compile it on a system with
32-bit longs, the compiler is within its rights to say "oops, bad
program, I'm not going to translate this garbage".  Personally I
view that behavior as a positive, so I'm glad the C standard allows
it.

The C standard deliberately sets a low bar.  In practice the low
bar doesn't matter at all, because compiler writers want to produce
a useful, above and beyond what the C standard might require.  And
in those cases like the 'long' assignment example above, there is a
benefit to compilers having the option to turn down the program.
The key phrase there is "having the option".  Different people have
different requirements and want different behaviors.  It's good
that the C standard recognizes that and allows a wide range of
choices, while still setting a reasonable bar for what programs
must be accepted.

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

Thread

Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-10 03:37 -0800
  Re: Call to a function Kaz Kylheku <864-117-4973@kylheku.com> - 2023-11-10 22:04 +0000
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 08:14 -0800
  Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-13 21:35 +0200
    Re: Call to a function Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-11-13 12:48 -0800
    Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-13 19:17 -0800
      Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-16 13:47 +0200
        Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-11-16 06:39 -0800
          Re: Call to a function Phil Carmody <pc+usenet@asdf.org> - 2023-11-21 01:29 +0200
            Re: Call to a function James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-11-21 23:21 -0500
            Re: Call to a function Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-12-24 11:12 -0800

csiph-web