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

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

Libraries using longjmp for error handling (was: Re: More on NNTP testing)

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Libraries using longjmp for error handling (was: Re: More on NNTP testing) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-09-27 22:52 +0000
    Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2023-09-28 08:19 +0800
      Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 02:18 +0100
        Re: Libraries using longjmp for error handling Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2023-09-28 22:30 +0000
          Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 22:33 +0000
            Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 01:41 +0300
              Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 23:45 +0000
            Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-28 17:35 -0700
              Re: Libraries using longjmp for error handling David Brown <david.brown@hesbynett.no> - 2023-09-29 16:49 +0200
        Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 18:24 -0700
          Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 03:19 +0100
            Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 07:46 -0700
              Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 21:02 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 21:56 -0700
                  Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 00:06 +0100
                    Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-30 20:35 -0700
                      Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 14:44 +0300
                      Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 15:45 +0100
                        Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 09:28 -0700
                          Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-01 20:49 +0100
                            Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-02 02:31 -0700
                              Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-10-02 23:55 +0100
                                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-03 05:01 -0700
              Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 23:58 +0300
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-10-01 02:52 -0700
                  Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-10-01 14:33 +0300
    Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 01:48 +0100
    Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 05:11 +0000
      Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 06:26 +0000
    Re: Libraries using longjmp for error handling (was: Re: More on NNTP testing) Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 16:02 +0300
      Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 14:44 +0100
        Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-28 18:31 +0300
          Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 16:43 +0000
            Re: Libraries using longjmp for error handling scott@slp53.sl.home (Scott Lurndal) - 2023-09-28 17:00 +0000
              Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 17:16 +0000
              Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 19:38 +0100
            Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 16:05 -0700
              Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 00:26 +0000
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 23:20 -0700
              Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-28 18:31 -0700
                Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 03:24 +0100
                  Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 03:12 +0000
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 22:45 -0700
                  Re: Libraries using longjmp for error handling Spiros Bousbouras <spibou@gmail.com> - 2023-09-29 12:02 +0000
                    Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 08:10 -0700
                      Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-29 17:03 +0100
                        Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 10:15 -0700
                        Re: Libraries using longjmp for error handling gazelle@shell.xmission.com (Kenny McCormack) - 2023-09-29 17:17 +0000
                      Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 18:53 +0000
                    Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 18:11 +0300
                      Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 10:20 -0700
                        Re: Libraries using longjmp for error handling Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-09-29 11:30 -0700
                  Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-29 18:31 +0000
          Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 19:27 +0100
            Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 20:24 +0000
              Re: Libraries using longjmp for error handling Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-09-28 22:23 +0100
                Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-28 15:43 -0700
                Re: Libraries using longjmp for error handling Kaz Kylheku <864-117-4973@kylheku.com> - 2023-09-28 23:11 +0000
                  Re: Libraries using longjmp for error handling Anton Shepelev <anton.txt@gmail.moc> - 2023-09-29 17:23 +0300
                    Re: Libraries using longjmp for error handling Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-09-29 08:19 -0700
          Re: Libraries using longjmp for error handling David Brown <david.brown@hesbynett.no> - 2023-09-28 21:57 +0200
    Re: Libraries using longjmp for error handling Richard Kettlewell <invalid@invalid.invalid> - 2023-09-30 09:37 +0100

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

#176699 — Re: Libraries using longjmp for error handling

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>>   double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> Two things:
>>>
>>> Firstly, it's not a true literal because it is a mutable object in
>>> automatic storage.
>>
>> It most definitely is a literal, both in the original meaning
>> of the word, and also as used in the ISO C standard.
>
> C doesn't not define what the word "literal" means.  It has no syntactic
> category called "literal".  It has distinct constructs "string literal"
> and "compound literal".
>
> You've asserted in the past that there's a logical reason behind using
> the term "literal" for these two constructs and not for others, such as
> integer constants.  I'm not particularly interested in debating that
> point again, but I see no support in the standard for that assertion.
> (The standard also uses the word "literal" as an adjective; see for
> example N1570 6.1p1 where it refers to terminals in the grammar.)
>
> My point is that any discussion of what is or is not a "true literal" is
> unlikely to yield any meaningful result.

I agree, though it might be interesting to see if

  ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1:
  Fundamental terms.

sheds any light on the usage.  This document is one of the standard's
"Normative References".  I don't have this document, nor do I have access
to the right sort of library any more, so I can't help.

-- 
Ben.

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

#176700 — Re: Libraries using longjmp for error handling

On 2023-09-29, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> My point is that any discussion of what is or is not a "true literal" is
>> unlikely to yield any meaningful result.
>
> I agree, though it might be interesting to see if
>
>   ISO/IEC 2382−1:1993, Information technology — Vocabulary — Part 1:
>   Fundamental terms.
>
> sheds any light on the usage.  This document is one of the standard's
> "Normative References".  I don't have this document, nor do I have access
> to the right sort of library any more, so I can't help.

FYI, I looked at this quite long ago. At that time I hunted down a
leaked version which is under a different number:
IS 14692-1 (1999).  IS == Indian Standard.

I see that this can still be found.

The document does not mention "literal".

You will likely agree with my observation that the document is rather
short, and lacks substance.

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

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

#176706 — Re: Libraries using longjmp for error handling

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>>> On 2023-09-28, Anton Shepelev <anton.txt@gmail.moc> wrote:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>>   double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> Two things:
>>>
>>> Firstly, it's not a true literal because it is a mutable object in
>>> automatic storage.
>>
>> It most definitely is a literal, both in the original meaning
>> of the word, and also as used in the ISO C standard.
>
> C doesn't not define what the word "literal" means.  It has no
> syntactic category called "literal".  It has distinct constructs
> "string literal" and "compound literal".

I didn't say the C standard defines the term literal, only that
the standard uses the word literal in the same sense as the
original meaning.  (To be clear, the uses I'm talking about are
as part of compound terms "string literal" and "compound literal",
but the sense of common meaning is the same in both.)

It's true that string literals and compound literals are
different constructs, but they are obviously related, and they
are referred to together in a few places in the C standard.

> You've asserted in the past that there's a logical reason behind
> using the term "literal" for these two constructs and not for
> others, such as integer constants.  I'm not particularly interested
> in debating that point again, but I see no support in the standard
> for that assertion.  (The standard also uses the word "literal" as
> an adjective;  see for example N1570 6.1p1 where it refers to
> terminals in the grammar.)

I don't have my previous posting in front of me, but what I think
I said is that string literals and compound literals are both
consistent with the original meaning (in the programming world)
of the word literal, and that other constructs such as integer
constants do not share that aspect of semantic sameness.  Also
IIRC I stated my view that the semantic distinction is more
valuable than a possible syntactic distinction, and so that is
worth preserving, i.e., that string literals and compound
literals deserve to be associated with the term "literal", but
constants should not.

> My point is that any discussion of what is or is not a "true
> literal" is unlikely to yield any meaningful result.

I'm not saying anything about whether something is a "true
literal", whatever that might be.  What I am saying is that
a compound literal is a literal in the same sense that the
term was originally used, and that sense is consistent with
both string literals and compound literals (but not with
constants such as integer constants or floating constants).

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

#176723 — Re: Libraries using longjmp for error handling

On Thu, 28 Sep 2023 22:45:24 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> > You've asserted in the past that there's a logical reason behind
> > using the term "literal" for these two constructs and not for
> > others, such as integer constants.  I'm not particularly interested
> > in debating that point again, but I see no support in the standard
> > for that assertion.  (The standard also uses the word "literal" as
> > an adjective;  see for example N1570 6.1p1 where it refers to
> > terminals in the grammar.)
> 
> I don't have my previous posting in front of me,

<86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .

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

#176739 — Re: Libraries using longjmp for error handling

Spiros Bousbouras <spibou@gmail.com> writes:

> On Thu, 28 Sep 2023 22:45:24 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> You've asserted in the past that there's a logical reason behind
>>> using the term "literal" for these two constructs and not for
>>> others, such as integer constants.  I'm not particularly interested
>>> in debating that point again, but I see no support in the standard
>>> for that assertion.  (The standard also uses the word "literal" as
>>> an adjective;  see for example N1570 6.1p1 where it refers to
>>> terminals in the grammar.)
>>
>> I don't have my previous posting in front of me,
>
> <86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .

I know references like that are helpful for some people,
however they are not for me.[*]  Thank you though for
trying to help.

[*] And I have no desire to change that, at least not any time
soon.

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

#176746 — Re: Libraries using longjmp for error handling

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Thu, 28 Sep 2023 22:45:24 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> You've asserted in the past that there's a logical reason behind
>>>> using the term "literal" for these two constructs and not for
>>>> others, such as integer constants.  I'm not particularly interested
>>>> in debating that point again, but I see no support in the standard
>>>> for that assertion.  (The standard also uses the word "literal" as
>>>> an adjective;  see for example N1570 6.1p1 where it refers to
>>>> terminals in the grammar.)
>>>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .
>
> I know references like that are helpful for some people,
> however they are not for me.[*]  Thank you though for
> trying to help.

I can't help wondering what you mean.  You seem to use GNUS, as I do,
and I find such reference the most useful of all as just one click and
I'm, reading the referenced article in the same window.

> [*] And I have no desire to change that, at least not any time
> soon.

-- 
Ben.

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

#176748 — Re: Libraries using longjmp for error handling

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Spiros Bousbouras <spibou@gmail.com> writes:

[access to previous articles]

>>> <86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> I know references like that are helpful for some people,
>> however they are not for me.[*]  Thank you though for
>> trying to help.
>
> I can't help wondering what you mean.  You seem to use GNUS, as I
> do, and I find such reference the most useful of all as just one
> click and I'm, reading the referenced article in the same window.

I expect you are simply underestimating the depth of my ignorance.
Even though I have been using emacs for more than 40 years (and the
emacs session into which I am typing this message has been up for
more than two and half years), my knowledge of emacs commands (and
including gnus commands) is very selective.  My typical working
mode is to learn just enough to get by, and accumulate new
awareness only when there is some kind of nudge to do so.  So far I
haven't gotten such a nudge in the direction of this capability
(and it is not at all clear how big a nudge it would take to cause
any change).

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

#176749 — Re: Libraries using longjmp for error handling

In article <87jzs9arwe.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Spiros Bousbouras <spibou@gmail.com> writes:
>>
>>> On Thu, 28 Sep 2023 22:45:24 -0700
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> You've asserted in the past that there's a logical reason behind
>>>>> using the term "literal" for these two constructs and not for
>>>>> others, such as integer constants.  I'm not particularly interested
>>>>> in debating that point again, but I see no support in the standard
>>>>> for that assertion.  (The standard also uses the word "literal" as
>>>>> an adjective;  see for example N1570 6.1p1 where it refers to
>>>>> terminals in the grammar.)
>>>>
>>>> I don't have my previous posting in front of me,
>>>
>>> <86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> I know references like that are helpful for some people,
>> however they are not for me.[*]  Thank you though for
>> trying to help.
>
>I can't help wondering what you mean.  You seem to use GNUS, as I do,
>and I find such reference the most useful of all as just one click and
>I'm, reading the referenced article in the same window.
>
>> [*] And I have no desire to change that, at least not any time
>> soon.

Be that as it may, here is (one of) the article(s) to which we are all
referring:

From tr.17687@z991.linuxsc.com Fri Sep 29 11:14:57 MDT 2023
Article: 1091108 of comp.lang.c
Path: nnrp.xmission!xmission!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: you think rust may outthrone c?
Date: Sat, 12 Aug 2023 10:57:42 -0700
Message-ID: <86r0o887op.fsf@linuxsc.com>

...
The word literal, used as a noun when describing programming
languages, came into vogue sometime after it became common to
specify language syntax by using a formal grammar (usually
expressed in some variation of Backus-Naur Form);  roughly the
1970s timeframe.  A typical usage would be for "literal" to be
synonymous with "terminal symbol", or perhaps with just a subset
of terminal symbols, as used in the rules of grammar.  In some
cases the words "constant" and "literal" were used more or less
interchangeably.

A good decade earlier, however, the word literal was used in a
somewhat different programming language context, not as part of
describing a language but as an element of the language.  The
assembly language for IBM System/360 had constants, both ordinary
numeric and character constants, and symbolic constants (defined
with EQU).  Constants could be used as direct operands for some
instructions, depending on the particulars of the instruction and
for which operand, and represented values encoded directly in the
instruction.  Distinct from constants there were also /literals/,
a distinct category of operand that produced the address of an
initialized anonymous region of memory.  Here are two example
lines of assembly, to illustrate the difference:

        OI    VAL+2,X'F0'
        C     3,=F'1000'

In the first line, there are two constants, 2 and X'F0'.  These
tokens are numerical quantities that are used directly in the
generated instruction.  (In the case of the constant 2 the value
is added to the address VAL, and it is the sum that is used to
produce the bytes of the instruction, but the key property is
that the value 2 participates locally, and not remotely.)

The second line has a constant 3 and a literal =F'1000'.  Like in
the first line, the value 3 is used directly in the generated
instruction.  The literal =F'1000' is not used directly.  Instead,
the assembler keeps track of literals used in the program, and
uses them to initialize areas of memory elsewhere in the program.
A use of a literal, such as the =F'1000' here, results in the
address of the memory area reserved for the value of the literal.
(There are some further details about literals, such as literal
pools and the LTORG directive, that I won't explain because those
details are not important to the discussion.)

Note the parallels between how these terms are used in assembly
language and in C.  Constants are used to generate code but appear
only implicitly;  literals always occupy areas of memory (objects)
and use of a literal causes its address (lvalue) to be part of a
generated instruction.  The distinction between constants and
literals is primarily a semantic distinction, not a syntactic one.

Besides being more historically faithful, having two different
terms provides a useful semantic distinction that would disappear
if the term "literal" were used for both concepts.


>> Given a choice between the level of confusion seen in the C++
>> standard and the level of confusion seen in the C standard ("integer
>> constant" and "integer constant expression" is confusing?  really?)
>> I'm happy to be on the side of C's choice any day of the week and
>> twice on Sunday.  Please cast my vote to continue using the terms
>> "constant" and "literal" as they are used in the C standard.
>
> I use those terms simply because that's how they're used in the C
> standard.

Obviously it's a good idea to use terminology in the C standard
when talking about the C language.  My point though is that the
terminology used in the C standard is a better choice both
historically and semantically.


-- 
I voted for Trump because I thought he'd make pussy grabbing legal.
I honestly don't see any other way America could be made great again.

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

#176758 — Re: Libraries using longjmp for error handling

On 2023-09-29, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Spiros Bousbouras <spibou@gmail.com> writes:
>
>> On Thu, 28 Sep 2023 22:45:24 -0700
>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> You've asserted in the past that there's a logical reason behind
>>>> using the term "literal" for these two constructs and not for
>>>> others, such as integer constants.  I'm not particularly interested
>>>> in debating that point again, but I see no support in the standard
>>>> for that assertion.  (The standard also uses the word "literal" as
>>>> an adjective;  see for example N1570 6.1p1 where it refers to
>>>> terminals in the grammar.)
>>>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com>  and  <86fs4k6pgq.fsf@linuxsc.com> .
>
> I know references like that are helpful for some people,
> however they are not for me.[*]  Thank you though for
> trying to help.
>
> [*] And I have no desire to change that, at least not any time
> soon.

I see you are using Gnus, the Emacs-based newsreader, connected
to the same NTTP server as what I'm using.

The articles referenced above are still held by the server.

In the SLRN newsreader that I'm using, there is a simple ESC-l
command that prompts for the message ID.  It finds the article
and brings it into the article display. I was able to find
the articles this way.

It would be astonishing if the equivalent trick couldn't be done with
Gnus.

I quit Emacs in 1994, and have never used Gnus, but the documentation
says:

  Article Keymap
  --------------

  [ ... ]

  C-c ^
      If point is in the neighborhood of a Message-Id and you press r,
      Gnus will try to get that article from the server
      (gnus-article-refer-article). 

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

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

#176740 — Re: Libraries using longjmp for error handling

Spiros Bousbouras to Tim Rentsch:

> > I don't have my previous posting in front of me,
>
> <86r0o887op.fsf@linuxsc.com>  and
> <86fs4k6pgq.fsf@linuxsc.com> .

What fine Message-Id:s!  Does FSF stand for the Free
Software Fondation?  Tim might appreciate working URLs to
archived messages:

   http://al.howardknight.net/?ID=169556843200
   http://al.howardknight.net/?ID=169556849300

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#176750 — Re: Libraries using longjmp for error handling

Anton Shepelev <anton.txt@gmail.moc> writes:

> Spiros Bousbouras to Tim Rentsch:
>
>>> I don't have my previous posting in front of me,
>>
>> <86r0o887op.fsf@linuxsc.com>  and
>> <86fs4k6pgq.fsf@linuxsc.com> .
>
> What fine Message-Id:s!

Thank you.  I can assure you that I played no conscious role
in selecting them. :)

> Does FSF stand for the Free Software Fondation?

Certainly it might.  The colo server here runs ubuntu linux.

> Tim might appreciate working URLs to archived messages:
>
>    http://al.howardknight.net/?ID=169556843200
>    http://al.howardknight.net/?ID=169556849300

There are cases where I might.  In this particular case I
felt confident enough simply relying on my memory, even
though it seems to be more and more in need of ECC as years
go by.

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

#176756 — Re: Libraries using longjmp for error handling

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Anton Shepelev <anton.txt@gmail.moc> writes:
>> Spiros Bousbouras to Tim Rentsch:
>>>> I don't have my previous posting in front of me,
>>>
>>> <86r0o887op.fsf@linuxsc.com>  and
>>> <86fs4k6pgq.fsf@linuxsc.com> .
>>
>> What fine Message-Id:s!
>
> Thank you.  I can assure you that I played no conscious role
> in selecting them. :)
>
>> Does FSF stand for the Free Software Fondation?
>
> Certainly it might.  The colo server here runs ubuntu linux.

Not relevant.  Gnus includes ".fsf" in the Message-Ids it generates.

It also includes the domain name from which you post.  (linuxsc.com in
your case).  I prefer not to include that information, so I have

    (setq message-user-fqdn "nosuchdomain.example.com")

in my .emacs file.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */

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

#176757 — Re: Libraries using longjmp for error handling

On 2023-09-29, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> I'm not saying anything about whether something is a "true
> literal", whatever that might be.  What I am saying is that
> a compound literal is a literal in the same sense that the
> term was originally used, and that sense is consistent with
> both string literals and compound literals (but not with
> constants such as integer constants or floating constants).

Integer constants are not literals according some supposedly widely
understood sixty-year-old meaning of "literal"?

Are you okay?

C neglecting to use "literal" for integer constants is just a mistake.
It's okay to recognize that.

FWIW, the latest C draft does now have "compound literal constant" which
is defined using constexpr storage class. If you make one of these
beasties with int type, and give it a value like 42, then you
finally have a literal constant in C, of type int, with value 42.
That token 42 is, sadly, not called a literal.


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

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

#176663 — Re: Libraries using longjmp for error handling

Anton Shepelev <anton.txt@gmail.moc> writes:

> Ben Bacarisse to Anton Shepelev:
>
>> To nit-pick a bit, in C, there is no need to declare
>> anything if you want to ignore an "output parameter".
>> Taking strtod as a (poor) example:
>>
>>   double d = strtod(str, &(char *){0});
>
> Ah, but this is one of the strangest and craziest
> innovations of post-modern C -- the ability to pass a
> pointer (as it were) to a literal, rather than to a proper
> variable.

The C term is an object -- a region on memory that can hold values of
some type or other.  A variable is a named object (though C does not
define the term variable), whereas a compound literal denotes an
anonymous object.

Why do you consider anonymous objects to be strange and crazy?

> I say post-modern, because the adjective has just
> the right connotations of surrealism, abstract art.

Neither surrealism not abstract art have much to do with postmodernism
as it is now understood.  (A few early abstract artists called
themselves postmodernists, but they did not mean what we mean by the
term.)

Outside of the field, the term "postmodernism" has come to mean little
more that "everything that makes me uncomfortable about the humanities",
but that's a very lazy way to use the term.

Anyway, what is "postmodern" about anonymous objects?

> I
> hadn't even thought of doing that.  Programming languages
> seem obsessed with letting the programmer do as much as
> possible in place and inline: treating everyting as an
> expression, the comma operator, the ternary conditional
> operator, lambdas, anonymous functions and types, and
> now -- anonymous variables or literals -- to the detriment
> of the academic approach of giving every thing its own
> identifer.

Why do you associate the term academic with naming everything?  What's
the connection?

Mind you, the term is most often used (again rather lazily) to mean
"everything I don't like about modern programming" which would usually
include the functional approach you are criticising here, so it's
refreshing to see it used favourably.

>> > The above seems to suggest that the unusual practice of
>> > signalling an error via an output parameter is
>> > preferable from at lest the viewpoint of encouraging the
>> > programmer to handle errors...
>>
>> This may be the case in C (where tagged union return
>> values would be a pain in the neck), but in other
>> languages I'd say it's backwards.  If the error is a valid
>> but alternate return value the programmer /can't/ ignore
>> it.
>
> He can still work with the tagged union as if the error-
> member did not exist.  He can still treat the return value
> as if it always contained the result of a successful
> invocation.  With the output parameter, ignoring an error
> requires some effort, and that effort is visible in the
> code, e.g. as a dummy variable whose value is never used.

I can't see how you come to this conclusion.  Is it only about C or are
you considering other more strongly-typed languages?

Example: in Haskell a table lookup can fail (the key may not exist in
the map) so the return type of lookup on a map if integers is "Maybe
Integer".  The (polymorphic) Maybe type is like a tagged union.  It's
values are either "Nothing" or "Just x" where x is an integer.  You
can't ignore this fact; the code must explicitly handle this return
type.  (Of course in Haskell there is no alternative.  Without
modifiable variables one can't implement an "output parameter".)

Can you give an example of what you mean in C?  I could come up with an
example, but then it might be tailored to backing up my point of view!

>> > Furthermore, it is rather annoying in a language with a
>> > single return value, to have that primary ouput channel
>> > used to signal errors, forcing the programmer to resort
>> > the auxiliary channel of ouput parameters to return
>> > actual results.  Yes, I do it all the time, and your
>> > post may prompt me to try the alternative.
>>
>> One solution, in other languages, is to provide a simple
>> way to use that primary channel for both.  Every call
>> would have to code to handle the options, even if that
>> ended up being explict "ignore everything but the
>> successful return" code.
>
> Am I right that implementing that "simple" method is a major
> difficulty in compiler design?

I would not have thought so.  I've implemented a version in a functional
language, but that was not a traditional compiler.  Where is the
difficulty you see?

The problem in C would be the cost (larger return values) combined with
the fact that C has no clean way to handle tagged unions so the code
would be a mess.

-- 
Ben.

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

#176667 — Re: Libraries using longjmp for error handling

On 2023-09-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Anton Shepelev <anton.txt@gmail.moc> writes:
>
>> Ben Bacarisse to Anton Shepelev:
>>
>>> To nit-pick a bit, in C, there is no need to declare
>>> anything if you want to ignore an "output parameter".
>>> Taking strtod as a (poor) example:
>>>
>>>   double d = strtod(str, &(char *){0});
>>
>> Ah, but this is one of the strangest and craziest
>> innovations of post-modern C -- the ability to pass a
>> pointer (as it were) to a literal, rather than to a proper
>> variable.
>
> The C term is an object -- a region on memory that can hold values of
> some type or other.  A variable is a named object (though C does not
> define the term variable), whereas a compound literal denotes an
> anonymous object.
>
> Why do you consider anonymous objects to be strange and crazy?

By the way, here is an approach using only C90 syntax:

#include <stdlib.h>
#include <stdio.h>

struct ptr {
  char *ptr[1];
};

struct ptr tmp(void)
{
  struct ptr tmp = { 0 };
  return tmp;
}

int main(int argc, char **argv)
{
  if (argv[1]) {
    double d = strtod(argv[1], tmp().ptr); /* i.e. &tmp().ptr[0] */
    printf("d = %f\n", d);
  }

  return 0;
}

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

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

#176670 — Re: Libraries using longjmp for error handling

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

> On 2023-09-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> Anton Shepelev <anton.txt@gmail.moc> writes:
>>
>>> Ben Bacarisse to Anton Shepelev:
>>>
>>>> To nit-pick a bit, in C, there is no need to declare
>>>> anything if you want to ignore an "output parameter".
>>>> Taking strtod as a (poor) example:
>>>>
>>>>   double d = strtod(str, &(char *){0});
>>>
>>> Ah, but this is one of the strangest and craziest
>>> innovations of post-modern C -- the ability to pass a
>>> pointer (as it were) to a literal, rather than to a proper
>>> variable.
>>
>> The C term is an object -- a region on memory that can hold values of
>> some type or other.  A variable is a named object (though C does not
>> define the term variable), whereas a compound literal denotes an
>> anonymous object.
>>
>> Why do you consider anonymous objects to be strange and crazy?
>
> By the way, here is an approach using only C90 syntax:
>
> #include <stdlib.h>
> #include <stdio.h>
>
> struct ptr {
>   char *ptr[1];
> };
>
> struct ptr tmp(void)
> {
>   struct ptr tmp = { 0 };
>   return tmp;
> }
>
> int main(int argc, char **argv)
> {
>   if (argv[1]) {
>     double d = strtod(argv[1], tmp().ptr); /* i.e. &tmp().ptr[0] */
>     printf("d = %f\n", d);
>   }
>
>   return 0;
> }

Two points...  This is C90 syntax but not C90 semantics.  A C90 function
call is not an lvalue, so neither is the member access expression.
What's more in C99, it's not permitted to modify the returned object
which I assume is the whole point here.  I think it's OK in C11 and
later.

Second point... The context was not declaring a variable in order to
pass an object address to a function that needs it.  So instead of
declaring a variable you declare a struct type, a function and a local
variable within it!

OK, I see the point -- the ptr member in the returned value is sort of
an anonymous object -- but in my opinion it's a stretch.

-- 
Ben.

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

#176676 — Re: Libraries using longjmp for error handling

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
>> On 2023-09-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>
>>> Anton Shepelev <anton.txt@gmail.moc> writes:
>>>
>>>> Ben Bacarisse to Anton Shepelev:
>>>>
>>>>> To nit-pick a bit, in C, there is no need to declare
>>>>> anything if you want to ignore an "output parameter".
>>>>> Taking strtod as a (poor) example:
>>>>>
>>>>>   double d = strtod(str, &(char *){0});
>>>>
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
>>>
>>> The C term is an object -- a region on memory that can hold values of
>>> some type or other.  A variable is a named object (though C does not
>>> define the term variable), whereas a compound literal denotes an
>>> anonymous object.
>>>
>>> Why do you consider anonymous objects to be strange and crazy?
>>
>> By the way, here is an approach using only C90 syntax:
>>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> struct ptr {
>>   char *ptr[1];
>> };
>>
>> struct ptr tmp(void)
>> {
>>   struct ptr tmp = { 0 };
>>   return tmp;
>> }
>>
>> int main(int argc, char **argv)
>> {
>>   if (argv[1]) {
>>     double d = strtod(argv[1], tmp().ptr); /* i.e. &tmp().ptr[0] */
>>     printf("d = %f\n", d);
>>   }
>>
>>   return 0;
>> }
>
> Two points...  This is C90 syntax but not C90 semantics.  A C90 function
> call is not an lvalue, so neither is the member access expression.
> What's more in C99, it's not permitted to modify the returned object
> which I assume is the whole point here.  I think it's OK in C11 and
> later.

Some clarifications.

The result of a function call is not an lvalue in any version of
C (with the disclaimer that I have not checked the C23 draft).

Despite the result of a function call not being an lvalue, it is
legal to use '.' to access a member of a struct value returned by
a function, even in C90.  Member access does not require that the
first operand be an lvalue (although it needs to be an lvalue if
the member access expression is used as an lvalue).

In both C90 and C99, it's undefined behavior to use the pointer
value that results from 'tmp().ptr' to attempt an access, either
for writing or for reading.  It's possible that this omission is
just an oversight, but the plain text of both of the early C
standards says fairly clearly that undefined behavior results.

In C11, it's okay to use the pointer value from 'tmp().ptr' to
read a value, but attempting to store a value using that pointer
is undefined behavior.

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

#176683 — Re: Libraries using longjmp for error handling

On 2023-09-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> On 2023-09-28, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> Anton Shepelev <anton.txt@gmail.moc> writes:
>>>> Ah, but this is one of the strangest and craziest
>>>> innovations of post-modern C -- the ability to pass a
>>>> pointer (as it were) to a literal, rather than to a proper
>>>> variable.
[...]
>>> Why do you consider anonymous objects to be strange and crazy?
>>
>> By the way, here is an approach using only C90 syntax:
>>
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> struct ptr {
>>   char *ptr[1];
>> };
>>
>> struct ptr tmp(void)
>> {
>>   struct ptr tmp = { 0 };
>>   return tmp;
>> }
>>
>> int main(int argc, char **argv)
>> {
>>   if (argv[1]) {
>>     double d = strtod(argv[1], tmp().ptr); /* i.e. &tmp().ptr[0] */
>>     printf("d = %f\n", d);
>>   }
>>
>>   return 0;
>> }
>
> Two points...  This is C90 syntax but not C90 semantics.

Exactly; I didn't say that this is something that was possible in C90.

It's not required to work.

But in, fact, it can work, and when it does, it's because of the
semantics that there is an hidden temporary object there.

Things could go wrong; we have no idea what the lifetime is of that
object; when is its storage reused for something else being
evaluated in a neighboring subesxpression.

The program's evil trick uses a hole in the language.

If we just made it 
  
   struct ptr {
     char ptr;
   };

and then

  &tmp().ptr

then that violates a constraint: taking the address of a non-lvalue.

That constraint does not apply to the array-to-pointer "decay"
conversion, because that would prevent a non-lvalue array from being
simply accessed. We can't do a[2] without producing a pointer to
a[0] which is displaced and dereferenced.

> A C90 function
> call is not an lvalue, so neither is the member access expression.
> What's more in C99, it's not permitted to modify the returned object
> which I assume is the whole point here.  I think it's OK in C11 and
> later.
>
> Second point... The context was not declaring a variable in order to
> pass an object address to a function that needs it.  So instead of
> declaring a variable you declare a struct type, a function and a local
> variable within it!

But I only have to do that once; then invoke tmp().ptr any number of
times I want to get a temporary char *. Or, could, if it were documented
as reliable.

> OK, I see the point -- the ptr member in the returned value is sort of
> an anonymous object -- but in my opinion it's a stretch.

I think the point is that Anton should find the existence of all
anoymous temporary objects repugnant, not just the more recently
introduced ones.

That's why I put this under the "strange and crazy innovations in
post-modern C" remarks.

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

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

#176731 — Re: Libraries using longjmp for error handling

Kaz Kylheku to Ben Bacarisse:

> > OK, I see the point -- the ptr member in the returned
> > value is sort of an anonymous object -- but in my
> > opinion it's a stretch.
>
> I think the point is that Anton should find the existence
> of all anoymous temporary objects repugnant, not just the
> more recently introduced ones.

In that case, I see it as more or less a named object, its
name being the `ptr' field qualified by the function
invocation.  Otherwise, I should find repugnant even simple
expressions, like:

   res = sqr(x) + sqr(y);

where the return value of sqr() is techically some sort of
anonymous object, right?  Well, I do not object to functions
invocations in exprssions, for the reason stated above, and
because the are similar to the universally understood
mathematical notation.

> That's why I put this under the "strange and crazy
> innovations in post-modern C" remarks.

Right.  Many of you will tell me that I have to bend my
mental model to reflect the workings of C rather than trying
to bend C (e.g. by avoiding some techniques) to comply with
my mental model.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  www.asciiribbon.org   -- against proprietary attachments

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

#176743 — Re: Libraries using longjmp for error handling

Anton Shepelev <anton.txt@gmail.moc> writes:

> Kaz Kylheku to Ben Bacarisse:
>
>>> OK, I see the point -- the ptr member in the returned
>>> value is sort of an anonymous object -- but in my
>>> opinion it's a stretch.
>>
>> I think the point is that Anton should find the existence
>> of all anoymous temporary objects repugnant, not just the
>> more recently introduced ones.
>
> In that case, I see it as more or less a named object, its
> name being the `ptr' field qualified by the function
> invocation.  Otherwise, I should find repugnant even simple
> expressions, like:
>
>    res = sqr(x) + sqr(y);
>
> where the return value of sqr() is techically some sort of
> anonymous object, right?  [...]

No, it isn't.  The result of calling sqr(x) is a value, not
an object.  All objects have an address;  the result of sqr(x)
does not.  In an expression like 3+4, the 3 and the 4 are
values, not objects.  That is one reason why the distinction
between constants, which are values and not objects, and
literals, which are anonymous objects, is important.

[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