scott@slp53.sl.home (Scott Lurndal) writes:
> jak <nospam@please.ty> writes:
>>jak ha scritto:
>>> 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.
>>
>>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. 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
>
> 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++).

The runtime representation of a null pointer value is not, I believe,
relevant to the current discussion. What's being discussed is the token
sequence that the NULL macro expands to.

It's legal for NULL to expand to, for example, `((void*)0)` or `0`, as
defined by the implementation. The latter is of type int, which of
course is not a pointer type. We were discussing a piece of code that,
if I recall correctly (I'm too lazy to go back and check) uses a null
pointer constant in a conditional (ternary) expression in such a way
that the expression is invalid (violates a constraint) if NULL expands
to 0.

Using either (void*)0 or (void*)NULL in the code would avoid that
problem.

(Incidentally, C23 will add a "nullptr" keyword, similar to what C++
has.)

--
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 */

jak <nospam@please.ty> writes:
>jak ha scritto:

>>> 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++).
>>>
>> hmm...so we agree, right?
>>
>
>...meaning that if the standard says that 0 if pointer will match a null
>pointer, the compiler on that system will take care of using the null
>pointer when it sees 0 as a pointer. Otherwise what is the standard for?
>The problem will be when the standard is changed again.

In the real world, the address zero is a perfectly legal memory address;
the C standard text simply requires that a null pointer constant cast
to a pointer type should compare unequal to a pointer to any object or
function and that any two null pointers, regardless of type, compare
equal.

Any other integer converted to a pointer type is implementation defined.

While userland code generally doesn't map the first page of the virtual
address space, kernel code does and may need to access via a pointer
with null pointer constant value and is often written in C.

Changing the definition of a null pointer constant would certainly break
a lot of real-world code.

jak <nospam@please.ty> writes:
> 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.

What you need to understand is that we are honestly trying to understand
what you write, but you're not making it easy. I understand that it can
be difficult to write in a language that you don't know well; I
certainly couldn't do so in any language other than my native English.
If I tried to post in a technical form using Google Translate, the
results would be ... amusing. Your apparent efforts have been more
successful than mine would have been. You probably know English a lot
better than I know any language other than English.

There is no "newsgroup manager". Usenet is a cooperative distributed
system. There is no central authority.

Nobody is suggesting that non-native English speakers should not post
here.

I don't know where you got the phrase "specialized function". I'm
curious what phrase Google Translate generated that from (you haven't
mentioned what your native language is).

I'm telling you, as a native English speaker and as someone who has
extensively studied the C language and the various editions of its
standard, that the phrase "specialized function" doesn't make sense in
the way you're using it. There is nothing "specialized" about a
function whose parameter and return types are something other than int.
Older versions of C implicitly used type int in some contexts, but
that's no longer the case (integer constants within a certain range are
still of type int, but that's not relevant to function declarations).

You seem to have expected readers to know what you meant by "specialized
functions". That was an unrealistic expectation. At least one person
made the reasonable but incorrect assumption that you were talking about
C++, since "specialization" is a C++ concept.

You claimed above that:

it is no longer possible to declare a specialized function pointer
array without first declaring the typedef that defines the function
pointer and why.

You have been asked several times to explain that. You have refused to
do so. (You've also refused to explain what you mean by "stretch".)

I will ask you again: What do you mean by that? Can you give an example
in the form of a snippet of C code?

As far as I know, there is no context in C in which declaring an array
of function pointers requires the use of a typedef (though a typedef may
well make the declaration easier for human readers to understand). If
I'm mistaken, you should be able to show us such a declation that uses a
typedef that cannot be changed into equivalent valid C without a
typedef.

Please do so.

And please try to be less arrogant. It's surprising that someone who is
writing in English by using Google Translate would blame his readers
when they don't understand something rather than considering that the
translation might be faulty. We're trying to communicate. Please join
us in that effort.

--
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 */

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

jak <nospam@please.ty> writes:
> Dan Cross ha scritto:
>> 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?
>>
>>> Perhaps you consider being portability if
>>> you move the source code to another machine with the same operating
>>> system, same compiler, same compiler version.
>> This has nothing to do with that. Tim's code was correct and
>> portable.
>> - Dan C.
>>
> Correct for sure but you and I don't have the same concept of portable.
> There are compilers that don't accept things like this:
>
> char val;
> int *pi;
>
> pi = (int *)&val;
>
> because if you assigned a value to *pi you would be using unallocated
> memory and if you really want to do that you need a left cast:
>
> ((char *)pi) = &val;

Was that line of code intended to be in some hypothetical C-like
language, using a feature that you wish C provided? If that was the
point you were trying to make, it wasn't clear.

That line of code;

((char *)pi) = &val;

is not valid C. (It's also not valid C++.) When I attempt to compile
it, I get:

error: lvalue required as left operand of assignment

As for the original code:

char val;
int *pi;

pi = (int *)&val;

That doesn't violate any constraint or syntax rule, but it's likely to
have undefined behavior depending on the characteristics of the
implementation. A compiler *could* reject that code, but I'd be
surprised to see one that actually did so. A warning might be
appropriate, but most C compilers take a pointer cast as an assertion by
the programmer that "I know what I'm doing". Do you know of a compiler
that doesn't accept it?

--
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:26, Dan Cross wrote:
> In article <u11bll$27m86$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
> You (and honestly, me) are both speculating. This is why I
> asked him what he meant; he responded by asking me why I was
> asking him. Subsequent posts from me suggest a less than
> stellar command of the language, so I suspect he's simply
> confused.
....
> Why don't we let him speak for himself?

Because he hasn't chosen to do so, and because frankly, he doesn't do
that good a job of it. He's got language difficulties, and is using
Google translate to work around them. I've occasionally used Google
translate to respond to foreign language inquiries that arrive in this
newsgroup, but I always do so with a great deal of fear and trepidation
about how it might have mangled my message.

Keith Thompson ha scritto:
> jak <nospam@please.ty> writes:
>> 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.
>
> What you need to understand is that we are honestly trying to understand
> what you write, but you're not making it easy. I understand that it can
> be difficult to write in a language that you don't know well; I
> certainly couldn't do so in any language other than my native English.
> If I tried to post in a technical form using Google Translate, the
> results would be ... amusing. Your apparent efforts have been more
> successful than mine would have been. You probably know English a lot
> better than I know any language other than English.
>
> There is no "newsgroup manager". Usenet is a cooperative distributed
> system. There is no central authority.
>
> Nobody is suggesting that non-native English speakers should not post
> here.
>
> I don't know where you got the phrase "specialized function". I'm
> curious what phrase Google Translate generated that from (you haven't
> mentioned what your native language is).
>
> I'm telling you, as a native English speaker and as someone who has
> extensively studied the C language and the various editions of its
> standard, that the phrase "specialized function" doesn't make sense in
> the way you're using it. There is nothing "specialized" about a
> function whose parameter and return types are something other than int.
> Older versions of C implicitly used type int in some contexts, but
> that's no longer the case (integer constants within a certain range are
> still of type int, but that's not relevant to function declarations).
>
> You seem to have expected readers to know what you meant by "specialized
> functions". That was an unrealistic expectation. At least one person
> made the reasonable but incorrect assumption that you were talking about
> C++, since "specialization" is a C++ concept.
>
> You claimed above that:
>
> it is no longer possible to declare a specialized function pointer
> array without first declaring the typedef that defines the function
> pointer and why.
>
> You have been asked several times to explain that. You have refused to
> do so. (You've also refused to explain what you mean by "stretch".)
>
> I will ask you again: What do you mean by that? Can you give an example
> in the form of a snippet of C code?
>
> As far as I know, there is no context in C in which declaring an array
> of function pointers requires the use of a typedef (though a typedef may
> well make the declaration easier for human readers to understand). If
> I'm mistaken, you should be able to show us such a declation that uses a
> typedef that cannot be changed into equivalent valid C without a
> typedef.
>
> Please do so.
>
> And please try to be less arrogant. It's surprising that someone who is
> writing in English by using Google Translate would blame his readers
> when they don't understand something rather than considering that the
> translation might be faulty. We're trying to communicate. Please join
> us in that effort.
>

I was looking for the opposite of "implicit default function
declaration" :^(

jak <nospam@please.ty> writes:
> jak ha scritto:
>> Scott Lurndal ha scritto:
>>> jak <nospam@please.ty> writes:
>>>> jak ha scritto:
>>>>> 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.
>>>>
>>>> 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. 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
>>>
>>> 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++).
>>>
>> hmm...so we agree, right?
>
> ...meaning that if the standard says that 0 if pointer will match a null
> pointer, the compiler on that system will take care of using the null
> pointer when it sees 0 as a pointer. Otherwise what is the standard for?
> The problem will be when the standard is changed again.

Again, the code being discussed was affected by the implementation's
definition of the NULL macro, not the run-time representation of
a null pointer value.

The constant 0 explicitly or implicitly converted to a pointer type
yields a null pointer value. Yes, the language standard guarantees
that. Your concern that a future edition of the standard might not
make that guarantee is, I believe, unfounded. Such a change would
quietly break large amounts of existing code, and the maintainers
of the standard carefully avoid making such changes.

(To be clear, the guarantee applies to "an integer constant expression
with the value 0", not to any arbitrary integer expression with the
value 0. `(void*)(2-2)` yields a null pointer value. Given `int n = 0;`
`(void*)n` is not guaranteed to yield a null pointer value.)

--
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 */

jak <nospam@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. 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.

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.

Please show us the code in question.

--
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 */

Keith Thompson ha scritto:
> jak <nospam@please.ty> writes:
>> 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.
>
> What you need to understand is that we are honestly trying to understand
> what you write, but you're not making it easy. I understand that it can
> be difficult to write in a language that you don't know well; I
> certainly couldn't do so in any language other than my native English.
> If I tried to post in a technical form using Google Translate, the
> results would be ... amusing. Your apparent efforts have been more
> successful than mine would have been. You probably know English a lot
> better than I know any language other than English.
>
> There is no "newsgroup manager". Usenet is a cooperative distributed
> system. There is no central authority.
>
> Nobody is suggesting that non-native English speakers should not post
> here.
>
> I don't know where you got the phrase "specialized function". I'm
> curious what phrase Google Translate generated that from (you haven't
> mentioned what your native language is).
>
> I'm telling you, as a native English speaker and as someone who has
> extensively studied the C language and the various editions of its
> standard, that the phrase "specialized function" doesn't make sense in
> the way you're using it. There is nothing "specialized" about a
> function whose parameter and return types are something other than int.
> Older versions of C implicitly used type int in some contexts, but
> that's no longer the case (integer constants within a certain range are
> still of type int, but that's not relevant to function declarations).
>
> You seem to have expected readers to know what you meant by "specialized
> functions". That was an unrealistic expectation. At least one person
> made the reasonable but incorrect assumption that you were talking about
> C++, since "specialization" is a C++ concept.
>
> You claimed above that:
>
> it is no longer possible to declare a specialized function pointer
> array without first declaring the typedef that defines the function
> pointer and why.
>
> You have been asked several times to explain that. You have refused to
> do so. (You've also refused to explain what you mean by "stretch".)
>
> I will ask you again: What do you mean by that? Can you give an example
> in the form of a snippet of C code?
>
> As far as I know, there is no context in C in which declaring an array
> of function pointers requires the use of a typedef (though a typedef may
> well make the declaration easier for human readers to understand). If
> I'm mistaken, you should be able to show us such a declation that uses a
> typedef that cannot be changed into equivalent valid C without a
> typedef.
>
> Please do so.
>
> And please try to be less arrogant. It's surprising that someone who is
> writing in English by using Google Translate would blame his readers
> when they don't understand something rather than considering that the
> translation might be faulty. We're trying to communicate. Please join
> us in that effort.
>

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.

In article <u11kei$2907o$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 13:26, Dan Cross wrote:
>> In article <u11bll$27m86$1@dont-email.me>,
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>...
>> You (and honestly, me) are both speculating. This is why I
>> asked him what he meant; he responded by asking me why I was
>> asking him. Subsequent posts from me suggest a less than
>> stellar command of the language, so I suspect he's simply
>> confused.
>...
>> Why don't we let him speak for himself?
>
>Because he hasn't chosen to do so, and because frankly, he doesn't do
>that good a job of it. He's got language difficulties, and is using
>Google translate to work around them. I've occasionally used Google
>translate to respond to foreign language inquiries that arrive in this
>newsgroup, but I always do so with a great deal of fear and trepidation
>about how it might have mangled my message.

Then given that you admit that neither of us actually knows what
he originally meant, perhaps we should refrain from assuming and
leveling accusations of "confusion" based on those assumptions.

- Dan C.

jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
[...]
>> I don't know where you got the phrase "specialized function". I'm
>> curious what phrase Google Translate generated that from (you haven't
>> mentioned what your native language is).
[...]
> I was looking for the opposite of "implicit default function
> declaration" :^(

OK, fine.

C dropped the "implicit int" rule in the 1999 standard. In C90, this:

foo(int arg);

would declare foo as a function returning int. In C99 and later it's a
syntax error. If I understand you correctly, there is no need for the
phrase "specialized function", since all functions are "specialized".

One more time: You made a specific claim about some construct requiring
a typedef. You seem to be carefully avoiding explaining what you mean.

Please either show us a construct that demonstrates the issue you're
talking about, or stop wasting our time. (And please also explain what
you meant by "stretch" elsewhere in this thread.)

You've said it's something you asked about here a few years ago, and you
were told that a typedef is required. If you don't remember the
details and you aren't able to find them, that's ok; just say so.
But you've given the impression, perhaps unintentionally, that you're
being deliberately evasive. You asked for an explanation, but you
haven't given us the information necessary to provide one.

--
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 14:27, jak wrote:
> Keith Thompson ha scritto:
....
>> I don't know where you got the phrase "specialized function". I'm
>> curious what phrase Google Translate generated that from (you haven't
>> mentioned what your native language is).
>>
>> I'm telling you, as a native English speaker and as someone who has
>> extensively studied the C language and the various editions of its
>> standard, that the phrase "specialized function" doesn't make sense in
>> the way you're using it. There is nothing "specialized" about a
>> function whose parameter and return types are something other than int.
>> Older versions of C implicitly used type int in some contexts, but
>> that's no longer the case (integer constants within a certain range are
>> still of type int, but that's not relevant to function declarations).
>>
>> You seem to have expected readers to know what you meant by "specialized
>> functions". That was an unrealistic expectation. At least one person
>> made the reasonable but incorrect assumption that you were talking about
>> C++, since "specialization" is a C++ concept.
>>
>> You claimed above that:
>>
>> it is no longer possible to declare a specialized function pointer
>> array without first declaring the typedef that defines the function
>> pointer and why.
>>
>> You have been asked several times to explain that. You have refused to
>> do so. (You've also refused to explain what you mean by "stretch".)
....
> I was looking for the opposite of "implicit default function
> declaration" :^(

Implicit function declarations disappeared in C99. There no longer is
anything to be the opposite of.
Code showing how a typedef is necessary in order to declare an array of
function pointers would help clarify what you're talking about.

Keith Thompson ha scritto:
> jak <nospam@please.ty> writes:
>> Keith Thompson ha scritto:
> [...]
>>> I don't know where you got the phrase "specialized function". I'm
>>> curious what phrase Google Translate generated that from (you haven't
>>> mentioned what your native language is).
> [...]
>> I was looking for the opposite of "implicit default function
>> declaration" :^(
>
> OK, fine.
>
> C dropped the "implicit int" rule in the 1999 standard. In C90, this:
>
> foo(int arg);
>
> would declare foo as a function returning int. In C99 and later it's a
> syntax error. If I understand you correctly, there is no need for the
> phrase "specialized function", since all functions are "specialized".
>
> One more time: You made a specific claim about some construct requiring
> a typedef. You seem to be carefully avoiding explaining what you mean.
>
> Please either show us a construct that demonstrates the issue you're
> talking about, or stop wasting our time. (And please also explain what
> you meant by "stretch" elsewhere in this thread.)
>
> You've said it's something you asked about here a few years ago, and you
> were told that a typedef is required. If you don't remember the
> details and you aren't able to find them, that's ok; just say so.
> But you've given the impression, perhaps unintentionally, that you're
> being deliberately evasive. You asked for an explanation, but you
> haven't given us the information necessary to provide one.
>

You talk to me as if I forced you to answer me. Just ignore me.

In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote:
>Keith Thompson ha scritto:
>>[snip]
>
>You talk to me as if I forced you to answer me. Just ignore me.

Actually, he's been both incredibly patient and polite, and made
a sincere effort to communicate with you respectfully. Perhaps
the translation software you are using is not particularly good,
but one cannot escape the impression that you are being
deliberately rude.

- Dan C.

Dan Cross ha scritto:
> In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote:
>> Keith Thompson ha scritto:
>>> [snip]
>>
>> You talk to me as if I forced you to answer me. Just ignore me.
>
> Actually, he's been both incredibly patient and polite, and made
> a sincere effort to communicate with you respectfully. Perhaps
> the translation software you are using is not particularly good,
> but one cannot escape the impression that you are being
> deliberately rude.
>
> - Dan C.
>
Again...
You talk to one and another answers. You confuse me with the values:
In my opinion, those who say "you don't understand" are arrogant, not
those who say "I didn't explain myself well".
In my opinion "waste our time" is offensive to me and to all of you.
I also thought that many of you are in some whatsapp or telegram group
chat to get along and make fun of people here.

In article <u11nhi$29ksm$1@dont-email.me>, jak <nospam@please.ty> wrote:
>Dan Cross ha scritto:
>> In article <u11mde$29eis$1@dont-email.me>, jak <nospam@please.ty> wrote:
>>> Keith Thompson ha scritto:
>>>> [snip]
>>>
>>> You talk to me as if I forced you to answer me. Just ignore me.
>>
>> Actually, he's been both incredibly patient and polite, and made
>> a sincere effort to communicate with you respectfully. Perhaps
>> the translation software you are using is not particularly good,
>> but one cannot escape the impression that you are being
>> deliberately rude.
>
>Again...
>You talk to one and another answers. You confuse me with the values:
>In my opinion, those who say "you don't understand" are arrogant, not
>those who say "I didn't explain myself well".
>In my opinion "waste our time" is offensive to me and to all of you.
>I also thought that many of you are in some whatsapp or telegram group
>chat to get along and make fun of people here.

*shrug* I don't understand why any of that is coming up in your
response to me. I guess all I can say is, "Please don't feed
the troll."

- Dan C.

jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
>> jak <nospam@please.ty> writes:
>>> Keith Thompson ha scritto:
>> [...]
>>>> I don't know where you got the phrase "specialized function". I'm
>>>> curious what phrase Google Translate generated that from (you haven't
>>>> mentioned what your native language is).
>> [...]
>>> I was looking for the opposite of "implicit default function
>>> declaration" :^(
>> OK, fine.
>> C dropped the "implicit int" rule in the 1999 standard. In C90,
>> this:
>> foo(int arg);
>> would declare foo as a function returning int. In C99 and later
>> it's a
>> syntax error. If I understand you correctly, there is no need for the
>> phrase "specialized function", since all functions are "specialized".
>> One more time: You made a specific claim about some construct
>> requiring
>> a typedef. You seem to be carefully avoiding explaining what you mean.
>> Please either show us a construct that demonstrates the issue you're
>> talking about, or stop wasting our time. (And please also explain what
>> you meant by "stretch" elsewhere in this thread.)
>> You've said it's something you asked about here a few years ago, and
>> you
>> were told that a typedef is required. If you don't remember the
>> details and you aren't able to find them, that's ok; just say so.
>> But you've given the impression, perhaps unintentionally, that you're
>> being deliberately evasive. You asked for an explanation, but you
>> haven't given us the information necessary to provide one.
>
> You talk to me as if I forced you to answer me. Just ignore me.

No, you did not force me to answer you.

You asked a specific question upthread:

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.

I chose to attempt to answer that question because I found it
interesting. To do so, I need information that you have not provided,
even after multiple requests that you do so.

I don't know why you refuse to elaborate, and I will not waste any more
of *my* time asking you to do so. I believe that you are mistaken on
the technical point, and that it *is* possible in modern C to do
whatever it was you were referring to without using typedef. If you
actually want an answer, you know what you need to do.

--
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 */

jak <nospam@please.ty> writes:
[...]
> I also thought that many of you are in some whatsapp or telegram group
> chat to get along and make fun of people here.

For the record, no, we don't do that. I very rarely communicate with
any of the other regulars of this newsgroup other than in the newsgroup
itself. There is no conspiracy to make fun of you or anyone else.

--
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 10/04/2023 19:22, Keith Thompson wrote:
> jak <nospam@please.ty> writes:
>> There are compilers that don't accept things like this:
>>
>> char val;
>> int *pi;
>>
>> pi = (int *)&val;
>>
>> because if you assigned a value to *pi you would be using unallocated
>> memory and if you really want to do that you need a left cast:
>>
>> ((char *)pi) = &val;
>
> Was that line of code intended to be in some hypothetical C-like
> language, using a feature that you wish C provided? If that was the
> point you were trying to make, it wasn't clear.
>
> That line of code;
>
> ((char *)pi) = &val;
>
> is not valid C. (It's also not valid C++.) When I attempt to compile
> it, I get:
>
> error: lvalue required as left operand of assignment
I can't see much wrong with it. It works fine with tcc and (my) bcc
compilers. It assigns an address to pointer. The cast is needed because
otherwise there's a type mismatch (assigning char* address to a int*
pointer).

I'm surprised that gcc reports it as an error rather than a warning as
it does with nearly everything else, for example:

int *pi;
char *pc;
pi = pc;

gives a warning.

Bart <bc@freeuk.com> writes:
> On 10/04/2023 19:22, Keith Thompson wrote:
>> jak <nospam@please.ty> writes:
>>> There are compilers that don't accept things like this:
>>>
>>> char val;
>>> int *pi;
>>>
>>> pi = (int *)&val;
>>>
>>> because if you assigned a value to *pi you would be using unallocated
>>> memory and if you really want to do that you need a left cast:
>>>
>>> ((char *)pi) = &val;
>>
>> Was that line of code intended to be in some hypothetical C-like
>> language, using a feature that you wish C provided? If that was the
>> point you were trying to make, it wasn't clear.
>>
>> That line of code;
>>
>> ((char *)pi) = &val;
>>
>> is not valid C. (It's also not valid C++.) When I attempt to compile
>> it, I get:
>>
>> error: lvalue required as left operand of assignment
> I can't see much wrong with it. It works fine with tcc and (my) bcc
> compilers. It assigns an address to pointer. The cast is needed
> because otherwise there's a type mismatch (assigning char* address to
> a int* pointer).
>
> I'm surprised that gcc reports it as an error rather than a warning as
> it does with nearly everything else, for example:
>
> int *pi;
> char *pc;
> pi = pc;
>
> gives a warning.

I'm not sure why you're surprised.

A cast operation takes an expression that specifies a *value* and yields
a *value* of the specified type. It does not yield a reference to an
object (in other words, it's not an lvalue).

Similarly, this:

int n;
n + 2 = 4;

does not set n to 2; it's a constraint violation, because n + 2 is not
an lvalue.

gcc does, in its default mode, allow a lot of implicit pointer
conversions that are not permitted by the language, perhaps because they
were usually permitted by pre-ANSI C implementations and the gcc
maintainers never saw a good time to break old code. I don't think
most historical C compilers ever treated cast expressions as lvalues,
so that consideration doesn't apply in this case.

You're right that tcc (I have version 0.9.27) accepts the assignment
without complaint. I find that surprising.

Certainly C *could* have been defined so that a cast expression can be
an lvalue (presumably only if the operand is an lvalue). It just wasn't
defined that way. A cast yields a converted value, not a converted
object.

(To be clear, the standard's syntactic category "cast-expression"
includes expressions that have no cast operators. I'm talking about an
expression with a cast operator at the top level.)

--
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 */

Bart <bc@freeuk.com> writes:

> On 10/04/2023 19:22, Keith Thompson wrote:

>> That line of code;
>>
>> ((char *)pi) = &val;
>>
>> is not valid C. (It's also not valid C++.) When I attempt to compile
>> it, I get:
>>
>> error: lvalue required as left operand of assignment
>
> I can't see much wrong with it.

It violates a constraint. A cast expression does not yield an l-value.
Obviously, C could have been designed so that assigning to a cast
expression meant something (what, exactly I don't know), but it was not.
In C, you convert the value being assigned.

> It works fine with tcc

That's a shame. A diagnostic is required since tcc claims to be conforming.

> and (my) bcc compilers. It assigns an address to pointer. The cast is
> needed because otherwise there's a type mismatch (assigning char*
> address to a int* pointer).

A cast on the value makes that obvious. What does a cast on the lvalue
do as there is nothing to convert? How does bcc treat

double d;
(int)d = 42;

? Does it just treat the cast as an instruction to be quiet while
generating code to move sizeof 42 bytes to d's location?

tcc, by the way, correctly generates a diagnostic (in fact an error):
"error: lvalue expected" for that line. I don't know why it doesn't
for the pointer case.

> I'm surprised that gcc reports it as an error rather than a warning as it
> does with nearly everything else,

It's suggests the author of the code is deeply baffled by the language
so I would agree that it's serious flaw meriting an error message.

--
Ben.

On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> jak <nospam@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>.

Ike Naar <ike@sdf.org> writes:

> On 2023-04-10, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> jak <nospam@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?

--
Ben.

On 10/04/2023 22:36, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 10/04/2023 19:22, Keith Thompson wrote:
>
>>> That line of code;
>>>
>>> ((char *)pi) = &val;
>>>
>>> is not valid C. (It's also not valid C++.) When I attempt to compile
>>> it, I get:
>>>
>>> error: lvalue required as left operand of assignment
>>
>> I can't see much wrong with it.
>
> It violates a constraint. A cast expression does not yield an l-value.
> Obviously, C could have been designed so that assigning to a cast
> expression meant something (what, exactly I don't know), but it was not.
> In C, you convert the value being assigned.

Whatever the type of the LHS of an assignment, it would override that
with the cast type.

> How does bcc treat
>
> double d;
> (int)d = 42;

It doesn't report it but it doesn't work that well either. I think it
would just be simpler to not allow it.

My lvalue-checking logic needs to allow the use of & in front of an
lvalue expression, but it also needs to be stricter when it is the LHS
of an assignment or anything that modifies memory. I've now made that
change.

> ? Does it just treat the cast as an instruction to be quiet while
> generating code to move sizeof 42 bytes to d's location?

For the (int)d example, type-punning would be more more appropriate to
get that behaviour. There are no type-punning casts in C, but it can be
emulated with:

*(int*)&d = 42;

>
> tcc, by the way, correctly generates a diagnostic (in fact an error):
> "error: lvalue expected" for that line. I don't know why it doesn't
> for the pointer case.

The original example perhaps works in tcc, because the cast in that case
is a no-op, not requiring anything to be converted except changing the type.