Kaz Kylheku <864-117-4973@kylheku.com> writes:

[miscellaneous suggestions taken out]

> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>
>> void *realloc0 ( void *ptr, size_t size ) {
>> void *reptr = NULL;
>> if ( size < 1 ) {
>> if ( ptr != NULL ) free(ptr); }
>> else reptr = realloc(ptr,size);
>> return ( reptr ); }
>
> Consider:
>
> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>
> which avoids multiple returns, variable assignment, and
> verbiage.

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.

(Some people may prefer writing 'p = NULL' after the call to
free(); my preference in this case is to write 'p = 0', as
shown. But that question is orthogonal to the main point about
avoiding the potential compilation error.)

Tim Rentsch ha scritto:
> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [miscellaneous suggestions taken out]
>
>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>
>>> void *realloc0 ( void *ptr, size_t size ) {
>>> void *reptr = NULL;
>>> if ( size < 1 ) {
>>> if ( ptr != NULL ) free(ptr); }
>>> else reptr = realloc(ptr,size);
>>> return ( reptr ); }
>>
>> Consider:
>>
>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>
>> which avoids multiple returns, variable assignment, and
>> verbiage.
>
> 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.

>
> (Some people may prefer writing 'p = NULL' after the call to
> free(); my preference in this case is to write 'p = 0', as
> shown. But that question is orthogonal to the main point about
> avoiding the potential compilation error.)
>

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>
> [miscellaneous suggestions taken out]
>
>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>
>>> void *realloc0 ( void *ptr, size_t size ) {
>>> void *reptr = NULL;
>>> if ( size < 1 ) {
>>> if ( ptr != NULL ) free(ptr); }
>>> else reptr = realloc(ptr,size);
>>> return ( reptr ); }
>>
>> Consider:
>>
>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>
>> which avoids multiple returns, variable assignment, and
>> verbiage.
>
> 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).

I'm not sure what you mean. "Can result in an error" sounds a bit
vague. I know from

> ... the main point about
> avoiding the potential compilation error ...

that you mean a compilation error, but that's not a standard term.

--
Ben.

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?

- Dan C.

In article <86v8i54yk5.fsf@linuxsc.com>,
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>I think you misunderstood my comment. I didn't mean to say
>anything about what the authors say about the evolution of
>realloc(). I meant only that the code they gave works just fine
>(not counting the problem when 'sizeof (int) == 1' that Ben B
>pointed out) -- importantly, under the assumptions that the
>authors explicitly stated -- and that they didn't say anything
>about whether the code is portable or well-defined if considered
>outside of those assumptions. The authors may have some opinions
>about whether the code /should/ work in general, but they don't
>make any claims about whether it /does/ work in general, and that
>point is the only one I mean to address.

No, I understood that, but I disagree: I believe that they were
trying to make a more general statement, beyond simply the
circumstances they outlined.

Of course, without asking them, it's difficult to be certain.

- Dan C.

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.

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

> Tim Rentsch ha scritto:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [miscellaneous suggestions taken out]
>>
>>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>>
>>>> void *realloc0 ( void *ptr, size_t size ) {
>>>> void *reptr = NULL;
>>>> if ( size < 1 ) {
>>>> if ( ptr != NULL ) free(ptr); }
>>>> else reptr = realloc(ptr,size);
>>>> return ( reptr ); }
>>>
>>> Consider:
>>>
>>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>>
>>> which avoids multiple returns, variable assignment, and
>>> verbiage.
>>
>> 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.

The re-written code doesn't have any implementation dependency:
it is guaranteed to work in all versions of C back to ANSI C and
even K&R C (except of course K&R C doesn't have void or void *,
(or size_t?) but the conversion of 0 to any pointer type will
work even back in K&R C).

Furthermore writing an explicit cast is almost always a bad idea,
especially in open code. Writing the expression without a cast
gives the compiler a chance to say that the code is wrong, if
indeed wrong it is. No diagnostics plus no use of any symbols
such as NULL that are implementation-defined means the code will
compile successfully everywhere.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>
>> [miscellaneous suggestions taken out]
>>
>>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>>
>>>> void *realloc0 ( void *ptr, size_t size ) {
>>>> void *reptr = NULL;
>>>> if ( size < 1 ) {
>>>> if ( ptr != NULL ) free(ptr); }
>>>> else reptr = realloc(ptr,size);
>>>> return ( reptr ); }
>>>
>>> Consider:
>>>
>>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>>
>>> which avoids multiple returns, variable assignment, and
>>> verbiage.
>>
>> 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).
>
> I'm not sure what you mean. "Can result in an error" sounds a bit
> vague. I know from
>
>> ... the main point about
>> avoiding the potential compilation error ...
>
> that you mean a compilation error, but that's not a standard term.

If NULL is #define'd to be 0, then a diagnostic is required. The
problem can be seen by attempting to compile this version:

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

The presence of a required diagnostic means the compilation can
fail, without needing any other cause. Of course that doesn't
mean a compilation must fail, but it can fail, and will fail
if for example -Werror was used. Does that clarify what I was
trying to get at?

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>
>>> [miscellaneous suggestions taken out]
>>>
>>>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>>>
>>>>> void *realloc0 ( void *ptr, size_t size ) {
>>>>> void *reptr = NULL;
>>>>> if ( size < 1 ) {
>>>>> if ( ptr != NULL ) free(ptr); }
>>>>> else reptr = realloc(ptr,size);
>>>>> return ( reptr ); }
>>>>
>>>> Consider:
>>>>
>>>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>>>
>>>> which avoids multiple returns, variable assignment, and
>>>> verbiage.
>>>
>>> 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).
>>
>> I'm not sure what you mean. "Can result in an error" sounds a bit
>> vague. I know from
>>
>>> ... the main point about
>>> avoiding the potential compilation error ...
>>
>> that you mean a compilation error, but that's not a standard term.
>
> If NULL is #define'd to be 0, then a diagnostic is required. The
> problem can be seen by attempting to compile this version:
>
> void *
> realloc0( void *p, size_t size ){
> return size == 0 ? free( p ), 0 : realloc( p, size );
> }
>
> The presence of a required diagnostic means the compilation can
> fail, without needing any other cause. Of course that doesn't
> mean a compilation must fail, but it can fail, and will fail
> if for example -Werror was used. Does that clarify what I was
> trying to get at?

Yes, thanks. I thought you mean that, but I was not sure. I prefer to
be more explicit and say that such and such violates a constraint, but I
can see some advantage in using more colloquial terms.

--
Ben.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>> [miscellaneous suggestions taken out]
>>>>
>>>>> On 2023-04-06, John Forkosh <forkosh@panix.com> wrote:
>>>>>
>>>>>> void *realloc0 ( void *ptr, size_t size ) {
>>>>>> void *reptr = NULL;
>>>>>> if ( size < 1 ) {
>>>>>> if ( ptr != NULL ) free(ptr); }
>>>>>> else reptr = realloc(ptr,size);
>>>>>> return ( reptr ); }
>>>>>
>>>>> Consider:
>>>>>
>>>>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size);
>>>>>
>>>>> which avoids multiple returns, variable assignment, and
>>>>> verbiage.
>>>>
>>>> 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).
>>>
>>> I'm not sure what you mean. "Can result in an error" sounds a bit
>>> vague. I know from
>>>
>>>> ... the main point about
>>>> avoiding the potential compilation error ...
>>>
>>> that you mean a compilation error, but that's not a standard term.
>>
>> If NULL is #define'd to be 0, then a diagnostic is required. The
>> problem can be seen by attempting to compile this version:
>>
>> void *
>> realloc0( void *p, size_t size ){
>> return size == 0 ? free( p ), 0 : realloc( p, size );
>> }
>>
>> The presence of a required diagnostic means the compilation can
>> fail, without needing any other cause. Of course that doesn't
>> mean a compilation must fail, but it can fail, and will fail
>> if for example -Werror was used. Does that clarify what I was
>> trying to get at?
>
> Yes, thanks. I thought you mean that, but I was not sure. I
> prefer to be more explicit and say that such and such violates a
> constraint, but I can see some advantage in using more colloquial
> terms.

It is often the case that I feel a tension between using formal
phrasing as it is used in the C standard, and informal phrasing
more like common English usage. Personally I think either can be
appropriate, depending on the particular issue being discussed and
on the expected audience. I must admit, however, that frequently
I get push back from one side or the other, carrying at least an
implicit suggestion that I made a bad choice. For the most part I
simply accept these comments as part of the price for trying to
make a reasonable decision in the face of incomplete information
(while still allowing for the possibility that my decisions in the
future may be altered). When reading comments made by other
people, I always try to understand what perspective they are
taking, and adjust my verbal processing accordingly; it is only
when I can't find a way of understanding their comments that I
want to bring it up. What is that aphorism? "Assume that what
they are saying makes sense, and try to find a way of looking at
it so that it's sensible, to understand what they meant." Or
something like that.

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.

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?
>
> - Dan C.
>
Why are you asking me this? Perhaps you consider being portability if
you move the source code to another machine with the same operating
system, same compiler, same compiler version.

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 C standard is a semi-formal document, and defines the meanings of
many terms used in that document, meanings that are almost always at
least subtly (and often not so subtly) different from the normal meaning
of the English words that they are built from. The meanings defined by
the standard are the ones that apply when interpreting what the standard
means. It is correspondingly important to know what those meanings are.

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.

"Several operators convert operand values from one type to another
automatically. This subclause specifies the result required from such an
implicit conversion, as well as those that result from a cast
operation (an explicit conversion)." (6.3p1)

The terms "implicit conversion" and "explicit conversion" are both
italicized in the actual standard, which is an ISO convention indicating
that the sentence in which they occur is the official definition of what
those terms mean.

Implicit conversions occur in the following contexts:

The integer promotions (6.3.1.1p2).
The usual arithmetic conversions (6.3.1.8p1).

An lvalue of array type is implicitly converted into a pointer to the
first element of that array in many contexts (6.3.2p3). This is done as
a convenience, but has led many people to confuse arrays with pointers.

A function designator is implicitly converted into a pointer to the
designated function in many contexts (6.3.2p4).

The default argument promotions (6.5.2.2p6).

Simple assignment (6.5.16.1p2).

As-if by assignment:
Arguments of function declared with a prototype. (6.5.2.2p7, 6.9.1p10)
Return expression. (6.8.6.4p3)

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.

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 C standard is a semi-formal document, and defines the meanings of
> many terms used in that document, meanings that are almost always at
> least subtly (and often not so subtly) different from the normal meaning
> of the English words that they are built from. The meanings defined by
> the standard are the ones that apply when interpreting what the standard
> means. It is correspondingly important to know what those meanings are.
>
> 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.
>
> "Several operators convert operand values from one type to another
> automatically. This subclause specifies the result required from such an
> implicit conversion, as well as those that result from a cast
> operation (an explicit conversion)." (6.3p1)
>
> The terms "implicit conversion" and "explicit conversion" are both
> italicized in the actual standard, which is an ISO convention indicating
> that the sentence in which they occur is the official definition of what
> those terms mean.
>
> Implicit conversions occur in the following contexts:
>
> The integer promotions (6.3.1.1p2).
> The usual arithmetic conversions (6.3.1.8p1).
>
> An lvalue of array type is implicitly converted into a pointer to the
> first element of that array in many contexts (6.3.2p3). This is done as
> a convenience, but has led many people to confuse arrays with pointers.
>
> A function designator is implicitly converted into a pointer to the
> designated function in many contexts (6.3.2p4).
>
> The default argument promotions (6.5.2.2p6).
>
> Simple assignment (6.5.16.1p2).
>
> As-if by assignment:
> Arguments of function declared with a prototype. (6.5.2.2p7, 6.9.1p10)
> Return expression. (6.8.6.4p3)
>
>
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 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.

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.

- Dan C.

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.

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

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.

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.

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;

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.

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

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?

- Dan C.

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

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

- Dan C.