473,406 Members | 2,867 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,406 software developers and data experts.

Trouble with malloc().

I am having trouble with malloc() again for a PC app I am developing. The
method of the suspicious line of code seems to be Ok on a embedded platform,
but not with the PC platform. The embedded platform uses a different
compiler. I feel like I'm overlooking a very simple problem, but I can't
see it. I would appreciate any help. Thank you.

I am trying to allocate memory for a structure of type NAT_S which contains
a pointer to a structure of type NAT_ENTRY_S (see code below).

The compiler reports warning 'Suspicious pointer conversion' as indicated
below in the code. This is the only warning or error I get.

This code appears to work but the next call to malloc() following this, the
app crashes. In some instances, ReadNat() is not called and the app works
Ok. So the problem points to within ReadNat(), which is where the warning
is.

I examined/watched the address given to 'nat' and 'nat->entries' and they
are different by 24 bytes when they should be different by 6. The sizeof(
NAT_S ) is 6.

/************************************************** **********/
typedef struct
{
short a;
short b;
long c;
long d;
} NAT_ENTRY_S;

typedef struct
{
short num_entries;
NAT_ENTRY_S *entries;
} NAT_S;

NAT_S *ReadNat( FILE *file, long offset )
{
NAT_S *nat;
short i, num_entries;

fseek( file, offset, SEEK_SET );
num_entries = ReadShort( file );

if( (nat = malloc( sizeof( NAT_S ) + (num_entries * sizeof(
NAT_ENTRY_S )) )) != NULL )
{
nat->num_entries = num_entries;
nat->entries = nat + sizeof( NAT_S ); /* COMPILER WARNING:
Suspicious pointer conversion */

for( i = 0; i < num_entries; i++ )
{
/* load entries here */
}
}

return ifd;
}
/************************************************** ******/

Again, thank you.

----------------------------------
Brian
Nov 13 '05 #1
8 2245
Pegboy wrote:
I am having trouble with malloc() again for a PC app I am developing. The
method of the suspicious line of code seems to be Ok on a embedded platform,
but not with the PC platform. The embedded platform uses a different
compiler. I feel like I'm overlooking a very simple problem, but I can't
see it. I would appreciate any help. Thank you.

I am trying to allocate memory for a structure of type NAT_S which contains
a pointer to a structure of type NAT_ENTRY_S (see code below).

The compiler reports warning 'Suspicious pointer conversion' as indicated
below in the code. This is the only warning or error I get.

This code appears to work but the next call to malloc() following this, the
app crashes. In some instances, ReadNat() is not called and the app works
Ok. So the problem points to within ReadNat(), which is where the warning
is.

I examined/watched the address given to 'nat' and 'nat->entries' and they
are different by 24 bytes when they should be different by 6. The sizeof(
NAT_S ) is 6.

/************************************************** **********/
typedef struct
{
short a;
short b;
long c;
long d;
} NAT_ENTRY_S;

typedef struct
{
short num_entries;
NAT_ENTRY_S *entries;
} NAT_S;

NAT_S *ReadNat( FILE *file, long offset )
{
NAT_S *nat;
short i, num_entries;

fseek( file, offset, SEEK_SET );
num_entries = ReadShort( file );

if( (nat = malloc( sizeof( NAT_S ) + (num_entries * sizeof(
NAT_ENTRY_S )) )) != NULL )
{
nat->num_entries = num_entries;
nat->entries = nat + sizeof( NAT_S ); /* COMPILER WARNING:
Suspicious pointer conversion */


I'll say it's suspicious. It's also most likely the cause of your
problem. What makes you think that nat + sizeof(NAT_S) yields a memory
address that will be properly aligned for a NAT_ENTRY_S? You cannot
simply place an object anywhere in memory that is convenient. Some
objects in some implementations must be aligned on certain boundaries
(e.g., a 4-byte integer might be required to start on an address that is
divisible by 4).

malloc() is required to return a pointer to memory that is properly
aligned for any type, but that address plus some arbitrary value is NOT
required to yield a pointer to memory that is properly aligned for some
random type.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Nov 13 '05 #2
Kevin Goodsell wrote:
Pegboy wrote:
I am having trouble with malloc() again for a PC app I am developing. The
method of the suspicious line of code seems to be Ok on a embedded
platform,
but not with the PC platform. The embedded platform uses a different
compiler. I feel like I'm overlooking a very simple problem, but I can't
see it. I would appreciate any help. Thank you.

I am trying to allocate memory for a structure of type NAT_S which
contains
a pointer to a structure of type NAT_ENTRY_S (see code below).

The compiler reports warning 'Suspicious pointer conversion' as indicated
below in the code. This is the only warning or error I get.

This code appears to work but the next call to malloc() following
this, the
app crashes. In some instances, ReadNat() is not called and the app works
Ok. So the problem points to within ReadNat(), which is where the warning
is.

I examined/watched the address given to 'nat' and 'nat->entries' and they
are different by 24 bytes when they should be different by 6. The sizeof(
NAT_S ) is 6.

/************************************************** **********/
typedef struct
{
short a;
short b;
long c;
long d;
} NAT_ENTRY_S;

typedef struct
{
short num_entries;
NAT_ENTRY_S *entries;
} NAT_S;

NAT_S *ReadNat( FILE *file, long offset )
{
NAT_S *nat;
short i, num_entries;

fseek( file, offset, SEEK_SET );
num_entries = ReadShort( file );

if( (nat = malloc( sizeof( NAT_S ) + (num_entries * sizeof(
NAT_ENTRY_S )) )) != NULL )
{
nat->num_entries = num_entries;
nat->entries = nat + sizeof( NAT_S ); /* COMPILER WARNING:
Suspicious pointer conversion */

I'll say it's suspicious. It's also most likely the cause of your
problem. What makes you think that nat + sizeof(NAT_S) yields a memory
address that will be properly aligned for a NAT_ENTRY_S? You cannot
simply place an object anywhere in memory that is convenient. Some
objects in some implementations must be aligned on certain boundaries
(e.g., a 4-byte integer might be required to start on an address that is
divisible by 4).


Though alignment *may* be an issue here (practically speaking,
however, I doubt it) -- the problem is deeper. The value of the
expression:

nat + sizeof( NAT_S )

is equivalent to:

&(nat[sizeof(NAT_S)])

(probably not what you want) which is then assigned to a
not-necessarily-compatible pointer type. [Remember, pointer
arithmetic is performed in units of the size of the type of the
object to which a pointer points.]

I would recommend to the OP to turn up the warning levels as high as
possible. This would reveal the *real* problem.

malloc() is required to return a pointer to memory that is properly
aligned for any type, but that address plus some arbitrary value is NOT
required to yield a pointer to memory that is properly aligned for some
random type.

-Kevin


HTH,
--ag

--
Artie Gold -- Austin, Texas
Oh, for the good old days of regular old SPAM.

Nov 13 '05 #3
Artie Gold wrote:

Though alignment *may* be an issue here (practically speaking, however,
I doubt it) -- the problem is deeper. The value of the expression:

nat + sizeof( NAT_S )

is equivalent to:

&(nat[sizeof(NAT_S)])


Yeah, that's right. I somehow failed to realize what was actually
happening, and read the code the way that the OP probably meant for it
to be, something like this:

(char *)nat + sizeof(NAT_S)

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

Nov 13 '05 #4
Pegboy wrote:

I am having trouble with malloc() again for a PC app I am developing. The
method of the suspicious line of code seems to be Ok on a embedded platform,
but not with the PC platform. The embedded platform uses a different
compiler. I feel like I'm overlooking a very simple problem, but I can't
see it. I would appreciate any help. Thank you.

I am trying to allocate memory for a structure of type NAT_S which contains
a pointer to a structure of type NAT_ENTRY_S (see code below).

The compiler reports warning 'Suspicious pointer conversion' as indicated
below in the code. This is the only warning or error I get.

This code appears to work but the next call to malloc() following this, the
app crashes. In some instances, ReadNat() is not called and the app works
Ok. So the problem points to within ReadNat(), which is where the warning
is.

I examined/watched the address given to 'nat' and 'nat->entries' and they
are different by 24 bytes when they should be different by 6. The sizeof(
NAT_S ) is 6.

/************************************************** **********/
typedef struct
{
short a;
short b;
long c;
long d;
} NAT_ENTRY_S;

typedef struct
{
short num_entries;
NAT_ENTRY_S *entries;
} NAT_S;

NAT_S *ReadNat( FILE *file, long offset )
{
NAT_S *nat;
short i, num_entries;

fseek( file, offset, SEEK_SET );
num_entries = ReadShort( file );

if( (nat = malloc( sizeof( NAT_S ) + (num_entries * sizeof(
NAT_ENTRY_S )) )) != NULL )
{
nat->num_entries = num_entries;
nat->entries = nat + sizeof( NAT_S ); /* COMPILER WARNING:
Suspicious pointer conversion */

for( i = 0; i < num_entries; i++ )
{
/* load entries here */
}
}

return ifd;
}


I am NOT reading things in detail, but I conclude you are trying
to allocate memory to hold the number of entries to be read, using
two entities. NAT_S is a header, holding the count and a pointer
to an array of NAT_ENTRY_S thinggummies. You have to allocate
those things separately, and it will be handy to make a function
to do it:

/* returns NULL for failure, else allocated space for n items */
NAT_S *makespacefor(size_t n)
{
NAT_S *p;

/* first, make space for the header */
if (p = malloc(sizeof *p)) {
/* header created, make space for the array */
p->num_entries = n;
if (p->entries = malloc(n * sizeof *(p->entries))) {
/* array space created - maybe initialize it */
}
else {
/* abject failure */
free(p);
p = NULL;
}
}
return p;
} /* makespacefor */

I disapprove strongly of your identifier names, but the point here
is to create the storage as simply as possible, note any failures,
and go on from there.

Keep functions as simple as possible, and have them do one job
only.
--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

Nov 13 '05 #5
Thanks all.

I've found that I'm simply going to have to allocate them separately, like
CBFalconer is saying.

To get rid of the warning message, I can change:
nat->entries = nat + sizeof( NAT_S );
to:
nat->entries = (NAT_ENTRY_S *)nat + sizeof( NAT_S );
but that doesn't solve the problem (app crashing).

Thanks again.
----------------------------
Brian
"Pegboy" <pe****@neb.rr.com> wrote in message
news:MZ******************@twister.rdc-kc.rr.com...
I am having trouble with malloc() again for a PC app I am developing. The
method of the suspicious line of code seems to be Ok on a embedded platform, but not with the PC platform. The embedded platform uses a different
compiler. I feel like I'm overlooking a very simple problem, but I can't
see it. I would appreciate any help. Thank you.

I am trying to allocate memory for a structure of type NAT_S which contains a pointer to a structure of type NAT_ENTRY_S (see code below).

The compiler reports warning 'Suspicious pointer conversion' as indicated
below in the code. This is the only warning or error I get.

This code appears to work but the next call to malloc() following this, the app crashes. In some instances, ReadNat() is not called and the app works
Ok. So the problem points to within ReadNat(), which is where the warning
is.

I examined/watched the address given to 'nat' and 'nat->entries' and they
are different by 24 bytes when they should be different by 6. The sizeof(
NAT_S ) is 6.

/************************************************** **********/
typedef struct
{
short a;
short b;
long c;
long d;
} NAT_ENTRY_S;

typedef struct
{
short num_entries;
NAT_ENTRY_S *entries;
} NAT_S;

NAT_S *ReadNat( FILE *file, long offset )
{
NAT_S *nat;
short i, num_entries;

fseek( file, offset, SEEK_SET );
num_entries = ReadShort( file );

if( (nat = malloc( sizeof( NAT_S ) + (num_entries * sizeof(
NAT_ENTRY_S )) )) != NULL )
{
nat->num_entries = num_entries;
nat->entries = nat + sizeof( NAT_S ); /* COMPILER WARNING:
Suspicious pointer conversion */

for( i = 0; i < num_entries; i++ )
{
/* load entries here */
}
}

return ifd;
}
/************************************************** ******/

Again, thank you.

----------------------------------
Brian

Nov 13 '05 #6
Pegboy wrote:

Thanks all.

I've found that I'm simply going to have to allocate them separately, like
CBFalconer is saying.

To get rid of the warning message, I can change:
nat->entries = nat + sizeof( NAT_S );
to:
nat->entries = (NAT_ENTRY_S *)nat + sizeof( NAT_S );
but that doesn't solve the problem (app crashing).


That's probably because you've forgotten something
rather important about pointer arithmetic: It is always
done in multiples of the size of the pointed-to object.
So your original `nat + sizeof(NAT_S)' does not point
to a spot `NAT_S' bytes beyond where `nat' itself points,
it points to a spot `NAT_S' *elements* beyond the start.
Since `nat' points to a `NAT_S' object, the sum advances
by `sizeof(NAT_S) * sizeof(NAT_S)' bytes -- which is
probably a little more than you intended, no?

The "correction" has a similar problem. In this case,
`(NAT_ENTRY_S*)nat' points to a `NAT_ENTRY_S' object, and
the arithmetic is done in terms of the size of that object.
The advance is now `sizeof(NAT_ENTRY_S) * sizeof(NAT_S)'
bytes -- again, more than you meant.

The simplest way to write the sum so it advances over
one `NAT_S' instance is `(NAT_ENTRY_S*)(nat + 1)'. Alas,
this can also fail, but for an entirely different reason:
alignment. There are perfectly portable ways to deal with
this problem, but they're surpassingly ugly -- and code
that's hard to read is more likely to be damaged during
maintenance than code that's clear. Unless you are really
allocating a whole lot of these things, to the point where
the per-allocation overhead (typically four to eight bytes)
is the difference betwen success and failure, you'd be well
advised to use separate allocations to hold separate data
types.

--
Er*********@sun.com
Nov 13 '05 #7
In article <3F***************@sun.com>
Eric Sosman <Er*********@Sun.COM> writes:
The simplest way to write the sum so it advances over
one `NAT_S' instance is `(NAT_ENTRY_S*)(nat + 1)'. Alas,
this can also fail, but for an entirely different reason:
alignment. There are perfectly portable ways to deal with
this problem, but they're surpassingly ugly ... [In general]
you'd be well advised to use separate allocations to hold separate data
types.


In this particular case, however -- where one item is a just
a "count header", and the remaining items are the actual data
structures -- C99's "flexible array member" might be the ideal
solution:

struct zag {
/* your data here */
};

struct zog {
int nzags;
struct zag zags[];
};

Now the routine to allocate N "zag"s enclosed in a "zog" might
look like:

struct zog *newzog(int nzags) {
struct zog *p;

if ((p = malloc(sizeof *p + nzags * sizeof p->zags[0])) == NULL)
... handle allocation failure ...
p->nzags = nzags;
/* fill in the zags, p->zags[i], for i in [0..nzags) if desired */
return p;
}

C89 has no "clean" way to implement this, but if the OP will consult
the FAQ, he will find the "dirty" method that will no doubt work
for him.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 13 '05 #8
Chris Torek wrote:
[... concerning the "struct hack" ...]
C89 has no "clean" way to implement this, but if the OP will consult
the FAQ, he will find the "dirty" method that will no doubt work
for him.


It can be done cleanly -- or "conformingly," at any rate --
in C89, at the price of ugliness. Here's an allocation for M
occurrences of `struct one' followed by N of `struct two':

struct fake { char x; struct two y; };
#define TWO_ALIGN offsetof(struct fake, y)
#define ONE_SPACE ((M * sizeof(struct one) + TWO_ALIGN - 1) \
/ TWO_ALIGN * TWO_ALIGN)
struct one *ptr1 = malloc(ONE_SPACE + N * sizeof(struct two));
/* assume success */
struct two *ptr2 = (struct two*)((char*)ptr1 + ONE_SPACE)

Personally, I find the ugliness of this "clean" solution so
overpowering that I've actually resorted to it only once. But
in the common case of wanting to store a single `struct head'
followed by a character string (which needs no alignment), the
situation is much simpler:

struct head *ptr = malloc(sizeof *ptr + strlen(string) + 1);
/* assume success */
strcpy( (char*)(ptr + 1), string);

--
Er*********@sun.com
Nov 13 '05 #9

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

Similar topics

14
by: Joseph | last post by:
I am trying to create a function that allocates memory for the matrix through a function; like the code below. However, this does not seem to work since I believe that the scope of the memory...
7
by: | last post by:
I fail to understand why that the memory allocated in the void create(int **matrix) does not remain. I passed the address of matrix so shouldn't it still have the allocated memory when it returns...
2
by: Thomas G. Marshall | last post by:
Arthur J. O'Dwyer <ajo@nospam.andrew.cmu.edu> coughed up the following: > On Thu, 1 Jul 2004, Thomas G. Marshall wrote: >> >> Aside: I've looked repeatedly in google and for some reason cannot >>...
6
by: grunes | last post by:
I wish to fread a few thousand bytes at a time in turn from several very large files from a DVD data disk, under Redhat Fedora Linux. When this is done the DVD drive wastes a lot of time and...
10
by: cijo | last post by:
Hi, My program has a pointer to a structure declared locally inside a function to which memory is allocated using malloc and reallocated later using realloc, and when I try to free the memory at...
7
by: slashdotcommacolon | last post by:
Hello, I'm working on the exercises from k&r, exercise 5-13 is to implement a simple replacement for the unix tail command. The brief says it should be able to cope no matter how unreasonable the...
27
by: ncf | last post by:
Hi all. In another topic, I was informed that I had to dynamically allocate memory instead of just trying to expand on a list. (I'm trying to learn C, and have a strong background in PHP and...
3
by: benjamin sago | last post by:
Hello all. I am writing a command shell, but am having trouble with memory allocations. I am trying to tokenise a string into a **char array for execvp (the unix launch-this-program function), but...
1
by: yucikala | last post by:
Hello, I'm a "expert of beginner" in C#. I have a dll - in C. And in this dll is this struct: typedef struct msg_s { /* please make duplicates of strings before next call to emi_read() ! */ ...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
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
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new...

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.