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

On 4/10/23 11:29, jak wrote:
....
> char val;
> int *pi;
>
> pi = (int *)&val;
>
> because if you assigned a value to *pi you would be using unallocated
> memory

The problem with that code has nothing to do with the problem Tim was
talking about, nor does it have anything to do with unallocated memory.
It has undefined behavior if &val points to a memory location that is
not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
even if it is correctly aligned, the value stored in pi cannot be used
to access an 'int', because it doesn't point at an int object.

> ... and if you really want to do that you need a left cast:
>
> ((char *)pi) = &val;

The left hand side of an assignment is required to be a modifiable
lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.

On 4/10/23 11:37, Dan Cross wrote:
> In article <u11aau$27go8$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/10/23 10:52, Dan Cross wrote:
>>> 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?
>>
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
>
> It seemed that jak was suggesting that in Tim's forumulation,
> one should cast the 0 in p = 0, as in `p = (void *)0`.

I don't think so. I believe that he was suggesting that it would be
preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or
simply "free(ptr), (void*)0", which would avoid the implementation
dependency. I took this as a suggestion of style, rather than implying
that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's
type, and is the value of the assignment expression, is a little too
subtle for Jak, and I can see his point.

>>>> 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.
>>
>> Tim's comment about an implementation dependency was written about code
>> written by Kaz Kylheku. That code does indeed have an implementation
>> dependency. Depending upon which choice an implementation makes for the
>> null pointer constant that NULL expands into, Kaz's code might or might
>> not contain a constraint violation.
>
> That was not what I was referring to; see above and please note
> the exact words I responded to (specifically the post that
> referred to "autocast").

Jak's comment using the phrase "autocast" was not referring to any
implementation dependency in Tim's code, only to the same implementation
dependency in Kaz's code that Tim himself was talking about.

James Kuyper ha scritto:
> On 4/10/23 10:29, jak wrote:
>> James Kuyper ha scritto:
>>> On 4/10/23 03:31, jak wrote:
>>>> Keith Thompson ha scritto:
>>>>> jak <nospam@please.ty> writes:
>>>>> [...]
>>>>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>>>>> on autocast and use an explicit one instead.
>>>>>
>>>>> I've never seen the term "autocast" before.
>>>>>
>>>>> A cast is an explicit conversion. A conversion done without a cast is
>>>>> an implicit conversion. "Autocast" would be a contradiction.
>>>>>
>>>>
>>>> Maybe this is because we don't come from the same county and therefore,
>>>> probably, haven't read the same books? I don't formalize myself nor am I
>>>> shocked when I read 'implicit conversion' despite the cast it should be
>>>> considered a stretch and not a conversion. Perhaps you too should have a
>>>> more open mind.
> ...
>>> The word "stretch" appears nowhere in the C standard. As a very
>>> well-read native speaker of English with a very good understanding of C,
>>> and a fairly good understanding of most programming jargon, I'm not sure
>>> what you mean by "stretch". None of the 10 meanings listed at
>>> wiktionary.org for "stretch" seems applicable.
>>> Would you care to describe what you mean by that term, and how it
>>> differs from a conversion? I haven't a clue.
> ...
>> Are you K.T's knight perhaps? Please stop quoting bits of manuals that
>> everyone has read hundreds of times, be less obtuse and learn to read
>> what is not written. Some field work wouldn't hurt. Do not hoe but claim
>> to design hoes.
>
> Are you referring to Keith Thompson? I am not his knight, whatever you
> might mean by that; we're just two people with similar attitudes about
> formal rigor, and as a result are often (but not always) in agreement
> about what the standard means.
> The standard is not a manual. I seriously doubt that you have read it
> hundreds of times.
> I remain unenlightened as to what "stretch" might mean in this context.
> I can't even imagine where I might look for a definition.
>
>
Keep your doubts close to you as well. I'm still ahead of you because I
know that I don't know.

On Mon, 10 Apr 2023 11:34:54 -0400
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
> On 4/10/23 10:52, Dan Cross wrote:
> > 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?
>
> The comment about "implementation dependency" was written by Tim, jak
> was merely referring to that comment.

Yes , but which piece of code was jak referring to ? For easy reference lets
call Code A

return (size == 0) ? free(ptr), NULL : realloc(ptr, size);

which posted by Kaz in <20230407042121.909@kylheku.com> and Code B

void *
realloc0( void *p, size_t size ){
return size == 0 ? free( p ), p = 0 : realloc( p, size );
}

which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
"If you absolutely wanted to avoid dependency" which of the 2 code excerpts
was he referring to ? I took it to mean that he was referring to Code B and I
think Dan took it to mean the same. Code B does not have any "implementation
dependency" , it just relies on the C standard. In contrast , Code A may have
a constraint violation depending on how the implementation defines NULL , as
Tim pointed out.

> >> 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.
>
> Tim's comment about an implementation dependency was written about code
> written by Kaz Kylheku. That code does indeed have an implementation
> dependency. Depending upon which choice an implementation makes for the
> null pointer constant that NULL expands into, Kaz's code might or might
> not contain a constraint violation.

On 4/10/23 11:35, Dan Cross wrote:
> In article <u119gi$27go7$1@dont-email.me>,
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>> On 4/10/23 10:51, Dan Cross wrote:
>>> In article <u116a4$270uv$1@dont-email.me>,
>>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>>> On 4/9/23 15:34, Dan Cross wrote:
>>>>> 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?
>>>>
>>>> The C standard merely requires that NULL expand to a null pointer
>>>> constant. It depends upon the implementation which null pointer
>>>> constant
>>>> it expands to. A null pointer constant necessarily has either an
>>>> integer
>>>> type or the type void*. The comma expression will have that same type.
>>>> An integer type results in a constraint violation, void* does not.
>>>> That's the implementation dependency that Tim was talking about.
>>>
>>> The C standard has been quite explicit that integer 0 is
>>> a valid null pointer constant since C89. Tim's code was
>>> correct and had no dependency.
>>
>> Correct. 0 is a valid null pointer constant. It has a type of int.
>> Therefore, the expression "free(p), 0' would have a value of 0 and a
>> type of int. The expression 'size == 0 ? NULL : realloc(p, size)" would
>> not be problematic because, in that context, a null pointer constant
>> gets implicitly converted to a null pointer with the same type as the
>> return value of realloc (6.5.15p7). However, function calls are not
>> allowed in integer constant expressions (6.6p6), so "free(p), 0" does
>> NOT qualify as an integer constant expression, and therefore also does
>> not qualify as a null pointer constant (6.3.2.3p3). A conditional
>> expression where the second operand has an arithmetic type, but does not
>> qualify as a null pointer constant, and a third operand that has pointer
>> type, doesn't match any of the permitted combinations listed in the
>> constraints on conditional expressions (6.5.15p3):
>>
>> "One of the following shall hold for the second and third operands:
>> ISO/IEC 9899:202x (E)
>> — both operands have arithmetic type;
>> — both operands have the same structure or union type;
>> — both operands have void type;
>> — both operands are pointers to qualified or unqualified versions of
>> compatible types;
>> — one operand is a pointer and the other is a null pointer constant; or
>> — one operand is a pointer to an object type and the other is a pointer
>> to a qualified or unqualified
>> version of void ."
>
> I do not know why you are addressing this to me. I agreed with
> the overall analysis and don't think I posted anything to the
> contrary.
>
> Perhaps you meant to respond to someone else?

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.

On 4/10/23 11:58, Spiros Bousbouras wrote:
> On Mon, 10 Apr 2023 11:34:54 -0400
> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
....
>> The comment about "implementation dependency" was written by Tim, jak
>> was merely referring to that comment.
>
> Yes , but which piece of code was jak referring to ? For easy reference lets
> call Code A
>
> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>
> which posted by Kaz in <20230407042121.909@kylheku.com> and Code B
>
> void *
> realloc0( void *p, size_t size ){
> return size == 0 ? free( p ), p = 0 : realloc( p, size );
> }
>
> which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
> was he referring to ? I took it to mean that he was referring to Code B and I
> think Dan took it to mean the same. Code B does not have any "implementation
> dependency" , it just relies on the C standard. In contrast , Code A may have
> a constraint violation depending on how the implementation defines NULL , as
> Tim pointed out.

I took jak as referring to both code A and code B. He was saying that
code A has an implementation dependency, while code B did not, but that
he would prefer a different way of modifying code A to avoid that
dependency. I understood him to be expressing a stylistic preference,
not something required in order for the code to be correct.

James Kuyper ha scritto:
> On 4/10/23 11:29, jak wrote:
> ...
>> char val;
>> int *pi;
>>
>> pi = (int *)&val;
>>
>> because if you assigned a value to *pi you would be using unallocated
>> memory
>
> The problem with that code has nothing to do with the problem Tim was
> talking about, nor does it have anything to do with unallocated memory.
> It has undefined behavior if &val points to a memory location that is
> not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
> even if it is correctly aligned, the value stored in pi cannot be used
> to access an 'int', because it doesn't point at an int object.
>
>> ... and if you really want to do that you need a left cast:
>>
>> ((char *)pi) = &val;
>
> The left hand side of an assignment is required to be a modifiable
> lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
>

hmmm... in my point of view declaring a variable corresponds to
allocating memory while using malloc means allocating memory
dynamically. For me it is not easy to express concepts in your language
and in addition you continue to take me back on the quibbles. Maybe we
can talk again when I improve my English and you're less picky.

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.

On 4/10/23 12:10, jak wrote:
> James Kuyper ha scritto:
>> On 4/10/23 11:29, jak wrote:
>> ...
>>> char val;
>>> int *pi;
>>>
>>> pi = (int *)&val;
>>>
>>> because if you assigned a value to *pi you would be using unallocated
>>> memory
>>
>> The problem with that code has nothing to do with the problem Tim was
>> talking about, nor does it have anything to do with unallocated memory.
>> It has undefined behavior if &val points to a memory location that is
>> not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
>> even if it is correctly aligned, the value stored in pi cannot be used
>> to access an 'int', because it doesn't point at an int object.
>>
>>> ... and if you really want to do that you need a left cast:
>>>
>>> ((char *)pi) = &val;
>>
>> The left hand side of an assignment is required to be a modifiable
>> lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
>>
>
> hmmm... in my point of view declaring a variable corresponds to
> allocating memory while using malloc means allocating memory
> dynamically. For me it is not easy to express concepts in your language
> and in addition you continue to take me back on the quibbles. Maybe we
> can talk again when I improve my English and you're less picky.

Declaring 'val' allocates memory to store a char. Declaring pi allocates
memory to store a pointer to an int. (int*)val is an expression that
could have undefined behavior, for reasons that have nothing to do with
unallocated memory. If it doesn't have undefined behavior, the result of
that conversion can safely be stored in the memory allocated for pi. It
cannot, however, be used to access an int object, because it doesn't
point at any such object.

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.

jak <nospam@please.ty> writes:
> Keith Thompson ha scritto:
>> jak <nospam@please.ty> writes:
>> [...]
>>> If you absolutely wanted to avoid dependency, perhaps you shouldn't rely
>>> on autocast and use an explicit one instead.
>> I've never seen the term "autocast" before.
>> A cast is an explicit conversion. A conversion done without a cast
>> is
>> an implicit conversion. "Autocast" would be a contradiction.
>
> Maybe this is because we don't come from the same county and therefore,
> probably, haven't read the same books? I don't formalize myself nor am I
> shocked when I read 'implicit conversion' despite the cast it should be
> considered a stretch and not a conversion. Perhaps you too should have a
> more open mind.

I don't know what you mean by "stretch". Can you explain?
Perhaps it has some technical meaning in books you've read, but I
haven't encountered it.

Having a "more open mind" doesn't help me to understand unfamiliar
terms that haven't been defined. "autocast", unlike "stretch",
is obvious enough in context, but in my opinion it's unnecessarily
obscure. When discussing C, I strongly prefer to use terms defined
by the C standard, with the meanings assigned by that standard.
I think that's the best way to establish a common vocabulary and
promote effective communication. I don't see that "autocast"
expresses anything that isn't more effectively expressed by
"implicit conversion".

As for the technical issue, I've found that implicit conversions are
often better (less error-prone, leading to more easily maintainable
code) than explicit casts. C probably has more implicit conversions
than I'm entirely comfortable with, but most of them do the right
thing most of the time. If you use a cast, you have the additional
burden of specifying the correct type, and keeping it correct as
the code is maintained.

--
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:
>> Are you K.T's knight perhaps? Please stop quoting bits of manuals that
>> everyone has read hundreds of times, be less obtuse and learn to read
>> what is not written. Some field work wouldn't hurt. Do not hoe but claim
>> to design hoes.
>> 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'm not aware that that's true. If it is, I invite you to start a new
thread to discuss it. I don't know what you mean by "specialized" in
this context, and I'm not aware of any case where declaring an array of
function pointers requires a typedef.

This thread has already drifted, as many threads do, so it might not
matter a great deal whether you start a new thread or not, but it is a
substantial change of topic.

--
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 Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote:
> James Kuyper ha scritto:
> > On 4/10/23 11:29, jak wrote:
> > ...
> >> char val;
> >> int *pi;
> >>
> >> pi = (int *)&val;
> >>
> >> because if you assigned a value to *pi you would be using unallocated
> >> memory
> >
> > The problem with that code has nothing to do with the problem Tim was
> > talking about, nor does it have anything to do with unallocated memory.
> > It has undefined behavior if &val points to a memory location that is
> > not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
> > even if it is correctly aligned, the value stored in pi cannot be used
> > to access an 'int', because it doesn't point at an int object.
> >
> >> ... and if you really want to do that you need a left cast:
> >>
> >> ((char *)pi) = &val;
> >
> > The left hand side of an assignment is required to be a modifiable
> > lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
> >
> hmmm... in my point of view declaring a variable corresponds to
> allocating memory while using malloc means allocating memory
> dynamically. For me it is not easy to express concepts in your language
> and in addition you continue to take me back on the quibbles. Maybe we
> can talk again when I improve my English and you're less picky.
>
In a sense that is right. But generally the term "allocating" isn't used for
variables created on the stack, unless maybe for large arrays.
The reason is that the stack works by magic. Within the confines of the
C language, there is no way to express that the stack might fail, though
of course it must do so eventually if allowed to get arbitrarily deep.

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

James and I do not speak for each other, but I see no reason to think he
was joking, and I agree with what he wrote. I'm not assuming that you
were making a point about C++, but the word "specialized" does suggest
that it's likely; if so, I suggest posting in comp.lang.c++.

If you perceive a joke, perhaps you can explain it to us.

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

On 4/10/23 12: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.
....
> 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.

Google translate does not do a good enough job of translating your
language into English, to allow discussion of such complicated issues.
If there's any forum using a language that you understand well enough, I
recommend using it.

I would never have considered the possibility that someone would use to
term "specialized function" to refer to such a thing. I still don't
understand the problem that you're complaining about. You can declare an
array of pointers to unspecialized functions as follows:

int unspec(int);
int (*unspec_array1[15])(int)={unspec};

An array of pointers to any particular specialized function type can be
declared equally easily:

char spec(double);
char (*spec_array1[15])(double)={spec};

I think you've left out some important details about what it is you want
to do, that prevents it from being done without a typedef.
Perhaps you're thinking of a heterogeneous array, one that contains
pointers to functions with two or more different types? The array itself
can have only one type, and using such an array often requires
conversion of a function pointer type to that type. A typedef makes that
much simpler, but is not necessary.

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
but tomorrow someone will change the 'standard' and this will no longer
be true. Portability should also be considered over time and making sure
both branches of the ternary operator return a pointer by adding a cast
even if it's now unnecessary is not a bad thing because it could make
the function *also* portable over time. Those who have coded for decades
have seen these things and know they will happen again.

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

In article <u11bll$27m86$1@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:37, Dan Cross wrote:
>>[snip]
>> It seemed that jak was suggesting that in Tim's forumulation,
>> one should cast the 0 in p = 0, as in `p = (void *)0`.
>
>I don't think so. I believe that he was suggesting that it would be
>preferable to rewrite Kaz's formulation as "free(ptr), (void*)NULL", or
>simply "free(ptr), (void*)0", which would avoid the implementation
>dependency. I took this as a suggestion of style, rather than implying
>that it was necessary. The fact that "p=0" implicitly converts 0 to 'p's
>type, and is the value of the assignment expression, is a little too
>subtle for Jak, and I can see his point.

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.

>>>> This has nothing to do with that. Tim's code was correct and
>>>> portable.
>>>
>>> Tim's comment about an implementation dependency was written about code
>>> written by Kaz Kylheku. That code does indeed have an implementation
>>> dependency. Depending upon which choice an implementation makes for the
>>> null pointer constant that NULL expands into, Kaz's code might or might
>>> not contain a constraint violation.
>>
>> That was not what I was referring to; see above and please note
>> the exact words I responded to (specifically the post that
>> referred to "autocast").
>
>Jak's comment using the phrase "autocast" was not referring to any
>implementation dependency in Tim's code, only to the same implementation
>dependency in Kaz's code that Tim himself was talking about.

Why don't we let him speak for himself?

- Dan C.

In article <u11c9m$27m86$3@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:58, Spiros Bousbouras wrote:
>> On Mon, 10 Apr 2023 11:34:54 -0400
>> James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>...
>>> The comment about "implementation dependency" was written by Tim, jak
>>> was merely referring to that comment.
>>
>> Yes , but which piece of code was jak referring to ? For easy reference lets
>> call Code A
>>
>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>
>> which posted by Kaz in <20230407042121.909@kylheku.com> and Code B
>>
>> void *
>> realloc0( void *p, size_t size ){
>> return size == 0 ? free( p ), p = 0 : realloc( p, size );
>> }
>>
>> which was posted by Tim in <86r0st3zj0.fsf@linuxsc.com> .So when jak said
>> "If you absolutely wanted to avoid dependency" which of the 2 code excerpts
>> was he referring to ? I took it to mean that he was referring to Code B and I
>> think Dan took it to mean the same. Code B does not have any "implementation
>> dependency" , it just relies on the C standard. In contrast , Code A may have
>> a constraint violation depending on how the implementation defines NULL , as
>> Tim pointed out.
>
>I took jak as referring to both code A and code B. He was saying that
>code A has an implementation dependency, while code B did not, but that
>he would prefer a different way of modifying code A to avoid that
>dependency. I understood him to be expressing a stylistic preference,
>not something required in order for the code to be correct.

Instead of assuming, you should simply ask him.

- Dan C.

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?

In article <u11c1o$27m86$2@dont-email.me>,
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>On 4/10/23 11:35, Dan Cross wrote:
>>[snip]
>> I do not know why you are addressing this to me. I agreed with
>> the overall analysis and don't think I posted anything to the
>> contrary.
>>
>> Perhaps you meant to respond to someone else?
>
>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.

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.

- Dan C.

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.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On Monday, 10 April 2023 at 17:10:19 UTC+1, jak wrote:
>> James Kuyper ha scritto:
>> > On 4/10/23 11:29, jak wrote:
>> > ...
>> >> char val;
>> >> int *pi;
>> >>
>> >> pi = (int *)&val;
>> >>
>> >> because if you assigned a value to *pi you would be using unallocated
>> >> memory
>> >
>> > The problem with that code has nothing to do with the problem Tim was
>> > talking about, nor does it have anything to do with unallocated memory.
>> > It has undefined behavior if &val points to a memory location that is
>> > not correctly aligned to hold an 'int' (6.3.2.3p7). More importantly,
>> > even if it is correctly aligned, the value stored in pi cannot be used
>> > to access an 'int', because it doesn't point at an int object.
>> >
>> >> ... and if you really want to do that you need a left cast:
>> >>
>> >> ((char *)pi) = &val;
>> >
>> > The left hand side of an assignment is required to be a modifiable
>> > lvalue (6.5.16p2). The result of a pointer conversion is not an lvalue.
>> >
>> hmmm... in my point of view declaring a variable corresponds to
>> allocating memory while using malloc means allocating memory
>> dynamically. For me it is not easy to express concepts in your language
>> and in addition you continue to take me back on the quibbles. Maybe we
>> can talk again when I improve my English and you're less picky.
>>
> In a sense that is right. But generally the term "allocating" isn't used for
> variables created on the stack, unless maybe for large arrays.
> The reason is that the stack works by magic. Within the confines of the
> C language, there is no way to express that the stack might fail, though
> of course it must do so eventually if allowed to get arbitrarily deep.

In fact the word "allocate" and various forms of it *are* commonly used
by the standard to refer to "variables created on the stack" (more
technically, objects with automatic storage duration).

One example (which happens to be one of the earliest references in the
text of the standard):

An *array type* describes a contiguously allocated nonempty set of
objects with a particular member object type, called the *element
type*.

This refers to array objects in general, not just heap-allocated array
objects.

The fact that one of the four storage durations is called "allocated",
while the word "allocate" is used to refer to reserving memory in other
contexts, is potentially confusing, but I haven't found it to be much of
a problem.

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