By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,131 Members | 1,425 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,131 IT Pros & Developers. It's quick & easy.

realloc zero bytes?

P: n/a

The C standard doesn't say anything about what happens when you call
realloc with a size argument of 0. Both glibc and openbsd appear to
return a valid pointer to a zero-sized object.. e.g. the return of a
malloc(0).

Does anyone know of a runtime where realloc() free'ed the object and
then returned NULL? If so, it would make the following idiom for
realloc() exploitable. Here's the idiom, snagged from an openbsd man page:

if ((p2 = realloc(p, nsize)) == NULL) {
if (p)
free(p);
p = NULL;
return NULL;
}
p = p2;

You can see that if nsize is 0 and realloc() free'ed the memory and
returned NULL, it would be a double-free of p.

Thanks,
rCs
Jan 9 '07
Share this Question
Share on Google+
64 Replies


P: n/a

CBFalconer wrote:
Keith Thompson wrote:
"Jun Woong" <wo***@icu.ac.krwrites:
Keith Thompson wrote:
"Jun Woong" <wo***@icu.ac.krwrites:
[...]
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.''

Jan 19 '07 #51

P: n/a
Keith Thompson said:
"Jun Woong" <wo***@icu.ac.krwrites:
[...]
>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".
Your spelling is fine, but your pronunciation is incorrect.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Jan 19 '07 #52

P: n/a
David R Tribble wrote:
>As a side issue, is an implementation allowed to return
the same value (besides NULL) for all malloc(0) calls?
Douglas A. Gwyn wrote:
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

Jan 19 '07 #53

P: n/a
"David R Tribble" <da***@tribble.comwrote in message
news:11**********************@11g2000cwr.googlegro ups.com...
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 );

Jan 19 '07 #54

P: n/a
David R Tribble wrote:
David R Tribble wrote:
>>As a side issue, is an implementation allowed to return
the same value (besides NULL) for all malloc(0) calls?

Douglas A. Gwyn wrote:
>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.

--
Clark S. Cox III
cl*******@gmail.com
Jan 19 '07 #55

P: n/a
In article <12*************@corp.supernews.com>,
Clark S. Cox III <cl*******@gmail.comwrote:
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 19 '07 #56

P: n/a
David R Tribble wrote:
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.
Jan 19 '07 #57

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <12*************@corp.supernews.com>,
Clark S. Cox III <cl*******@gmail.comwrote:
>>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.
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.
--
Ben Pfaff
bl*@cs.stanford.edu
http://benpfaff.org
Jan 19 '07 #58

P: n/a
In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:
>>>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.
>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 19 '07 #59

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:
>>>>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.
>>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.
I don't think that contradicts anything I said, although it does
clarify it.
--
Here's a tip: null pointers don't have to be *dull* pointers!
Jan 19 '07 #60

P: n/a
ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:
In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:
>>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.
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.
I think I agree.

Suppose sizeof(double)==8, and double requires 8-byte alignment. But
suppose that converting a misaligned char* pointer to double* (which
invokes undefined behavior) simply copies the bit pattern, and never
causes anything "bad" to happen. In other words, attempting to access
a misaligned double object can crash your program, but constructing a
misaligned pointer to double cannot. (These are assumptions about a
particular hypothetical implementation.)

Then the standard's definition of malloc() explicitly requires
double *ptr = malloc(1);
(assuming it succeeds) to set ptr to a value that's properly aligned
(i.e., 8-byte aligned) for type double -- but there's no way for a
portable program to detect a violation of this requirement. So I
think the "as if" rule applies.

If a tree is misaligned in a forest and nobody can access it, does it
invoke undefined behavior?

Note that if the result of malloc(1) is misaligned, then
realloc(ptr, sizeof(double))
will not be able to expand the allocated space in place; it must
allocate a *new* properly aligned 8-byte block. This doesn't argue
that malloc(1) can't yield a misaligned pointer, merely that the
implementation must take some extra care if it does so.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 20 '07 #61

P: n/a
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
Suppose sizeof(double)==8, and double requires 8-byte alignment. But
suppose that converting a misaligned char* pointer to double* (which
invokes undefined behavior) simply copies the bit pattern, and never
causes anything "bad" to happen. In other words, attempting to access
a misaligned double object can crash your program, but constructing a
misaligned pointer to double cannot. (These are assumptions about a
particular hypothetical implementation.)
Well, if you assume nothing can go wrong then of course you can
conclude that nothing can go wrong. However, a not-strictly-
conforming program could inspect the returned address in an
implementation-dependent way and still determine that it has
improper alignment, taking a branch that a conforming
implementation must not allow to happen.

The requirements on a conforming implementation are not limited
to compilation of s.c. programs.
Jan 20 '07 #62

P: n/a
"Douglas A. Gwyn" <DA****@null.netwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
Suppose sizeof(double)==8, and double requires 8-byte alignment. But
suppose that converting a misaligned char* pointer to double* (which
invokes undefined behavior) simply copies the bit pattern, and never
causes anything "bad" to happen. In other words, attempting to access
a misaligned double object can crash your program, but constructing a
misaligned pointer to double cannot. (These are assumptions about a
particular hypothetical implementation.)

Well, if you assume nothing can go wrong then of course you can
conclude that nothing can go wrong. However, a not-strictly-
conforming program could inspect the returned address in an
implementation-dependent way and still determine that it has
improper alignment, taking a branch that a conforming
implementation must not allow to happen.

The requirements on a conforming implementation are not limited
to compilation of s.c. programs.
Um, where did I mention strictly conforming programs?

Any code that examines a pointer value and determines whether it's
properly aligned must depend on (at least) implementation-defined
behavior. For example, it might convert the pointer value to an
integer type and examine the low-order bits, or convert it to a string
using sprintf("%p", ptr); both conversions are implementation-defined.

But I don't see anything that requires an implementation to define
these conversions in a way that allows a program to determine the
pointer value's alignment. I can imagine an implementation in which
malloc(1) returns a misaligned pointer, but no program, using the
standard and the implementation's required documentation, can prove
this.

Before we get too far into this, let me say that *this* particular
issue is, in my opinion, no big deal. I think there's a requirement
in the standard that can, for some implementations, be violated more
or less undetectably. It's an interesting theoretical tidbit, but I
don't think there are any significant consequences.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Jan 20 '07 #63

P: n/a
Jun Woong wrote:
CBFalconer wrote:
>Keith Thompson wrote:
>>"Jun Woong" <wo***@icu.ac.krwrites:
Keith Thompson wrote:
"Jun Woong" <wo***@icu.ac.krwrites:
[...]
>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.

--
Mike.

--
Posted via a free Usenet account from http://www.teranews.com

Jan 22 '07 #64

P: n/a
Mike Lyle wrote, On 19/01/07 17:57:

<snip>
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.
How about "the regulars of comp.lang.c believe in pedanticism"? ;-)
--
Flash Gordon
Jan 22 '07 #65

64 Replies

This discussion thread is closed

Replies have been disabled for this discussion.