Path: csiph.com!weretis.net!feeder8.news.weretis.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Libraries using longjmp for error handling Date: Thu, 28 Sep 2023 22:45:24 -0700 Organization: A noiseless patient Spider Lines: 71 Message-ID: <86lecph6rv.fsf@linuxsc.com> References: <65SQM.565977$9o89.411905@fx05.ams4> <20230928160237.9796f1896cb0be293bd24b76@gmail.moc> <87jzsae7jm.fsf@bsb.me.uk> <20230928183129.fb386b543c40cd56340ca40f@gmail.moc> <20230928093424.111@kylheku.com> <8634yxj3uh.fsf@linuxsc.com> <87a5t5sr2j.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="13636bbb038e3a1f79d11dd50eec8409"; logging-data="154330"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX198WwT7hXUSaIfl3JFJBp3fU05GYcmA/oY=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:BKcSqH0OqPgM3gpUkoGyD1xD/sU= sha1:YntD5pACYHRqAxuU0Q604Qzww2Q= Xref: csiph.com comp.lang.c:176706 Keith Thompson writes: > Tim Rentsch writes: > >> Kaz Kylheku <864-117-4973@kylheku.com> writes: >> >>> On 2023-09-28, Anton Shepelev 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).