Richard Kettlewell wrote:

> It’s more than 20 years since I last had to integrate a C library which
> reported errors via longjmp() and I’m still bitter about it.

I have never encountered a library which does that. Which library was
that?

> As a matter of API design, I’d rather C library communicated errors via
> return values (and pointer parameters, where more complex error
> information is required).

Personally, i think that, at least for a library, an error should _only_
be communicated by return value. If more complex information is required,
then the return value can be made more complex. I don't think i've ever
used a library that communicates information via a pointer parameter.

One thing i've experienced in multiple libraries is a system a bit like
what errno.h offers, but done via a pair of subroutines that retrieve and
assign to some hidden global variable. I don't like this for the same
reason i don't like subroutines that use errno (unless they're syscall
wrappers), but in at least two of the cases the library has also come with
a way to set a callback subroutine to automatically deal with errors
instead. This is nice, since it means that the code doesn't get all
obfuscated with error checking after every subroutine call, but it's
annoying that each library needs to come with its own unique subroutine
for this, and i do worry about it being overly general in treating all
errors lethally.

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr. bluemanedhawk.github.io
Warning: Low flying owls. Lost chihuahua.

On 9/28/2023 6:52 AM, Blue-Maned_Hawk wrote:
> Richard Kettlewell wrote:
>
>> It’s more than 20 years since I last had to integrate a C library which
>> reported errors via longjmp() and I’m still bitter about it.

I am not surprised.

> I have never encountered a library which does that. Which library was
> that?
>
>> As a matter of API design, I’d rather C library communicated errors via
>> return values (and pointer parameters, where more complex error
>> information is required).
>
> Personally, i think that, at least for a library, an error should _only_
> be communicated by return value. If more complex information is required,
> then the return value can be made more complex. I don't think i've ever
> used a library that communicates information via a pointer parameter.
>
> One thing i've experienced in multiple libraries is a system a bit like
> what errno.h offers, but done via a pair of subroutines that retrieve and
> assign to some hidden global variable. I don't like this for the same
> reason i don't like subroutines that use errno (unless they're syscall
> wrappers), but in at least two of the cases the library has also come with
> a way to set a callback subroutine to automatically deal with errors
> instead. This is nice, since it means that the code doesn't get all
> obfuscated with error checking after every subroutine call, but it's
> annoying that each library needs to come with its own unique subroutine
> for this, and i do worry about it being overly general in treating all
> errors lethally.

Error handling in libraries is a thorny subject, and I could go on a
long rant on it. The short summary is simply this: error handling is
rife with incompetence, and incompetent designs. Even in languages that
ostensibly provide better mechanisms than C, the details are usually
poorly documented and under-specified [1].

Rest assured that my error handling strategy is /sane/, though for now
I'm not explaining my code, nor design.

[1] Like in Common Lisp, when you're given a handler that supposedly
can handle it in-situ, but then the handler doesn't get enough arguments
to do much more than log a generic error, or -- this was a personal
favorite -- you have to read the source code to figure out what the
error handler gets.

--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:

> Richard Kettlewell wrote:
>
>> It’s more than 20 years since I last had to integrate a C library which
>> reported errors via longjmp() and I’m still bitter about it.
>
> I have never encountered a library which does that. Which library was
> that?
>
>> As a matter of API design, I’d rather C library communicated errors via
>> return values (and pointer parameters, where more complex error
>> information is required).
>
> Personally, i think that, at least for a library, an error should _only_
> be communicated by return value. If more complex information is required,
> then the return value can be made more complex. I don't think i've ever
> used a library that communicates information via a pointer parameter.

Well you almost certainly have used such a library because some of the
functions in the C standard library use this technique. For example,
the failure to find a convertible sequence is signalled by strtod by
what is placed in the pointer pointed to by the second argument.

--
Ben.

Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:

> On 9/28/2023 6:52 AM, Blue-Maned_Hawk wrote:
>> Personally, i think that, at least for a library, an error should _only_
>> be communicated by return value. If more complex information is required,
>> then the return value can be made more complex.
....
> Error handling in libraries is a thorny subject, and I could go on a
> long rant on it. The short summary is simply this: error handling is
> rife with incompetence, and incompetent designs. Even in languages that
> ostensibly provide better mechanisms than C, the details are usually
> poorly documented and under-specified [1].

If it's done well, the result is not even "error handling" -- it's just
what the function returns. For example, a lookup in a table of integers
in Haskell returns a type that is, in effect "maybe an integer" The
return will be either "Nothing" or something like "Just 42".

Haskell does not always get it right (particularly some of the older
APIs) but the trend is to provide return type rich enough to include
either a correct result or an explanation of the fault.

--
Ben.

On 2023-09-27, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
> Richard Kettlewell wrote:
>
>> It’s more than 20 years since I last had to integrate a C library which
>> reported errors via longjmp() and I’m still bitter about it.
>
> I have never encountered a library which does that. Which library was
> that?

libpng is one example. Given a png handle you can call png_setjmp(png)
to get a jmp_buf * pointer. You setjmp on it, and libpng will longjmp to
it. There is a png_longjmp(png, <val>) function you can tall to test it.

I seem to recall that there is at least one more "famous" library which
similarly uses longjmp, but I cannot remember which.

Supporting this kind of library in the TXR Lisp FFI has been on my
TODO list. Seeing this thread gave me the sudden impetus to get it
working, and I got it done.

This works:

(let ((jb (jmp-buf)))
(setjmp jb result
(progn (put-line "setjmp")
(longjmp jb 42))
(put-line `result @result`)))

There is a jmp-buf function that allocates and returns a blank
object suitable as a jump buffer. There is a setjmp macro
which saves the context and evaluates a form. That form can longjmp,
in which case zero or more longjmp cleanup forms are evaluated
in scope of a variable which is bound to the integer longjmp
value.

I didn't have to add any special operator; setjmp expands to
a call to a run-time support function, where the expression
arguments are shored up into lambda functions.

In the test case file, in addition to the above trivial test,
I detect whether the system has libpng installed. If so,
a FFI test with libpng is conducted:

;; needed by png-set-longjmp-fn API
(defvarl libc (dlopen nil))
(defvarl longjmp-addr (dlsym libc "longjmp"))

(typedef png-structp (cptr png))

(with-dyn-lib "libpng.so"
(deffi png-get-header-ver "png_get_header_ver" str (png-structp))
(deffi png-create-read-struct "png_create_read_struct" png-structp (str cptr cptr cptr))
(deffi png-set-longjmp-fn "png_set_longjmp_fn" (carray uchar) (png-structp (cptr dlsym) size-t))
(deffi png-longjmp "png_longjmp" void (png-structp int)))

(defvar png-ver (png-get-header-ver cptr-null))

;; In the png.h header, png_setjmp is a macro only; you cannot
;; #undef it to get to a function. So we write the macro in
;; the same way as a Lisp macro, in terms of png-set-longjmp-fn,
;; whereby we pass the longjmp function, and sizeof (jmp_buf).
(defmacro png-setjmp (png-ptr)
(let ((jmpbuf-size (load-time (len (jmp-buf)))))
^(png-set-longjmp-fn ,png-ptr longjmp-addr ,jmpbuf-size)))

;;; Test

;; get png handle
(defvar png (png-create-read-struct png-ver cptr-null cptr-null cptr-null))

With that we can get the jmp-buf out of png, setjmp on it,
and then invoke it via png_longjmp, as if the library generated
an error:

;; get jmp_buf from png handle, setjmp it, longjmp to it.
(setjmp (png-setjmp png) err
(progn (put-line "libpng longjmp")
(png-longjmp png 42))
(put-line `libpng error @err`))

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

On 2023-09-28, Kaz Kylheku <864-117-4973@kylheku.com> wrote:
> On 2023-09-27, Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> wrote:
>> Richard Kettlewell wrote:
>>
>>> It’s more than 20 years since I last had to integrate a C library which
>>> reported errors via longjmp() and I’m still bitter about it.
>>
>> I have never encountered a library which does that. Which library was
>> that?
>
> libpng is one example. Given a png handle you can call png_setjmp(png)
> to get a jmp_buf * pointer. You setjmp on it, and libpng will longjmp to
> it. There is a png_longjmp(png, <val>) function you can tall to test it.

Found another one: netpbm. With netpbm, you allocate the jmp_buf, save
context with setjmp and pass the jmp_buf to pm_setjmpbuf.

It will then longjmp through it in an error situation.

Blue-Maned_Hawk:

> Personally, i think that, at least for a library, an error
> should _only_ be communicated by return value. If more
> complex information is required, then the return value can
> be made more complex. I don't think i've ever used a
> library that communicates information via a pointer
> parameter.

The failure to captrue the return value and to test it for
an error is a classic code smell, which is possible because
the return value can be ignored. If the error be signalled
via an output parameter[1], however, it is much harder to
ignore it, becuase the programmer is forced to declare a
local variable to hold the error information and pass it to
the invocation. This frees the return value for the actual
function result, and then again the programmer cannot ignore
it but must use somehow, lest the invocation be pointess.
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...

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.
____________________
1. In C, this would be a pointer, but I am using higher-
level terminology.

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

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

> Blue-Maned_Hawk:
>
>> Personally, i think that, at least for a library, an error
>> should _only_ be communicated by return value. If more
>> complex information is required, then the return value can
>> be made more complex. I don't think i've ever used a
>> library that communicates information via a pointer
>> parameter.
>
> The failure to captrue the return value and to test it for
> an error is a classic code smell, which is possible because
> the return value can be ignored. If the error be signalled
> via an output parameter[1], however, it is much harder to
> ignore it, becuase the programmer is forced to declare a
> local variable to hold the error information and pass it to
> the invocation.

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});

Of course strtod allows you to pass a null pointer here anyway, but
that's not the point. One can always pass a temporary object.

> This frees the return value for the actual
> function result, and then again the programmer cannot ignore
> it but must use somehow, lest the invocation be pointess.
> 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.

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

--
Ben.

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. I say post-modern, because the adjective has just
the right connotations of surrealism, abstract art. 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.

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

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

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

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.

Each time control flow enters the scope where "double d" is defined, a
new object is created.

A plausible translation scheme for the &(char *){0} object in
the above situation is to emit a hidden variable, like this:

char *__hidden_1234 = 0;
double d = strtod(str, &__hidden_1234);

The only literal in sight is the 0 constant.

(Rather it is C++ that has the weird design of being able to bind const
references to literals that are of a type whose values don't have
reference semantics.)

Secondly, we have had pointers to literals for over seventy years,
ever since Lisp:

(function '(1 2 3)) ;; literal list passed to function

Quoted lists are bona fide literals in Lisp. Common Lisp makes
it undefined behavior to try to modify them; they can be burned
into ROM or mapped into read-only VM pages and such.
Quoted lists with identical suffixes can be merged together (sound
familiar?), and since they are constants, they can be subject to
constant folding so that they partially or entirely disappear. E.g.(cdr
'(1 2 3)) can compile into '(2 3).

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

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.

Perhaps Ben should have written it as

double d= strtod(str, NULL);

RETURN VALUE
These functions return the converted value, if any.

If endptr is not NULL, a pointer to the character after the last char-
acter used in the conversion is stored in the location referenced by
endptr.

This will just push a zero to the stack (or argument register) before calling
strtod. No need to allocate storage anywhere.

On 2023-09-28, Scott Lurndal <scott@slp53.sl.home> wrote:
> 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.
>
> Perhaps Ben should have written it as
>
> double d= strtod(str, NULL);

Check Ben's original post. That was mentioned from the start, but set
aside for the sake of illustrating how you can ignore an "output
parameter" which doesn't have such a NULL opt-out mechanism, and
to do it in a self-contained way, without the clutter of separately
declaring temporary objects.

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

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.

scott@slp53.sl.home (Scott Lurndal) 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.
>
> Perhaps Ben should have written it as
>
> double d= strtod(str, NULL);

No, for reasons I gave! The point was that one can always do at least
this so there is never a need for a declared variable when the
information is going to be ignored.

--
Ben.

On 28/09/2023 17:31, 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.

That is not what is happening at all. There is a compound literal used
to initialise a temporary object of type char* with the value 0, and a
pointer to this temporary object is passed to the function.

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

Compound literals arrived with C99 (or gcc extensions a few years before
that) - long before modern C, which is C17/C18. "Post-modern C" would
be C23.

> I
> hadn't even thought of doing that.

If you don't want to do that, don't do it.

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

Well, it is certainly fine to do this in C++ (which supports optional
types in the standard library, as well as structured binding, std::tie
and tuples to make it easy to use multiple return values. I don't
believe anyone has claimed C++ is a language that is easy for compiler
design - but I doubt if this is a major reason.

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.

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.

[This article is a resend because my first try seems to not have worked;
if this is duplicated, that's the explanation.]

Ben Bacarisse wrote:

> Haskell does not always get it right (particularly some of the older
> APIs) but the trend is to provide return type rich enough to include
> either a correct result or an explanation of the fault.

Things like that are pretty much what i was referring to earlier when i
referred to making the return type more complex to handle more complex
situations. Obviously, it would have to be done differently in C, since C
doesn't support tagged unions (at least not natively—i know of a couple
libraries that use macro magic to implement them).

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr. bluemanedhawk.github.io
A flamethrower will not interfere with WiFi unless you aim it directly at
the router.

Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> writes:
>[This article is a resend because my first try seems to not have worked;
>if this is duplicated, that's the explanation.]
>
>Ben Bacarisse wrote:
>
>> Haskell does not always get it right (particularly some of the older
>> APIs) but the trend is to provide return type rich enough to include
>> either a correct result or an explanation of the fault.
>
>Things like that are pretty much what i was referring to earlier when i
>referred to making the return type more complex to handle more complex
>situations. Obviously, it would have to be done differently in C, since C
>doesn't support tagged unions (at least not natively—i know of a couple
>libraries that use macro magic to implement them).

In C++, a std::pair<bool, return-type> is used in that context. If the sizeof
the return type is 64-bits or less, most modern ABI's will return it in a pair
of registers.

Scott Lurndal:

> In C++, a std::pair<bool, return-type> is used in that
> context. If the sizeof the return type is 64-bits or
> less, most modern ABI's will return it in a pair of
> registers.

This groups the error flag and return value, the error
message having to be passed somewhere else. In C, one can
group the error flag, error code, error message plus any
additional error information, in order to return the actual
return value.

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

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.

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.

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.

Anton Shepelev <anton.txt@gmail.moc> writes:
>Scott Lurndal:
>
>> In C++, a std::pair<bool, return-type> is used in that
>> context. If the sizeof the return type is 64-bits or
>> less, most modern ABI's will return it in a pair of
>> registers.
>
>This groups the error flag and return value, the error
>message having to be passed somewhere else. In C, one can
>group the error flag, error code, error message plus any
>additional error information, in order to return the actual
>return value.

In C++ you can group any number of objects into a struct
and return that, if you need to. I wouldn't return a
message from the function, an error code that maps into
a message is often sufficient.

One could take a leaf from the VMS book and replace the bool
with an error code (which maps externally into a locale-specific
string), where "SS$_NORMAL" indicates that the operation was
successful, and the range less than MAX(defined errno) is
reserved for strerror() messages and the range above some
value is reserved to the application.

On 2023-09-28, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> 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

Let's examine our use of the article "a".

#include <stdio.h>

void fun(int c)
{ char x;

if (c > 0) {
printf("%p\n", (void *) &(char *){&x});
fun(c - 1);
}
}

int main(void)
{ fun(5);
return 0;
}

$ ./literal
0xbfd9f4b8
0xbfd9f488
0xbfd9f458
0xbfd9f428
0xbfd9f3f8

This illustrates why I have an issue with using the term "literal" for
this situation.

The object:

1. (by default) is freshly allocated on the fly in automatic storage;

2. consequently, may exhibit multiple addresses concurrently;

3. is destroyed when the scope terminates;

4. is independently mutable in all its multiple instances; and

5. doesn't have literals in its expression, being initialized using &x.

What is literal about it?

C99 said that a compound literal "is an expression that provides access
to an anonymous object".

Why can't we call that expression "anonymous object designator"
or something? If we have "char *p = 0", p is a primary expression which
designates an object, and not a literal.

If we then have (char *){p} we get an anonymous object that is
initialized with a copy of p, and that expression designates it in much
the same way as p designates its object.

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