realloc zero bytes?

[Ben Pfaff]

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.[/QUOTE]

I don't think that contradicts anything I said, although it does
clarify it.

 

[Keith Thompson]

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.[/QUOTE]

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.

 

[Douglas A. Gwyn]

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.

 

[Keith Thompson]

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.

 

[Flash Gordon]

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

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"? ;-)