473,385 Members | 1,357 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,385 software developers and data experts.

justification check

Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.

--
vir

Nov 14 '05 #1
19 2290
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.


You can't check alignment (which I assume you mean by "justification")
portably. This is one of the impediments to writing the *alloc family
in standard C. You may be able to use standard C constructs to test
alignment on a particular platform, perhaps by converting the retured
pointer to an integer type and testing divisibility (with the modulus
operator or a bitmask).

#include <stdio.h>

int aligned(void *p, int boundary) {
return !((long)p % boundary);
}
int main() {
double d;
char c;
int x;
void *pointers[] = {&d, &c, &x, 0}, **p = pointers;
int alignments[] = {32, 16, 8, 4, 2, 0}, *i;

for (; *p; p++)
for (i = alignments; *i; i++)
printf("%p is %saligned on a %d-byte boundary\n",
*p, (aligned(*p, *i) ? "" : "not "), *i);
return 0;
}

Of course, you only need to check that the pointer returned by your
implementation of malloc is correctly aligned for /any/ type, i.e. it
must satisfy most stringent alignment requirements on the target
platform.

Jeremy.
Nov 14 '05 #2
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.


You can't check alignment (which I assume you mean by "justification")
portably. This is one of the impediments to writing the *alloc family
in standard C. You may be able to use standard C constructs to test
alignment on a particular platform, perhaps by converting the retured
pointer to an integer type and testing divisibility (with the modulus
operator or a bitmask).

#include <stdio.h>

int aligned(void *p, int boundary) {
return !((long)p % boundary);
}
int main() {
double d;
char c;
int x;
void *pointers[] = {&d, &c, &x, 0}, **p = pointers;
int alignments[] = {32, 16, 8, 4, 2, 0}, *i;

for (; *p; p++)
for (i = alignments; *i; i++)
printf("%p is %saligned on a %d-byte boundary\n",
*p, (aligned(*p, *i) ? "" : "not "), *i);
return 0;
}

Of course, you only need to check that the pointer returned by your
implementation of malloc is correctly aligned for /any/ type, i.e. it
must satisfy most stringent alignment requirements on the target
platform.

Jeremy.
Nov 14 '05 #3
"Victor Nazarov" <vv*****@mail.ru> wrote in message

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.

Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};

struct control
{
struct control *next;
struct control *prev;
size_t len;
};

union block
{
union alltypes aligner;
struct control controldata;
};
Nov 14 '05 #4
"Victor Nazarov" <vv*****@mail.ru> wrote in message

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.

Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};

struct control
{
struct control *next;
struct control *prev;
size_t len;
};

union block
{
union alltypes aligner;
struct control controldata;
};
Nov 14 '05 #5

On Mon, 5 Apr 2004, Malcolm wrote:

"Victor Nazarov" <vv*****@mail.ru> wrote in message

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.


Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};


The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types. For
all you know, the DS9000 requires 1024-byte alignment for array[42] of
double, and 1-byte alignment for all other data types. And there are
an infinity of different pointer types to check.
This is a FAQ both here and c.std.c, as far as I'm concerned. It
would be nice if C0x provided a macro MAX_ALIGNMENT or something so
that you could do this yourself, but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union alltypes'
is useful.

HTH,
-Arthur
Nov 14 '05 #6

On Mon, 5 Apr 2004, Malcolm wrote:

"Victor Nazarov" <vv*****@mail.ru> wrote in message

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.


Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};


The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types. For
all you know, the DS9000 requires 1024-byte alignment for array[42] of
double, and 1-byte alignment for all other data types. And there are
an infinity of different pointer types to check.
This is a FAQ both here and c.std.c, as far as I'm concerned. It
would be nice if C0x provided a macro MAX_ALIGNMENT or something so
that you could do this yourself, but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union alltypes'
is useful.

HTH,
-Arthur
Nov 14 '05 #7
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.


You can't check alignment (which I assume you mean by "justification")
portably. This is one of the impediments to writing the *alloc family
in standard C. You may be able to use standard C constructs to test
alignment on a particular platform, perhaps by converting the retured
pointer to an integer type and testing divisibility (with the modulus
operator or a bitmask).

[code snipped]

Let me emphasize Jeremy's point about portability. Though I'm sure
his code will work properly on most systems, I know of at least one
(Cray vector systems) on which it will fail, because pointers are not
represented in the "obvious" way. I wouldn't bet against the
existence of other architectures on which it might also fail.

Leaving aside the alignment issue, there's no good way to check that
the memory requested was actually allocated. Suppose your malloc()
has a bug that causes it to return a pointer to memory that's actually
part of some user variable. The best you can do portably is confirm
that you can read and write the allocated memory -- but the only way
to confirm that you *can't* is to invoke undefined behavior.

A large part of the reason malloc() and friends are in the standard
library is because they *can't* be implemented portably.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #8
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.


You can't check alignment (which I assume you mean by "justification")
portably. This is one of the impediments to writing the *alloc family
in standard C. You may be able to use standard C constructs to test
alignment on a particular platform, perhaps by converting the retured
pointer to an integer type and testing divisibility (with the modulus
operator or a bitmask).

[code snipped]

Let me emphasize Jeremy's point about portability. Though I'm sure
his code will work properly on most systems, I know of at least one
(Cray vector systems) on which it will fail, because pointers are not
represented in the "obvious" way. I wouldn't bet against the
existence of other architectures on which it might also fail.

Leaving aside the alignment issue, there's no good way to check that
the memory requested was actually allocated. Suppose your malloc()
has a bug that causes it to return a pointer to memory that's actually
part of some user variable. The best you can do portably is confirm
that you can read and write the allocated memory -- but the only way
to confirm that you *can't* is to invoke undefined behavior.

A large part of the reason malloc() and friends are in the standard
library is because they *can't* be implemented portably.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
Nov 14 '05 #9
Malcolm wrote:
"Victor Nazarov" <vv*****@mail.ru> wrote in message
Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.


Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};

struct control
{
struct control *next;
struct control *prev;
size_t len;
};

union block
{
union alltypes aligner;
struct control controldata;
};

This seems to be the best solution to implement memory management, but
I'd like to find out any ways to test third party memory managements
functions for right (defined in C standard) behavior.

vir

Nov 14 '05 #10
Malcolm wrote:
"Victor Nazarov" <vv*****@mail.ru> wrote in message
Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right justification
of each C type dynamically allocated.


Use a Block structure to do all your controls. In the block, add a union of
all the basic types, to force alignment.

union alltypes
{
void *x1;
long x2;

... (don't forget function pointers)
};

struct control
{
struct control *next;
struct control *prev;
size_t len;
};

union block
{
union alltypes aligner;
struct control controldata;
};

This seems to be the best solution to implement memory management, but
I'd like to find out any ways to test third party memory managements
functions for right (defined in C standard) behavior.

vir

Nov 14 '05 #11
Keith Thompson wrote:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.

Thank you for your answers. I suspected that things were just like you
had described. So I think the way out is to forget about portability and
implement everything for the particular architecture.

vir

Nov 14 '05 #12
Keith Thompson wrote:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:
Consider I want to write my own version of standard malloc, calloc,
realloc, free. How can I portably check if they work correctly? The most
remarkable will be the test for right justification of each C type
dynamicly allocated.

Thank you for your answers. I suspected that things were just like you
had described. So I think the way out is to forget about portability and
implement everything for the particular architecture.

vir

Nov 14 '05 #13
Victor Nazarov wrote:
Keith Thompson wrote:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right
justification of each C type dynamicly allocated.

Thank you for your answers. I suspected that things were just
like you had described. So I think the way out is to forget
about portability and implement everything for the particular
architecture.


The two areas that will require special system dependant attention
are alignment, and where to get the memory to dispense. If you
isolate those operations almost everything else can be quite
standard and portable code. You can find an example at:

<http://cbfalconer.home.att.net/download/nmalloc.zip>

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush
Nov 14 '05 #14
Victor Nazarov wrote:
Keith Thompson wrote:
Jeremy Yallop <je****@jdyallop.freeserve.co.uk> writes:
Victor Nazarov wrote:

Consider I want to write my own version of standard malloc,
calloc, realloc, free. How can I portably check if they work
correctly? The most remarkable will be the test for right
justification of each C type dynamicly allocated.

Thank you for your answers. I suspected that things were just
like you had described. So I think the way out is to forget
about portability and implement everything for the particular
architecture.


The two areas that will require special system dependant attention
are alignment, and where to get the memory to dispense. If you
isolate those operations almost everything else can be quite
standard and portable code. You can find an example at:

<http://cbfalconer.home.att.net/download/nmalloc.zip>

--
"I'm a war president. I make decisions here in the Oval Office
in foreign policy matters with war on my mind." - Bush
Nov 14 '05 #15

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types.
For all you know, the DS9000 requires 1024-byte alignment for
array[42] of double, and 1-byte alignment for all other data types.
I don't think this is allowed, because you can create an array of 42 doubles
from an array of 43 or higher.
And there are an infinity of different pointer types to check.
But all, except function pointers, have got to be interconvertible with void
*.
but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union
alltypes' is useful.

It may just be possible to write a conforming compiler that does so on a
perverse reading of the standard.
Nov 14 '05 #16

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types.
For all you know, the DS9000 requires 1024-byte alignment for
array[42] of double, and 1-byte alignment for all other data types.
I don't think this is allowed, because you can create an array of 42 doubles
from an array of 43 or higher.
And there are an infinity of different pointer types to check.
But all, except function pointers, have got to be interconvertible with void
*.
but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union
alltypes' is useful.

It may just be possible to write a conforming compiler that does so on a
perverse reading of the standard.
Nov 14 '05 #17

On Tue, 6 Apr 2004, Malcolm wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types.
For all you know, the DS9000 requires 1024-byte alignment for
array[42] of double, and 1-byte alignment for all other data types.


I don't think this is allowed, because you can create an array of 42
doubles from an array of 43 or higher.


Probably true. Still, C&V, please.
And there are an infinity of different pointer types to check.


But all, except function pointers, have got to be interconvertible with
void *.


Interconvertible, yes. Same size as, no. AFAICT it's perfectly
reasonable to have each pointer hold not only a memory address, but
also a representation of its type, a unique identifier, a pointer to a
reference counter, and several kilobytes of padding bits. :) IOW,
while
foo *f = (void*)&f;
void *p = (foo*)&p;
is valid, it is certainly *NOT* the case that
sizeof f == sizeof p
on all platforms.
but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union
alltypes' is useful.


It may just be possible to write a conforming compiler that does so on a
perverse reading of the standard.


I don't understand that comment. I meant, "in C99 there is no portable
way to construct a 'universal alignment' structure." What did you mean?

-Arthur

Nov 14 '05 #18

On Tue, 6 Apr 2004, Malcolm wrote:

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
The problem with this, from the c.l.c point of view, is that there's
no way you can possibly make a union of *all* the basic types.
For all you know, the DS9000 requires 1024-byte alignment for
array[42] of double, and 1-byte alignment for all other data types.


I don't think this is allowed, because you can create an array of 42
doubles from an array of 43 or higher.


Probably true. Still, C&V, please.
And there are an infinity of different pointer types to check.


But all, except function pointers, have got to be interconvertible with
void *.


Interconvertible, yes. Same size as, no. AFAICT it's perfectly
reasonable to have each pointer hold not only a memory address, but
also a representation of its type, a unique identifier, a pointer to a
reference counter, and several kilobytes of padding bits. :) IOW,
while
foo *f = (void*)&f;
void *p = (foo*)&p;
is valid, it is certainly *NOT* the case that
sizeof f == sizeof p
on all platforms.
but as of C99 you still have to make
some non-standard assumption in order to guarantee that 'union
alltypes' is useful.


It may just be possible to write a conforming compiler that does so on a
perverse reading of the standard.


I don't understand that comment. I meant, "in C99 there is no portable
way to construct a 'universal alignment' structure." What did you mean?

-Arthur

Nov 14 '05 #19

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message
It may just be possible to write a conforming compiler that does > > so
on a perverse reading of the standard.
I don't understand that comment. I meant, "in C99 there is no
portable way to construct a 'universal alignment' structure." What
did you mean?

What I mean is that you might be able to frustrate the alltypes structure by
remaining within the letter of the standard, but doing something perverse,
like making all pointers that point to a structure whose name begins A-M
have a different alignment requirement than pointers to structures beginning
N-Z.

void * may have a less strict alignment requirement than say double *,
however, so this was a mistake.
Nov 14 '05 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: crownergis | last post by:
Hello. I'm Johnny Cash. Actually I have a bit of a problem. I have a page with an inline frame. The contents of the frame are wider than the frame (and designed that way). The newest content in...
1
by: Alex | last post by:
I have looked at the code for text justification on lebans.com and this seems to work very well. Except my report is a subreport and I cannot get the code to work on a subreport. Does anyone know...
1
by: Alex | last post by:
The JustiDirect text justification on Stephen LeBans site works well but I cannot get it to work on a sub report. Could anyone tell me if this is possible. Thanks. Alex
1
by: AMD 3400 | last post by:
Hello there, i have a question to ask, i have a huge 5000 columns in Excel that i've been working on and i want it right-justified. When i open it in Access it gives me left-justified. i would...
10
by: Victor Nazarov | last post by:
Consider I want to write my own version of standard malloc, calloc, realloc, free. How can I portably check if they work correctly? The most remarkable will be the test for right justification of...
4
by: Neil | last post by:
Just found out that the Microsoft Rich Textbox does not support full text justification, since it's based on Version 1.0 of the RichEdit Window Class, and full text justification is only available...
10
by: gaetanoortisi | last post by:
Hello, can anyone point me to some piece of code that do text justification of fixed fonts like those that nroff do on manpages? Thanks, Gaetano
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.