realloc zero bytes?

[Guest]

... snip ... [un-snip start]

David R Tribble wrote:
As a side issue, is an implementation allowed to return
the same value (besides NULL) for all malloc(0) calls? [un-snip end]

No; the spec says that at least one byte will be
actually allocated, and there is some general statement
that no two active heap allocations will overlap.

No.
7.20.3 p1 (n1124 or N869)
If the size of the space requested is zero, the behavior is
implementation-defined: either a null pointer is returned, or the
behavior is as if the size were some nonzero value, except that
the returned pointer shall not be used to access an object.

Did you even read the previous message before responding?

Yes. You stated that at least one byte would be allocated. I
disputed that.

He stated that at least one byte would be allocated if the result is
not NULL, which is correct.

 

[CBFalconer]

He stated that at least one byte would be allocated if the
result is not NULL, which is correct.

Pedantically, no. However we are arguing over the density of
angels on pinheads, which is not productive.

 

[Douglas A. Gwyn]

Pedantically, no. However we are arguing over the density of
angels on pinheads, which is not productive.

Actually, yes -- it was so stipulated in the portion that you
snipped out.

 

[Jun Woong]

[Reposting, previous post got out too soon]

It seems to me that this causes massive problems for people wishing to
write libraries that conform both to C90 and to C99. (...)

Well, not all that massive in this case. I should have said "once you
have done realloc without checking the arguments, you can handle it like
this". It does get cumbersome if you want the assignment to be a
separate statement though.

Otherwise:
if (!(size && (newobj = realloc(oldobj, size)))) {
free(oldobj);
return;
}

Those two examples given above do not have the same behavior, which
probably was intended; on an implementation where malloc(0) returns
a non-null pointer the former passes through without returning while
the latter returns after an explicit call to free. Furthermore,
strictly speaking, the former is not strictly conforming to C90.


--
Jun, Woong (woong at icu.ac.kr)
Samsung Electronics Co., Ltd.

``All opinions expressed are mine, and do not represent
the official opinions of any organization.''

 

[Hallvard B Furuseth]

Those two examples given above do not have the same behavior, which
probably was intended; (...)

No, I didn't really think of that. Just the simplest way to deal with
realloc(,0) after and before the call.

Furthermore, strictly speaking, the former is not strictly conforming
to C90.

Shrug. If we are going to be that paranoid about constants like
__STDC_VERSION__ or __cplusplus, it'd be no use to introduce them at all.

 

[Jun Woong]

Jun Woong writes: [...]

Those two examples given above do not have the same behavior, which
probably was intended; (...)

No, I didn't really think of that. Just the simplest way to deal with
realloc(,0) after and before the call.

Yes, the difference really originates from a point of time when a
call to realloc with the size 0 is handled.

Shrug. If we are going to be that paranoid about constants like
__STDC_VERSION__ or __cplusplus, it'd be no use to introduce them at all.

It would never cause a problem in practice. But this is comp.std.c;
I meant pedanticism with "strictly speaking."


--
Jun, Woong (woong at icu.ac.kr)
Samsung Electronics Co., Ltd.

``All opinions expressed are mine, and do not represent
the official opinions of any organization.''

 

[Keith Thompson]

It would never cause a problem in practice. But this is comp.std.c;
I meant pedanticism with "strictly speaking."

Surely you mean "pedantry" rather than "pedanticism".

}

 

[Jun Woong]

Surely you mean "pedantry" rather than "pedanticism".

<OT>

My Korean-English dictionary says that they refer to the same
meaning. Is there any (subtle?) difference I didn't recognize?

</OT>


--
Jun, Woong (woong at icu.ac.kr)
Samsung Electronics Co., Ltd.

``All opinions expressed are mine, and do not represent
the official opinions of any organization.''

 

[Keith Thompson]

<OT>

My Korean-English dictionary says that they refer to the same
meaning. Is there any (subtle?) difference I didn't recognize?

I think they probably mean the same thing. I was more interested in
making a joke than in strict accuracy.

 

[CBFalconer]

[...]
It would never cause a problem in practice. But this is comp.std.c;
I meant pedanticism with "strictly speaking."

Surely you mean "pedantry" rather than "pedanticism".

My Korean-English dictionary says that they refer to the same
meaning. Is there any (subtle?) difference I didn't recognize?

I think they probably mean the same thing. I was more interested
in making a joke than in strict accuracy.

I think they are subtly different, but I can't quite put my finger
on it. To me, pedantry implies use, while pedanticism implies
adherence to the practice.

"He indulged in pedantry in his reply"
vs
"He is a confirmed pedanticist" or "He practices pedanticism"

Added cross-post to alt.usage.english

 

[Jun Woong]

Keith Thompson wrote:
[...]
It would never cause a problem in practice. But this is comp.std.c;
I meant pedanticism with "strictly speaking."

Surely you mean "pedantry" rather than "pedanticism".

My Korean-English dictionary says that they refer to the same
meaning. Is there any (subtle?) difference I didn't recognize?

I think they probably mean the same thing. I was more interested
in making a joke than in strict accuracy.

I think they are subtly different, but I can't quite put my finger
on it. To me, pedantry implies use, while pedanticism implies
adherence to the practice.

"He indulged in pedantry in his reply"
vs
"He is a confirmed pedanticist" or "He practices pedanticism"

Oh, then, as Keith pointed out, "pedanticism" in my post should read
as "pedantry." ;-)


--
Jun, Woong (woong at icu.ac.kr)
Samsung Electronics Co., Ltd.

``All opinions expressed are mine, and do not represent
the official opinions of any organization.''

 

[Richard Heathfield]

Keith Thompson said:

Surely you mean "pedantry" rather than "pedanticism".

Your spelling is fine, but your pronunciation is incorrect.

 

[David R Tribble]

No; the spec says that at least one byte will be
actually allocated, and there is some general statement
that no two active heap allocations will overlap.

I didn't think so.

Another side issue. 7.20.3 says:
The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object [A]
and then used to access such an object or an array of such objects
in the space allocated

I assume we could insert at [A] the phrase:
having a size not greater than the allocated space

In other words, if I malloc two bytes, I can't expect that I can store
"any type of object" in the space (such as a 4-byte float). Nor should
I expect that the space allocated is "suitably aligned" for any object
type larger than two bytes, right?

-drt

 

[Wojtek Lerch]

In other words, if I malloc two bytes, I can't expect that I can store
"any type of object" in the space (such as a 4-byte float). Nor should
I expect that the space allocated is "suitably aligned" for any object
type larger than two bytes, right?

No, I think the standard does promise that this is defined:

float *foo = malloc( 1 );

 

[Mike Lyle]

Keith Thompson wrote:
[...]
It would never cause a problem in practice. But this is
comp.std.c; I meant pedanticism with "strictly speaking."

Surely you mean "pedantry" rather than "pedanticism".

My Korean-English dictionary says that they refer to the same
meaning. Is there any (subtle?) difference I didn't recognize?

I think they probably mean the same thing. I was more interested
in making a joke than in strict accuracy.

I think they are subtly different, but I can't quite put my finger
on it. To me, pedantry implies use, while pedanticism implies
adherence to the practice.

"He indulged in pedantry in his reply"
vs
"He is a confirmed pedanticist" or "He practices pedanticism"

Oh, then, as Keith pointed out, "pedanticism" in my post should read
as "pedantry." ;-)

I find that OED doesn't make CBF's distinction, and its most recent
example of "pedanticism" came from Roy Jenkins. Even if that in itself
isn't enough to recommend using "pedantry" instead, I think the word is
a syllable too far. I suppose we could support the term for something
like "holding to pedantry as a way of life", but I'd want to see some
credible examples.

 

[Clark S. Cox III]

No; the spec says that at least one byte will be
actually allocated, and there is some general statement
that no two active heap allocations will overlap.

I didn't think so.

Another side issue. 7.20.3 says:
The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object [A]
and then used to access such an object or an array of such objects
in the space allocated

I assume we could insert at [A] the phrase:
having a size not greater than the allocated space

Why make such an assumption; it is counter to what the standard already
says.

In other words, if I malloc two bytes, I can't expect that I can store
"any type of object" in the space (such as a 4-byte float). Nor should
I expect that the space allocated is "suitably aligned" for any object
type larger than two bytes, right?

AIUI, the alignment is absolute. If malloc returns a non-NULL pointer,
it is aligned suitably for *any* type, period. I see nothing undefined
about:

double *d = malloc(1);

Of course, if sizeof(double) is greater than 1, then dereferencing or
incrementing d would be undefined.

 

[Douglas A. Gwyn]

Another side issue. 7.20.3 says:
The pointer returned if the allocation succeeds is suitably aligned
so that it may be assigned to a pointer to any type of object [A]
and then used to access such an object or an array of such objects
in the space allocated
I assume we could insert at [A] the phrase:
having a size not greater than the allocated space

That's a different requirement. The intent is to have the same
more-stringent alignment requirement even for pointers to tiny
allocations (which would be a natural property of most malloc
implementations anyway).

Of course the "any type ... and then used to access" is meant
to be subject to the requirement that the accessed object
representation lie entirely within the array of bytes
allocated (which cannot be assumed to be more than the size
requested). That probably falls out of generic requirements
elsewhere in the standard.

 

[Richard Tobin]

AIUI, the alignment is absolute. If malloc returns a non-NULL pointer,
it is aligned suitably for *any* type, period. I see nothing undefined
about:

double *d = malloc(1);

Of course, if sizeof(double) is greater than 1, then dereferencing or
incrementing d would be undefined.

But if sizeof(double) is greater than one, how can you observe whether
or not the address is adequately aligned for a double? All conforming
programs work even if the alignment is wrong.

-- Richard

 

[Ben Pfaff]

But if sizeof(double) is greater than one, how can you observe whether
or not the address is adequately aligned for a double? All conforming
programs work even if the alignment is wrong.

Converting to a pointer type for which the pointer value is
misaligned yields undefined behavior in itself. See C99 6.3.2.3:

A pointer to an object or incomplete type may be converted
to a pointer to a different object or incomplete type. If
the resulting pointer is not correctly aligned57) for the
pointed-to type, the behavior is undefined.

Thus, "double *d = malloc(1);" is well-defined, but "char c;
double d = &c;" is not.

 

[Richard Tobin]

But if sizeof(double) is greater than one, how can you observe whether
or not the address is adequately aligned for a double? All conforming
programs work even if the alignment is wrong.

[/QUOTE]

Converting to a pointer type for which the pointer value is
misaligned yields undefined behavior in itself.

On a system where that in fact generates an error, malloc(1) could not
returned an insufficiently aligned address. But on a system where
that is not the case, malloc(1) *is* sufficiently aligned for all the
things you can legally do with it. That is, these systems behave *as
if* malloc(1) was sufficiently aligned for a double.

-- Richard