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

Groups > comp.lang.c > #152532

Re: longer 'char literals' meaning in c

Show all headers | View raw

Spiros Bousbouras <spibou@gmail.com> writes:

> On Sun, 24 May 2020 17:36:26 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>
>>> On Thu, 07 May 2020 13:48:23 GMT
>>> Spiros Bousbouras <spibou@gmail.com> wrote:
>>>
>>>> 1.  The documentation of the implementation must describe an
>>>> algorithm [*] which for every "integer character constant
>>>> containing more than one character" (MT1CC for short) returns an
>>>> integer value.
>>>
>>> Here's an amusing way to do so.  The first MT1CC encountered gets
>>> the value -1.  Every new MT1CC encountered , if it has been
>>> encountered before , gets the same value as before , otherwise gets
>>> the value N-1 where N is the minimum value which has been assigned
>>> to a MT1CC up to that point.  Perhaps the programmer will be able to
>>> decide with a command line flag whether the list of MT1CC already
>>> encountered gets reset every time translation moves to a new
>>> translation unit given on the command line or the list gets added to
>>> over the whole compilation.
>
> [...]
>
>> This scheme is not conforming.  The constants chosen by a given
>> implementation must be the same from program to program, even
>> if compiled on a different computer.  There is no way to do
>> that using a scheme like the one described above.
>
> Why must they be the same ?

They must be the same because that is how the Standard's authors
expect people will read it, and most people do indeed read it
that way.  One way to see this is to compare the wording used for
character constants with the wording used for floating-point
constants.  With character constants, the Standard says the value
is implementation defined.  With floating-point constants, the
Standard says the value is chosen in an implementation-defined
manner.  Behavior that is implementation defined is expected to
be fixed by the documentation.  Behavior that is chosen in an
implementation-defined manner allows variation in what choice is
made.  Note the last sentence of 6.4.4.2 p5:  "All floating
constants of the same source form shall convert to the same
internal format with the same value."  This sentence was added in
C11 because it was noticed that without it (and since the value
was chosen in an implementation-defined manner) an implementation
would be free to choose different values for two floating-point
constants that are character-for-character identical.  Saying
that isn't necessary for plain implementation-defined behavior,
because those choices are fixed;  it is necessary for behavior
that is chosen in an implementation-defined manner, because
choices in those cases are allowed to vary from place to place.
Try a search through the Standard for "implementation-defined
manner" and I think you'll see what I mean.

Another way to see that values must always be the same is that
the feature would be essentially useless without it.  For
example, we couldn't write a C library that uses character
constants, because the values wouldn't always be the same as the
program that is calling it.  Completely impractical.  The people
who write the ISO C standard tend to be rather practical folks.
Despite what some people here in the newsgroup might have you
believe, the C standard is not meant to be read like a math
textbook, where you mustn't assume anything that isn't precisely
and explicitly stated.  The people who write the Standard, and
almost everyone who reads it, simply don't consider as sensible
an interpretation that is highly contorted, ridiculous, or made
perversely.  Yes, sometimes it can be useful to discuss such
interpretations, and that is why comp.std.c exists.  But for
purposes of understanding the C language, in the same sense that
it is understood by compiler writers and the Standard's authors,
it's better just to ignore any idea that looks contrived or
contorted.


>> (Perhaps this suggestion was meant as a joke.  If it was, well,
>> did you hear about the snail who crawled into a car dealership?)
>
> No , I meant it seriously

I didn't think so but I wasn't sure.  No harm done I hope.

> and no I haven't heard the snail joke.

A snail crawls into a car dealership and asks for a fast and
eye-catching sports car.  "Also," he says, "I want the car to
have a big red S detailed on each side, and on the back."  The
salesman says, "I understand why you would want a fast and good
looking car, but why the S detailings?"  The snail replied, "When
I speed by, I want people to turn their heads and say 'Look at
that S car go!'."

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

Thread

Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 00:47 +0000
  Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-04 20:08 -0700
  Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 23:52 -0400
    Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 17:10 +0000
      Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 13:41 -0700
        Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 22:29 +0000
          Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 16:18 -0700
            Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 02:33 +0000
              Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 20:06 -0700
                Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 18:57 +0000
                Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-06 13:37 -0700
                Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-07 13:48 +0000
                Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-07 13:58 +0000
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-24 17:36 -0700
                Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-25 00:56 +0000
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-29 22:53 -0700
                Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-07 18:01 -0700
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-30 10:53 -0700
                Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-30 15:11 -0700
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-24 18:19 -0700
                Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-24 20:06 -0700
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-28 04:51 -0700
                Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-28 17:45 -0700
                Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-26 07:02 -0700
      Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-05 20:18 -0400
        Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 20:01 +0000
          Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-06 18:20 -0400
            Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-28 04:42 -0700
              Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-06-28 17:13 -0700
    Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-06-03 09:08 -0700

csiph-web