On Tuesday, 11 April 2023 at 01:04:22 UTC+3, Ben Bacarisse wrote:
> Ike Naar <i...@sdf.org> writes:
>
> > On 2023-04-10, Keith Thompson <Keith.S.T...@gmail.com> wrote:
> >> jak <nos...@please.ty> writes:
> >>> I apologize. The type of data was, perhaps, more complex, also it was
> >>> not a declaration but a cast for which I asked for advice on this
> >>> newsgroup a few years ago and more than one person replied that the only
> >>> way was through a typedef.
> >>
> >> I do not believe that there have been any changes to the standard that
> >> cause some construct to require a typedef where a typedef was not
> >> previously required. I suspect that anyone who said that "the only
> >> way was through a typedef" was mistaken. (It's likely that a typedef
> >> would make the code easier to read.)
> >>
> >> It's entirely possible that I'm mistaken, and if so I would very much
> >> like to know about it.
> >
> > An example: a function that returns a pointer to a function of the same type.
> > It's mentioned in comp.lang.c FAQ 1.22,
> > <https://c-faq.com/decl/recurfuncp.html>.
>
> I don't think that's an example of something that can only be done with
> a typedef. For one thing, it can't be done at all (/even/ using a
> typedef), but when one /is/ used, surely it's just to make the
> almost-doing it code easier to read?
>
Yes. For other thing jak says it was not the point but example
about issues because of evolution of languages and changes in standards.
That can't be such example as a function returning pointer to function of same
type can not be declared by any standard of C (nor C++). Also as
dereferencing function pointers is now implicit (but explicit
dereferencing is also not illegal) the standards have actually relaxed
it a bit.

I suspect that jak is not vague because of translation to English but
because he remembers disliking some breaking change
between standards years ago but has now forgot what it was.

On 10/04/2023 18:35, jak wrote:
> James Kuyper ha scritto:
>> On 4/10/23 11:43, jak wrote:
>>> James Kuyper ha scritto:
>>>> On 4/10/23 10:37, jak wrote:
>>>> ...
>>>>>> Instead, explain to me why, after all the improvements introduced
>>>>>> by the
>>>>> standards, it is no longer possible to declare a specialized function
>>>>> pointer array without first declaring the typedef that defines the
>>>>> function pointer and why.
>>>>
>>>> "specialized function pointer array"? Are you posting that to the
>>>> correct newsgroup?
>>>> Even if this were comp.lang.c++, you've just swerved off into an
>>>> entirely different conversational direction - I would recommend
>>>> starting
>>>> a new thread to discuss that issue.
>>>>
>>>
>>> Please tell me you're joking...
>>
>> No, I'm dead serious. This is the wrong newsgroup to discuss specialized
>> functions, because C doesn't have them. There would be both more
>> interest, and more expertise, for a discussion of that issue in
>> comp.lang.c++ than here.
>> I'm also dead serious about the change in Subject. When you introduce a
>> radical change of topic, it is indeed good netiquette to make a
>> corresponding change to the "Subject:" header.
>>
>
> What I can't explain to you is that you are fixated on terminology while
> I'm trying to explain myself largely using the google translator. By
> specialized function (this is the google translation) I mean a function
> that has return values and parameters different from the inte type so
> not like:
>
> int foo(int)
>
> You could, however, propose to the newsgroup manager that non-native
> English speakers should not use it... or become less meticulous.

In order to have any hope of communicating properly, it is important to
use correct terminology. If we all use vague words based on what they
sometimes mean in English, we'll never get anywhere - all our time will
be spent asking each other what we mean.

This is a C language group. The source of all terms is the C standards.
These are easily found online, for all the different versions of C
(technically only the draft versions are freely available, but these are
fine for almost all use-cases). The standards documents are not easy
reading even for native English speakers, but you must at least
appreciate that the terms we all use here come from those documents.

We realise that you are not a native English speaker - that applies to
many of the regular posters here, who come from all around the world. I
believe some find that Google translate can help a bit, but it cannot
handle technical programming terms and expressions. It may be unfair,
but if you want to be a serious programmer, learning more English is
unavoidable. (That does /not/ mean we expect perfect English!)

Along with that, giving code examples showing what you mean can be very
helpful.

I believe that what you are talking about is the distinction between
"function prototype declarations" and "non-prototype function
declarations" (also sometimes known as "K&R function declarations"). In
ancient C, described in excellent but the long outdated first edition of
the book "The C Programming Language", functions were assumed to take a
single "int" parameter and return an "int", unless declared otherwise.
This type of function declaration was replaced in C90 by "prototypes"
specifying the return type and parameter type. Although function
prototype declarations are better in virtually every way, the old style
remained supported for backwards compatibility. Only now, in C23, has
support for them been removed entirely.

The only real use I have seen for non-prototype function declarations is
a "general" function pointer in arrays containing mixed function pointer
types. Such use is no longer allowed in C23. Is that what you are
concerned about? Normally a better choice of general function pointer
is "void foo(void)", rather than "int foo()". (In C23, the later would
now mean "int foo(void)".)

On Monday, 10 April 2023 at 21:14:24 UTC+3, jak wrote:
> Öö Tiib ha scritto:
> > On Monday, 10 April 2023 at 19:36:00 UTC+3, jak wrote:
> >> James Kuyper ha scritto:
> >>> On 4/10/23 11:43, jak wrote:
> >>>> James Kuyper ha scritto:
> >>>>> On 4/10/23 10:37, jak wrote:
> >>>>> ...
> >>>>>>> Instead, explain to me why, after all the improvements introduced
> >>>>>>> by the
> >>>>>> standards, it is no longer possible to declare a specialized function
> >>>>>> pointer array without first declaring the typedef that defines the
> >>>>>> function pointer and why.
> >>>>>
> >>>>> "specialized function pointer array"? Are you posting that to the
> >>>>> correct newsgroup?
> >>>>> Even if this were comp.lang.c++, you've just swerved off into an
> >>>>> entirely different conversational direction - I would recommend starting
> >>>>> a new thread to discuss that issue.
> >>>>>
> >>>>
> >>>> Please tell me you're joking...
> >>>
> >>> No, I'm dead serious. This is the wrong newsgroup to discuss specialized
> >>> functions, because C doesn't have them. There would be both more
> >>> interest, and more expertise, for a discussion of that issue in
> >>> comp.lang.c++ than here.
> >>> I'm also dead serious about the change in Subject. When you introduce a
> >>> radical change of topic, it is indeed good netiquette to make a
> >>> corresponding change to the "Subject:" header.
> >>>
> >>
> >> What I can't explain to you is that you are fixated on terminology while
> >> I'm trying to explain myself largely using the google translator. By
> >> specialized function (this is the google translation) I mean a function
> >> that has return values and parameters different from the inte type so
> >> not like:
> >>
> >> int foo(int)
> >>
> > That indeed is change of subject, what you post is not array, and it is
> > still unclear what you want. We can define variable of type of array of
> > function pointers without any typedefs like that:
> >
> > double (*array_of_function_pointers[52]) (float f, char c);
> >
> > That AFAIK works both in C and in C++.
> >
> >> You could, however, propose to the newsgroup manager that non-native
> >> English speakers should not use it... or become less meticulous.
> >
> > What newsreader it is that does not let you to start a new thread
> > or to change the subject line when you want to change subject?
> > Never seen such thing.
> >
>
> I apologize. The type of data was, perhaps, more complex, also it was
> not a declaration but a cast for which I asked for advice on this
> newsgroup a few years ago and more than one person replied that the only
> way was through a typedef. But that wasn't the point. The point was to
> be able to say that thanks to the continuous changes to follow the
> standards some things that worked have stopped.

Yes there are some breaking changes between standards of C.
The amount of such changes is far lower than between versions of
most other popular programming languages. The tradition
of backwards compatibility is ver high in C. Each breaking change
felt to have more than one good reason to break the code that it
broke (to me). Similar sentiments are probably the reason why people
are asking you to be more precise about the example that you talk
about. If you have forgotten it then it wasn't perhaps that important?

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

> cross@spitfire.i.gajendra.net (Dan Cross) writes:

[..concerning whether realloc() with a size of 0 must free()..]

>> The authors presented it as a universal property of
>> all implementations, but it just is not.
>
> I don't think they do.

Right.

> They state that "The C89 and C99 standards committees strongly
> recommended that allocation interfaces malloc, calloc, and realloc
> return a null pointer in response to zero-byte requests" and that
> this "implies that realloc(p,0) should unconditionally free(p)".
> I don't know where that recommendation comes from (the PDF is
> missing footnotes > 27)

I believe the authors mean to refer to statements in the two C
Rationale documents (and indeed it is the case that these
documents discuss matters concerning how memory management
behave).

> and the implication seems to be a bit of a stretch, but if they
> just assumed this to be universal, why explain that it was
> recommended?

To me it seems clear that the authors mean to distinguish between
what behaviors are /recommended/ (or at least that they think are
recommended) and what behaviors are /described or specified/ by
the various C standards over the years (which definitely have
changed in different official releases of the C standard). And
it seems obvious that the authors recognize that these two things
are not the same.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

> In article <u10erc$23rhg$1@dont-email.me>, jak <nospam@please.ty> wrote:
>
>> Dan Cross ha scritto:
>>
>>> In article <u0uk66$1or41$1@dont-email.me>, jak <nospam@please.ty> wrote:
>>>
>>>> Tim Rentsch ha scritto:
>>>>
>>>>> [snip]
>>>>> I agree with the general tone of this suggestion. Unfortunately
>>>>> however the particular code suggested might not compile (because
>>>>> the macro NULL might be #define'd to be 0, which can result in an
>>>>> error). Writing the function this way:
>>>>>
>>>>> void *
>>>>> realloc0( void *p, size_t size ){
>>>>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>>>>> }
>>>>>
>>>>> is an easy way to avoid that implementation dependency.
>>>>
>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>> on autocast and use an explicit one instead.
>>>
>>> What "dependency" would that avoid, other than a dependency on
>>> the C standard?
>>
>> Why are you asking me this?
>
> Because you are the one who suggested there is some kind of
> "dependency" in Tim's code?

I didn't take his comment that way. My impression is that he
meant there _might_ be a dependency, or perhaps there is some
uncertainty about whether there is a dependency, or possibly that
there may be a dependency at some time in the future. Of course
I am not sure what he meant, but that is how I took it.

cross@spitfire.i.gajendra.net (Dan Cross) writes:

[...]

> Why don't we let him speak for himself?

+1

It would be nice if people would follow this precept
more often.

jak <nospam@please.ty> writes:

[...]

> It's not my intention to be arrogant but here it's like sticking a
> stick in a wasp's nest. I've never been able to exchange more than
> one comment with the same person who immediately makes a new person
> aware and, honestly, I find the way many people respond particularly
> aggressive and often it seems like I'm talking to lawyers rather
> than programmers. I Already stopped posting here many years ago for
> the same reason even though I've always followed. I tried again but
> nothing has changed and I'll go back to just reading. However, I
> would like you to notice that there are few new arrivals and perhaps
> the cause is this climate.

For what it's worth I think the people who write these responses
are actually trying to be helpful. I think sometimes they don't
understand that what they think will be helpful doesn't really
help the person being responded to (such as yourself).

Incidentally, I am curious. Do you mind saying what your native
language is?

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> "Several operators convert operand values from one type to another
> automatically. This subclause specifies the result required from
> such an implicit conversion, as well as those that result from a
> cast operation (an explicit conversion)." (6.3p1)
>
> The terms "implicit conversion" and "explicit conversion" are both
> italicized in the actual standard, which is an ISO convention
> indicating that the sentence in which they occur is the official
> definition of what those terms mean.
>
> Implicit conversions occur in the following contexts:
>
> The integer promotions (6.3.1.1p2).
> The usual arithmetic conversions (6.3.1.8p1).
>
> An lvalue of array type is implicitly converted into a pointer to
> the first element of that array in many contexts (6.3.2p3). This is
> done as a convenience, but has led many people to confuse arrays
> with pointers.
>
> A function designator is implicitly converted into a pointer to the
> designated function in many contexts (6.3.2p4).
>
> The default argument promotions (6.5.2.2p6).
>
> Simple assignment (6.5.16.1p2).
>
> As-if by assignment:
> Arguments of function declared with a prototype. (6.5.2.2p7, 6.9.1p10)
> Return expression. (6.8.6.4p3)

Good list.

There is one other case of same rule as assignment, which is
scalar initializer values, either in declarations or in
compound literals.

Öö Tiib ha scritto:
> On Monday, 10 April 2023 at 21:14:24 UTC+3, jak wrote:
>> Öö Tiib ha scritto:
>>> On Monday, 10 April 2023 at 19:36:00 UTC+3, jak wrote:
>>>> James Kuyper ha scritto:
>>>>> On 4/10/23 11:43, jak wrote:
>>>>>> James Kuyper ha scritto:
>>>>>>> On 4/10/23 10:37, jak wrote:
>>>>>>> ...
>>>>>>>>> Instead, explain to me why, after all the improvements introduced
>>>>>>>>> by the
>>>>>>>> standards, it is no longer possible to declare a specialized function
>>>>>>>> pointer array without first declaring the typedef that defines the
>>>>>>>> function pointer and why.
>>>>>>>
>>>>>>> "specialized function pointer array"? Are you posting that to the
>>>>>>> correct newsgroup?
>>>>>>> Even if this were comp.lang.c++, you've just swerved off into an
>>>>>>> entirely different conversational direction - I would recommend starting
>>>>>>> a new thread to discuss that issue.
>>>>>>>
>>>>>>
>>>>>> Please tell me you're joking...
>>>>>
>>>>> No, I'm dead serious. This is the wrong newsgroup to discuss specialized
>>>>> functions, because C doesn't have them. There would be both more
>>>>> interest, and more expertise, for a discussion of that issue in
>>>>> comp.lang.c++ than here.
>>>>> I'm also dead serious about the change in Subject. When you introduce a
>>>>> radical change of topic, it is indeed good netiquette to make a
>>>>> corresponding change to the "Subject:" header.
>>>>>
>>>>
>>>> What I can't explain to you is that you are fixated on terminology while
>>>> I'm trying to explain myself largely using the google translator. By
>>>> specialized function (this is the google translation) I mean a function
>>>> that has return values and parameters different from the inte type so
>>>> not like:
>>>>
>>>> int foo(int)
>>>>
>>> That indeed is change of subject, what you post is not array, and it is
>>> still unclear what you want. We can define variable of type of array of
>>> function pointers without any typedefs like that:
>>>
>>> double (*array_of_function_pointers[52]) (float f, char c);
>>>
>>> That AFAIK works both in C and in C++.
>>>
>>>> You could, however, propose to the newsgroup manager that non-native
>>>> English speakers should not use it... or become less meticulous.
>>>
>>> What newsreader it is that does not let you to start a new thread
>>> or to change the subject line when you want to change subject?
>>> Never seen such thing.
>>>
>>
>> I apologize. The type of data was, perhaps, more complex, also it was
>> not a declaration but a cast for which I asked for advice on this
>> newsgroup a few years ago and more than one person replied that the only
>> way was through a typedef. But that wasn't the point. The point was to
>> be able to say that thanks to the continuous changes to follow the
>> standards some things that worked have stopped.
>
> Yes there are some breaking changes between standards of C.
> The amount of such changes is far lower than between versions of
> most other popular programming languages. The tradition
> of backwards compatibility is ver high in C. Each breaking change
> felt to have more than one good reason to break the code that it
> broke (to me). Similar sentiments are probably the reason why people
> are asking you to be more precise about the example that you talk
> about. If you have forgotten it then it wasn't perhaps that important?
>
>
>

Don't be too hard on me and above all give me the time necessary to find
that thread. Thinking about it, I remembered a few things that will help
me find it. For example, at that time Bart asked me if he could use a
piece of my code in one of his essays or books, and no, now it's no
longer necessary to have an answer because following their advice and
using the typedef I solved my problem. Anyway I'm looking for the thread
but it's been almost 20 years, maybe more. For now I only remember that
it concerned arrays with function pointers and it did not concern their
declaration but a cast to their type... but looking for a thread from 20
years ago... this is really a waste of time.

On 4/10/23 13:22, Scott Lurndal wrote:
....
> Well, I've worked with systems where a null pointer was represented by
> the 32-bit value 0xc0eeeeee. So you can't make assumptions, just use
> NULL (or nullptr in C++).

An integer constant expression with a value of 0 always qualifies as a
null pointer constant. Null pointer constants always implicitly convert
to null pointers of the appropriate type when used in pointer contexts.
This has always been the case, regardless of how null pointers are
represented internally.

David Brown <david.brown@hesbynett.no> writes:
[...]
> The only real use I have seen for non-prototype function declarations
> is a "general" function pointer in arrays containing mixed function
> pointer types. Such use is no longer allowed in C23. Is that what
> you are concerned about? Normally a better choice of general function
> pointer is "void foo(void)", rather than "int foo()". (In C23, the
> later would now mean "int foo(void)".)

I haven't often had a need for a generic function pointer type (as void*
is a generic object pointer type), but I suggest that using a return
type that's not used elsewhere might be safer. If you use `void(void)`
as a generic function type, there's a risk that a call without a cast
will quietly compile.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 4/10/23 13:34, Dan Cross wrote:
> In article <u11c1o$27m86$2@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> This analysis is ultimately a response to the question "What
>> "dependency" would that avoid, other than a dependency on the C
>> standard?". As far as I can tell, you are the one who posted that
>> question, in the message with the header
>>
>> Date: Sun, 9 Apr 2023 19:34:09 -0000 (UTC)
>>
>> The simplest explanation of your confusion I can come up with is that
>> you misunderstood jak as suggesting that that dependency was in Tim's
>> code, rather than Kaz's.
>
> First, please stop emailing me about this. Keep it in USENET.

I've already said this to you by e-mail, and I've explained it before to
the group, but I'll repeat it for the benefit of anyone who doesn't
remember my previous apologies:

I spent more than a decade using a newsreader that had a "Reply" button
that would send a message to the newsgroup, and provided only a
significantly less convenient method for sending a response to the
author (I no longer remember what that method was). A few years ago,
they changed their interface to provide a "Follow Up" button which does
what the old "Reply" button did, and a "Reply" button that now sends a
response only to the author. I've been trying ever since then to break
my habit of hitting the "Reply" button, but with very poor success, as
you have seen. This old dog does not learn new tricks as easily as I
used to. I promise to try to remember to hit the "Follow Up" button
instead, but since that's what I'm already trying to do, I would not
recommend expecting any different results.

> Second, you are making an assumption about user jak's intent.
> Respectfully, I think your assumption is wrong, which leads to
> your (ahem) "confusion." Perhaps try to clarify with jak what
> they mean before continuing the conversation; I tried and was
> rebuffed, but perhaps you will have better luck.

He's had plenty of opportunities to tell us who is interpreting his
words correctly. He's not bothered to do so. Until he does, we'll just
have to agree to disagree.

On 4/10/23 13:11, jak wrote:
...
> Also I would like to add that the concept of 'standard' that you follow
> with religious attention, IMO, is wrong because up to now it has not
> evolved but it has changed and this is insane. 'Standard' is a luxury
> for programming theorists. Thousands of companies use decades-old
> compilers so they don't have to change millions of lines of currently
> working code. The 'standard' should be followed by compiler makers and
> not compiler users.

The standard is a contract between implementations and users. It was
negotiated by the ISO committee, which includes implementors and users.
You have no obligation to use that contract, and neither does an
implementor. However, an implementation claiming to conform to a
standard can be relied upon to handle code in a manner consistent with
what the standard says, and can be held accountable if it fails to do
so. Without the standard, you have nothing to rely on but the
implementation's documentation. That may be sufficient for code that
only needs to work properly on one particular implementation, but if you
have any larger ambitions for your software, the standard is what you
must rely upon to achieve them.

> ... In the discussion of this thread we discuss a
> ternary operator which returns 0 in one rung and a pointer in the other.
> The standard says that 0 can be raised to a null pointer and it is true
> but tomorrow someone will change the 'standard' and this will no longer
> be true.

A key point to consider is that the relevant guarantee is NOT for a
value of 0, but for null pointer constants (NPCs). NULL expands to an
NPC. The integer constant 0 also qualifies as one. The expression
"free(p), 0" does not qualify as a null pointer constant, even though
it's an expression of integer type and a value of 0.

It is extremely unlikely that the committee will ever change those
rules. You might, with equal plausibility, worry about he possibility
that the short-circuit behavior of && and || operators might disappear.
If you're worrying about changes on that level, C becomes essentially
unusable - you should change to a different language that gives you less
worries.

On 4/10/23 17:47, Ike Naar wrote:
> On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
....
>> I do not believe that there have been any changes to the standard that
>> cause some construct to require a typedef where a typedef was not
>> previously required. I suspect that anyone who said that "the only
>> way was through a typedef" was mistaken. (It's likely that a typedef
>> would make the code easier to read.)
>>
>> It's entirely possible that I'm mistaken, and if so I would very much
>> like to know about it.
>
> An example: a function that returns a pointer to a function of the
> same type.
> It's mentioned in comp.lang.c FAQ 1.22,
> <https://c-faq.com/decl/recurfuncp.html>.

That's not an example of a construct requiring the use of a typedef. A
typedef is convenient, but not required. As it says on that page:

"without [the typedef], the state variable would have to be declared as
funcptr (*state)() and the call would contain a bewildering cast of the
form (funcptr (*)())(*state)()."

On 4/11/23 09:14, jak wrote:
....
> that thread. Thinking about it, I remembered a few things that will help
> me find it. For example, at that time Bart asked me if he could use a
> piece of my code in one of his essays or books, and no, now it's no
> longer necessary to have an answer because following their advice and
> using the typedef I solved my problem. Anyway I'm looking for the thread
> but it's been almost 20 years, maybe more. For now I only remember that
> it concerned arrays with function pointers and it did not concern their
> declaration but a cast to their type... but looking for a thread from 20
> years ago... this is really a waste of time.

The fundamental problem is that, in C, a typedef is nothing more than an
synonym for a type. In any context where you use a typedef, you could
also use the explicit type itself. Therefore, it's not possible that you
were forced to use a typedef. A typedef often makes code easier to read
and write, but is never necessary. The kind of code you're talking about
is one of the contexts where that is true.

On 4/11/23 05:27, David Brown wrote:
....> declarations" (also sometimes known as "K&R function
declarations"). In
> ancient C, described in excellent but the long outdated first edition of
> the book "The C Programming Language", functions were assumed to take a
> single "int" parameter and return an "int", unless declared otherwise.

"If the expression that precedes the parenthesized argument list in
a function call consists solely of an identifier, and if no
declaration is visible for this identifier, the identifier is
implicitly declared exactly as if, in the innermost block containing
the function call, the declaration

extern int identifier();

appeared."

(C90 6.3.2.2)

Note that the function is implicitly declared using the K&R syntax, not
as a function prototype. That syntax declares it as taking an
unspecified number of arguments of unspecified types, not as taking a
single "int" argument.

On 4/11/23 11:35, James Kuyper wrote:
....
> The fundamental problem is that, in C, a typedef is nothing more than an
> synonym for a type. In any context where you use a typedef, you could
> also use the explicit type itself. Therefore, it's not possible that you
> were forced to use a typedef. A typedef often makes code easier to read
> and write, but is never necessary. The kind of code you're talking about
> is one of the contexts where that is true.

Note that this is NOT true in C++: the type that a typedef describes can
have a different language linkage than the function that it is used to
declare. This allows a function's name to have different language
linkage than the function's type:

extern "C" typedef void FUNC();
FUNC f2; // the name f2 has C ++ language linkage and the
// function’s type has C language linkage
(C++ standard, 9.11p5)

This is the only case I'm aware of, in either language, where a typedef
is necessary, and not merely convenient.

James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> I spent more than a decade using a newsreader that had a "Reply" button
> that would send a message to the newsgroup, and provided only a
> significantly less convenient method for sending a response to the
> author (I no longer remember what that method was). A few years ago,
> they changed their interface to provide a "Follow Up" button which does
> what the old "Reply" button did, and a "Reply" button that now sends a
> response only to the author. I've been trying ever since then to break
> my habit of hitting the "Reply" button, but with very poor success, as
> you have seen. This old dog does not learn new tricks as easily as I
> used to. I promise to try to remember to hit the "Follow Up" button
> instead, but since that's what I'm already trying to do, I would not
> recommend expecting any different results.

My deepest apologies for this off-topic post, but I must say
that I feel your pain.

I had this TV "digibox" about 10 years ago. Its GUI design was pretty
crazy right from the beginning. The menu that applied to recorded
TV programs had "delete" (single item) and "delete all" right next
to each other. So it would be pretty easy to delete all your recordings
by accident. Somehow I avoided doing so.

After many years, one day I updated the digibox to the latest
software version. After the update, the "delete" and "delete all"
were still next to each other, but their location was different.

After watching an episode of Star Trek TNG, my intention was to
delete it in order to save disk space. Using mental autopilot
I pointed the cursor to the same location where "delete"
had been for many years. I was then asked to confirm the
deletion. While still on total autopilot, I quickly replied
"yes".

BANG! The next thing I knew was that all my recordings were
gone and there were at least one hundred of them! The GUI
designers had placed "delete all" to the very same location
that used to have "delete" (single item).

It is hard to believe this kind of GUI design can be real.
I do not remember the digibox manufacturer any more. It
could have been Topfield, but I am not sure.

br,
KK

On 11/04/2023 17:17, Kalevi Kolttonen wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> I spent more than a decade using a newsreader that had a "Reply" button
>> that would send a message to the newsgroup, and provided only a
>> significantly less convenient method for sending a response to the
>> author (I no longer remember what that method was). A few years ago,
>> they changed their interface to provide a "Follow Up" button which does
>> what the old "Reply" button did, and a "Reply" button that now sends a
>> response only to the author. I've been trying ever since then to break
>> my habit of hitting the "Reply" button, but with very poor success, as
>> you have seen. This old dog does not learn new tricks as easily as I
>> used to. I promise to try to remember to hit the "Follow Up" button
>> instead, but since that's what I'm already trying to do, I would not
>> recommend expecting any different results.
>
> My deepest apologies for this off-topic post, but I must say
> that I feel your pain.
>
> I had this TV "digibox" about 10 years ago. Its GUI design was pretty
> crazy right from the beginning. The menu that applied to recorded
> TV programs had "delete" (single item) and "delete all" right next
> to each other. So it would be pretty easy to delete all your recordings
> by accident. Somehow I avoided doing so.
>
> After many years, one day I updated the digibox to the latest
> software version. After the update, the "delete" and "delete all"
> were still next to each other, but their location was different.
>
> After watching an episode of Star Trek TNG, my intention was to
> delete it in order to save disk space. Using mental autopilot
> I pointed the cursor to the same location where "delete"
> had been for many years. I was then asked to confirm the
> deletion. While still on total autopilot, I quickly replied
> "yes".
>
> BANG! The next thing I knew was that all my recordings were
> gone and there were at least one hundred of them! The GUI
> designers had placed "delete all" to the very same location
> that used to have "delete" (single item).
>
> It is hard to believe this kind of GUI design can be real.

Is there no confirmation needed for 'Delete All'? That would be
incredibly bad design and should been reported on the original too.

I have a PVR that is older than ten years, and that will confirm first,
I think even for single items.

Although even that could go wrong: it should report how many items will
be affected, in case you'd clicked the wrong button.

Bart <bc@freeuk.com> wrote:
> On 11/04/2023 17:17, Kalevi Kolttonen wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>> I spent more than a decade using a newsreader that had a "Reply" button
>>> that would send a message to the newsgroup, and provided only a
>>> significantly less convenient method for sending a response to the
>>> author (I no longer remember what that method was). A few years ago,
>>> they changed their interface to provide a "Follow Up" button which does
>>> what the old "Reply" button did, and a "Reply" button that now sends a
>>> response only to the author. I've been trying ever since then to break
>>> my habit of hitting the "Reply" button, but with very poor success, as
>>> you have seen. This old dog does not learn new tricks as easily as I
>>> used to. I promise to try to remember to hit the "Follow Up" button
>>> instead, but since that's what I'm already trying to do, I would not
>>> recommend expecting any different results.
>>
>> My deepest apologies for this off-topic post, but I must say
>> that I feel your pain.
>>
>> I had this TV "digibox" about 10 years ago. Its GUI design was pretty
>> crazy right from the beginning. The menu that applied to recorded
>> TV programs had "delete" (single item) and "delete all" right next
>> to each other. So it would be pretty easy to delete all your recordings
>> by accident. Somehow I avoided doing so.
>>
>> After many years, one day I updated the digibox to the latest
>> software version. After the update, the "delete" and "delete all"
>> were still next to each other, but their location was different.
>>
>> After watching an episode of Star Trek TNG, my intention was to
>> delete it in order to save disk space. Using mental autopilot
>> I pointed the cursor to the same location where "delete"
>> had been for many years. I was then asked to confirm the
>> deletion. While still on total autopilot, I quickly replied
>> "yes".
>>
>> BANG! The next thing I knew was that all my recordings were
>> gone and there were at least one hundred of them! The GUI
>> designers had placed "delete all" to the very same location
>> that used to have "delete" (single item).
>>
>> It is hard to believe this kind of GUI design can be real.
>
> Is there no confirmation needed for 'Delete All'? That would be
> incredibly bad design and should been reported on the original too.

If you read carefully what I wrote, I did say:

"I was then asked to confirm the deletion. While still on
total autopilot, I quickly replied "yes".

So, yes, the confirmation was indeed needed. But after
many years of using this digibox, I was like a Pavlov's Dog,
fully conditioned to know the location of "Delete"
(single item). When that basic assumption failed, all hell
broke loose and I just clicked "Yes" simply not realizing
that the button was now "Delete All".

I cannot remember if it said "Want to delete all items"
or "Want to delete this item".

All in all, my user mistake was also involved, but I still
very much blame those who:

1) First put "Delete" and "Delete All" right next to each other
2) Then put "Delete All" to where "Delete" was previously

I really have no education concerning how to design GUIs, but
I am pretty sure this is *not* the way to do it.

br,
KK

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 4/11/23 09:14, jak wrote:
> ...
>
>> that thread. Thinking about it, I remembered a few things that
>> will help me find it. For example, at that time Bart asked me if
>> he could use a piece of my code in one of his essays or books, and
>> no, now it's no longer necessary to have an answer because
>> following their advice and using the typedef I solved my problem.
>> Anyway I'm looking for the thread but it's been almost 20 years,
>> maybe more. For now I only remember that it concerned arrays with
>> function pointers and it did not concern their declaration but a
>> cast to their type... but looking for a thread from 20 years
>> ago... this is really a waste of time.
>
> The fundamental problem is that, in C, a typedef is nothing more
> than an synonym for a type. In any context where you use a typedef,
> you could also use the explicit type itself. [...]

Strictly speaking this assertion isn't quite right. Here is an
example:

typedef long Elongator( int );

extern const Elongator *elongator;

There is no way to declare the pointer object 'elongator' without
the use of a typedef.

It may be worth noting that using a type qualifier directly on a
function type is explicitly undefined behavior (but not a constraint
violation). However, an implementation might want to take advantage
of that in defining a language extension.

On Tuesday, April 11, 2023 at 10:46:24 PM UTC-4, Tim Rentsch wrote:
> James Kuyper <james...@alumni.caltech.edu> writes:
....
> > The fundamental problem is that, in C, a typedef is nothing more
> > than an synonym for a type. In any context where you use a typedef,
> > you could also use the explicit type itself. [...]
>
> Strictly speaking this assertion isn't quite right. Here is an
> example:
>
> typedef long Elongator( int );
>
> extern const Elongator *elongator;

I'm confused by that declaration - what is the 'const' supposed to mean in that context? Normally, I would read that declaration as saying that elongator is an identifier with external linkage, and that (*elongator)(5) returns a "const long", which makes no sense to me.

> There is no way to declare the pointer object 'elongator' without
> the use of a typedef.
> It may be worth noting that using a type qualifier directly on a
> function type is explicitly undefined behavior (but not a constraint
> violation).

gcc shares my confusion about that declaration, referring to precisely that rule:
elongator.h:2:25: warning: ISO C forbids qualified function types [-Wpedantic]
2 | extern const Elongator *elongator;
| ^~~~~~~~~
That error message disappears if I move the 'const', so that it qualifies elongator, which makes a lot more sense to me:
extern Elongator * const elongator;

and it accepts, as compatible, the following declaration of the same identifier:

extern long(*const elongator)(int);

On 12/04/2023 07:44, james...@alumni.caltech.edu wrote:
> On Tuesday, April 11, 2023 at 10:46:24 PM UTC-4, Tim Rentsch wrote:
>> James Kuyper <james...@alumni.caltech.edu> writes:
> ...
>>> The fundamental problem is that, in C, a typedef is nothing more
>>> than an synonym for a type. In any context where you use a typedef,
>>> you could also use the explicit type itself. [...]
>>
>> Strictly speaking this assertion isn't quite right. Here is an
>> example:
>>
>> typedef long Elongator( int );
>>
>> extern const Elongator *elongator;
>
> I'm confused by that declaration - what is the 'const' supposed to mean in that context? Normally, I would read that declaration as saying that elongator is an identifier with external linkage, and that (*elongator)(5) returns a "const long", which makes no sense to me.
>

The "const" applies to the function type, not the return type of the
function type. That, of course, makes even less sense (how could a
function /not/ be const in C?) - and as noted it the result is undefined
behaviour. But this is described in the semantics section (6.7.3p10),
not the constraints section.

>> There is no way to declare the pointer object 'elongator' without
>> the use of a typedef.
>> It may be worth noting that using a type qualifier directly on a
>> function type is explicitly undefined behavior (but not a constraint
>> violation).
>
> gcc shares my confusion about that declaration, referring to precisely that rule:
> elongator.h:2:25: warning: ISO C forbids qualified function types [-Wpedantic]
> 2 | extern const Elongator *elongator;
> | ^~~~~~~~~
> That error message disappears if I move the 'const', so that it qualifies elongator, which makes a lot more sense to me:
> extern Elongator * const elongator;
>
> and it accepts, as compatible, the following declaration of the same identifier:
>
> extern long(*const elongator)(int);

On 11/04/2023 21:50, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> The only real use I have seen for non-prototype function declarations
>> is a "general" function pointer in arrays containing mixed function
>> pointer types. Such use is no longer allowed in C23. Is that what
>> you are concerned about? Normally a better choice of general function
>> pointer is "void foo(void)", rather than "int foo()". (In C23, the
>> later would now mean "int foo(void)".)
>
> I haven't often had a need for a generic function pointer type (as void*
> is a generic object pointer type), but I suggest that using a return
> type that's not used elsewhere might be safer. If you use `void(void)`
> as a generic function type, there's a risk that a call without a cast
> will quietly compile.
>

That would be even better, yes. But would you not want the non-existent
type to be used for a parameter, rather than the return type? (You
could use it for both.)

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Tuesday, April 11, 2023 at 10:46:24?PM UTC-4, Tim Rentsch wrote:
>
>> James Kuyper <james...@alumni.caltech.edu> writes:
>
> ...
>
>>> The fundamental problem is that, in C, a typedef is nothing more
>>> than an synonym for a type. In any context where you use a typedef,
>>> you could also use the explicit type itself. [...]
>>
>> Strictly speaking this assertion isn't quite right. Here is an
>> example:
>>
>> typedef long Elongator( int );
>>
>> extern const Elongator *elongator;
>
> I'm confused by that declaration - what is the 'const' supposed to
> mean in that context?

'Elongator' is a function type (that maps an int to a long).

'const Elongator' is a 'const' function type; in other words the
qualifier 'const' applies to the function type as a whole, not
just to the return type of the function.

> Normally, I would read that declaration as
> saying that elongator is an identifier with external linkage, and
> that (*elongator)(5) returns a "const long", which makes no sense to
> me.

If 'elongator' had been declared as follows:

const long (*elongator)( int );

that would give the result you describe. But in effect the
declaration of 'elongator' is the following (not legal C, but
meant to show what is taking place):

extern const (long (int)) *elongator;

so the 'const' modifies the function type itself as a whole, and
not just the return type of the function. The syntax used there
is not allowed in C, which is why a typedef is needed.

>> There is no way to declare the pointer object 'elongator' without
>> the use of a typedef.
>> It may be worth noting that using a type qualifier directly on a
>> function type is explicitly undefined behavior (but not a constraint
>> violation).
>
> gcc shares my confusion about that declaration, referring to
> precisely that rule:
> elongator.h:2:25: warning: ISO C forbids qualified
> function types [-Wpedantic]
> 2 | extern const Elongator *elongator;
> | ^~~~~~~~~

Actually I think gcc is not confused, but has (for some unknown
reason) chosen to give a confusing error message. In point of
fact ISO C does not forbid qualified function types, but simply
says they are undefined behavior.

> That error message disappears if I move the 'const', so that it
> qualifies elongator, which makes a lot more sense to me:
> extern Elongator * const elongator;
>
> and it accepts, as compatible, the following declaration of the
> same identifier:
>
> extern long(*const elongator)(int);

Yes, moving 'const' to the other side of the '*' changes the
meaning of the declaration, just like the two declarations

const int *pci;
int *const cpi;

have different meanings for the types of the respective items
being declared.