473,890 Members | 1,397 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

malloc syntax

Hello all

What is the difference between Method 1 and Method 2 below? Is Method 2 safe to use?
typedef short Word;
typedef unsigned char Char;

int nAllocSize = large number;

//Method 1 crashes in my machine for large nAllocSize
Word* pShort = (Word*)malloc(n AllocSize*sizeo f(Word));

//Method 2 seems ok even if nAllocSize is large
Word* pShort;
Char* pChar = (Char*)malloc(n AllocSize*sizeo f(Char)*2);
pShort = (Word*)pChar;
Nov 13 '05
20 11477
Simon Biber wrote:
"Sidney Cadot" <si****@jigsaw. nl> wrote:
Now I am not usually one to invoke Bjarne Stroustrup as a source of
profound wisdom, but I hope that you will agree that he knows a thing
or two about C. Of course, C++ doesn't allow implicit casts from void*
to pointers of any other types, and the reason is given in $5.6 of
"The C++ Programming Language". After stating allowed operations on
void*, it continues "Other operations would be unsafe because the
compiler cannot know what kind of object is really pointed to."

The objection that you "don't know what kind of object is really pointed to"
is not satisfied by adding casts.


That is not my point. The point is that, IMHO, this is a valid argument
for outlawing implicit casts from void* to something_else* .

It isn't outlawed in C, and to me that doesn't feel right.

For example:
void foo(int type, void *vp)
{
if(type == 1)
{
float *fp = vp;
*fp = 1.0;
}
else if(type == 2)
{
double *dp = vp;
*dp = 2.0;
}
}

Now, this function is valid C but invalid C++ because of the void* issue.
I agree that you cannot be sure whether the user of the function will
actually pass in the valid and correctly-aligned address of the specified
type, float or double respectively.

However, if I change it to be valid C++:
void bar(int type, void *vp)
{
if(type == 1)
{
float *fp = (float *)vp;
*fp = 1.0;
}
else if(type == 2)
{
double *dp = (double *)vp;
*dp = 2.0;
}
}

How has this actually helped the situation? The compiler still does not
check whether the conversion is valid.


Casts are few and far inbetween, in any reasonable program. To me, they
serve the purpose of putting out a warning sign: "something potentially
dangerous is going on here". I miss that with implicit casting.

Surely, for the compiler it doesn't matter much (it doesn't hurt to
include the casts either).

Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.

Best regards,

Sidney

Nov 13 '05 #11
Sidney Cadot <si****@jigsaw. nl> wrote in message news:<bp******* ***@news.tudelf t.nl>...
Simon Biber wrote:
"Sidney Cadot" <si****@jigsaw. nl> wrote:
Now I am not usually one to invoke Bjarne Stroustrup as a source of
profound wisdom, but I hope that you will agree that he knows a thing
or two about C. Of course, C++ doesn't allow implicit casts from void*
to pointers of any other types, and the reason is given in $5.6 of
"The C++ Programming Language". After stating allowed operations on
void*, it continues "Other operations would be unsafe because the
compiler cannot know what kind of object is really pointed to."

The objection that you "don't know what kind of object is really pointed to"
is not satisfied by adding casts.


That is not my point. The point is that, IMHO, this is a valid argument
for outlawing implicit casts from void* to something_else* .

It isn't outlawed in C, and to me that doesn't feel right.


Well, it feels very right to the people who don't want to have to
worry about getting casts right all the time, and who think casts in
general should be reserved for situations that are more questionable
than pointer conversion.

Don't think about the contortions the machine must go through to get
the pointers converted correctly: You're using C, not assembly. If you
code portably, you can legitimately say that it isn't your fault if
the pointers don't behave as they should. (You still might have to fix
the code, but at least you'll be able to say that the compiler
designer screwed up.)

< code sans casts >
Now, this function is valid C but invalid C++ because of the void* issue.
I agree that you cannot be sure whether the user of the function will
actually pass in the valid and correctly-aligned address of the specified
type, float or double respectively.
< code with casts >
How has this actually helped the situation? The compiler still does not
check whether the conversion is valid.


Casts are few and far inbetween, in any reasonable program. To me, they
serve the purpose of putting out a warning sign: "something potentially
dangerous is going on here". I miss that with implicit casting.

Surely, for the compiler it doesn't matter much (it doesn't hurt to
include the casts either).


It doesn't hurt to include casts, except that it clutters the code
visually and obscures an important reason to use C instead of
assembly: You get nice features you don't have to think about. You
don't need to think about how floating-point numbers are represented,
how integer promotion needs to work, or how pointer conversion must
happen.

Casts are ugly, and they should only be used when something /really/
odd is happening. Pointer conversion isn't that odd: The Standard
Library depends upon it, and it can be used to great advantage to
write code that approaches polymorphism as closely as is possible in a
non-OO language.

Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.
Again, don't worry about it. Or, if you must worry about it, choose a
type-safe language like Pascal or Ada. (Hell, some Pascal variants
don't even allow you to cast /at all/: Once you have a floating-point
number, you'll never be able to perform integer arithmetic on it!) C
was designed for a different group and with a different philosophy.

Best regards,

Sidney

Nov 13 '05 #12
August Derleth wrote:
"Sidney Cadot" <si****@jigsaw. nl> wrote:
That is not my point. The point is that, IMHO, this is a valid argument
for outlawing implicit casts from void* to something_else* .

It isn't outlawed in C, and to me that doesn't feel right.
Well, it feels very right to the people who don't want to have to
worry about getting casts right all the time, and who think casts in
general should be reserved for situations that are more questionable
than pointer conversion.
I don't agree, but well - that's life.
Don't think about the contortions the machine must go through to get
the pointers converted correctly: You're using C, not assembly. If you
code portably, you can legitimately say that it isn't your fault if
the pointers don't behave as they should. (You still might have to fix
the code, but at least you'll be able to say that the compiler
designer screwed up.)
I have no issue with the work the compiler needs to do in any
circumstance. My issue is that I want the source code to clearly reflect
the semantics of what is going on. I simply don't like C's ability to
'help' me by providing an implicit cast in this case.
Surely, for the compiler it doesn't matter much (it doesn't hurt to
include the casts either).

It doesn't hurt to include casts, except that it clutters the code
visually and obscures an important reason to use C instead of
assembly: You get nice features you don't have to think about.


A line has to be drawn somewhere. In the days prior to C99, you could
happily not declare a result type for a function returning int; the
compiler would "help" by providing it for you. I didn't like that in
pretty much the same way as I don't like implicit void* casts.
You don't need to think about how floating-point numbers are represented,
Actually, in my work, I really *do* need to do this.
how integer promotion needs to work,
For any piece of non-trivial low-level C code, you'll get burned pretty
soon if you don't know this.
or how pointer conversion must happen.
The "how" doesn't interest me all that much... It's more an issue of who
is in control of deciding whether two given types are assignment
compatible. I maintain that this is an issue that is for the programmer
to decide.
Casts are ugly, and they should only be used when something /really/
odd is happening.
....Like, changing the type of something, because I, the programmer, know
that the type inferred by the compiler is not correct? That's my rule
for determining whether a cast is warranted.

Could you define the circumstances where you feel a cast is warranted?
Pointer conversion isn't that odd: The Standary Library depends upon
it, and it can be used to great advantage to write code that approaches
polymorphism as closely as is possible in a non-OO language.
I'm not claiming pointer conversions are odd. I'm saying that "oddness"
is a pretty bad criterion to decide whether casts are ok, since it
doesn't mean much.
Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.

Again, don't worry about it.
That would be, well, foolish. I need to be able to know what this kind
of code does:
#include <stdio.h>
int main(void)
{
double x;
int y;

x = 1.9; y=x;
printf ("%g -> %d\n", x, y);

x = -1.9; y=x;
printf ("%g -> %d\n", x, y);

x = 1e30; y=x;
printf ("%g -> %d\n", x, y);

x = -1e30; y=x;
printf ("%g -> %d\n", x, y);

return 0;
}
Or, if you must worry about it, choose a
type-safe language like Pascal or Ada.
There's many thinks about C that make it the better choice for my kind
of work. My software needs to be distributed and compiled by users, for
one thing; I can only safely assume that they'll have a C compiler.
(Hell, some Pascal variants don't even allow you to cast /at all/:
Once you have a floating-point number, you'll never be able to perform
integer arithmetic on it!)
As to the first remark: if memory serves, ISO C doesn't support casts.

As to the second statement, well, that is of course simply wrong. You
have trunc() and round() for that, at least. Which I think is a very
good idea.
C was designed for a different group and with a different philosophy.


Both have evolved. Unfortunately, it seems that there is no market
pressure nowadays to bring the Pascal standard up-to-date; in principle,
I think it has the potential of being a very useful and practical
language for many domains where C now reigns supreme. If you look at the
Delphi and Freepascal languages, there are few applications that they
cannot handle as well or better than C. Just my $0.05.
Best regards,

Sidney

Nov 13 '05 #13
Sidney Cadot wrote:

As to the first remark: if memory serves, ISO C doesn't support casts.


That should be ISO Pascal. Doh.

Sidney

Nov 13 '05 #14
Sidney Cadot wrote:
Simon Biber wrote:


The objection that you "don't know what kind of object is really
pointed to"
is not satisfied by adding casts.

That is not my point. The point is that, IMHO, this is a valid argument
for outlawing implicit casts from void* to something_else* .

It isn't outlawed in C, and to me that doesn't feel right.


That's fine, but it's not an argument in favor of malloc-casting, as far
as I can tell. We are talking about the C language, not some theoretical
language similar to C but without implicit conversions from void* to
other pointer types. Within the C language as it actually exists,
omitting the cast is usually (slightly) safer.


Casts are few and far inbetween, in any reasonable program. To me, they
serve the purpose of putting out a warning sign: "something potentially
dangerous is going on here". I miss that with implicit casting.
There is no such thing as "implicit casting". A cast is, by definition,
an explicit conversion. An implicit conversion is not a cast.

As for your warning sign analogy, that's fine. But why would you want to
flag a perfectly safe malloc call with such a warning? Warning signs are
only useful when they are accurate.

Surely, for the compiler it doesn't matter much (it doesn't hurt to
include the casts either).
It doesn't "hurt" in the same sense that any unnecessary text (that
neither changes nor clarifies the meaning of the program) doesn't hurt.
You could cast every expression you type, throw in a few dozen
parenthesis for good measure, and have a haiku comment after every line
in your program if you wanted to, and it wouldn't "hurt", at least in
the sense that the program would still behave the same.

Of course, this only applies to casts as long as you haven't made a
mistake. Unnecessary casts are harmful (for normal people) mainly
because they can hide mistakes. If you never make a mistake in your
code, then you can certainly cast all you want without any harm.

Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.


What makes you think a pointer cast doesn't generate code?

If you don't like implicit floating point to integer conversions, you
are free to not use them. Since such a conversion could actually be a
problem (unlike the implicit conversion of malloc's return value), using
a cast as a "warning sign" like you mentioned before may be appropriate.

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

Nov 13 '05 #15
Kevin Goodsell wrote:
Sidney Cadot wrote:
That is not my point. The point is that, IMHO, this is a valid
argument for outlawing implicit casts from void* to something_else* .

It isn't outlawed in C, and to me that doesn't feel right. That's fine, but it's not an argument in favor of malloc-casting, as far
as I can tell. We are talking about the C language, not some theoretical
language similar to C but without implicit conversions from void* to
other pointer types.
There are features of C I do not use because I consider them not useful
or downright ugly. This is one of them; I would be surprised if the same
wouldn't be true for most of us here (trigraphs come to mind).

So for me, at least, this /is/ an argument against implicit void*
conversions, and therefore for explicit malloc casts.
Within the C language as it actually exists, omitting the cast is usually
(slightly) safer.
This came up in the earlier discussion a few weeks ago. The "missing
#include stdlib.h" argument I think is not very strong, given that any
quality compiler can be made to warn about that nowadays. The argument
that you have to maintain consistency between no less than three type
specifiers when you do:

double *x = (double *)malloc(n * sizeof(double))

....is somewhat stronger, but this is still "taste" territory IMHO. All
in all, I'd have to say that the discussion is not an open-and-shut case
as many here feel it is, since there are also arguments /for/ malloc
casting.

I still see some validity in maintaining C++ compatibility. Essentially,
malloc casts are by far the most important (often only) thing to keep a
valid C program from also being a valid C++ program. Many disagreed,
arguing that I wouldn't try to compile my C program using a Fortran
compiler either. Upon which I responded that actually, I would, if this
could help me to catch errors (which is not the case, as it is with C++).

The second, more philosophical argument, is that I use casts to improve
or correct the compiler's knowledge of the type of an expression. Given
the loose expression malloc(1000 * sizeof(double)) , this ought to be of
type double* instead of void*, so I cast. The fact that it is usually
assigned to a variable of type double* immediately after, invoking
implicit conversion, is irrelevant as far as I am concerned; the
expression itself ought to be of type double*, which allows the compiler
to catch errors of the form:

int *x = (double *)malloc(1000 * sizeof(double))

That would go unnoticed on

int *x = malloc(1000 * sizeof(double))

Although many (most here, at least) would prefer

int *x = malloc(1000 * sizeof *x)

Which doesn't suffer from any problem, except that the RHS expression is
of type void*, and needs an implicit conversion due to assignment
(which I don't like).

This basically summarizes the discussion pretty even-handedly, I hope.
The only thing I want to argue is that it's still up for discussion. No
killer arguments are made from both side of the fence I think.
Casts are few and far inbetween, in any reasonable program. To me,
they serve the purpose of putting out a warning sign: "something
potentially dangerous is going on here". I miss that with implicit
casting.


There is no such thing as "implicit casting". A cast is, by definition,
an explicit conversion. An implicit conversion is not a cast.


I'll try to be more careful in the present and future.
As for your warning sign analogy, that's fine. But why would you want to
flag a perfectly safe malloc call with such a warning? Warning signs are
only useful when they are accurate.
Having a block of a thousand doubles floating around on the heap and
pointing to it by a void* to me is a strange situation. I mend it with
the cast. Overriding the type inferred by the compiler is something that
merits a warning for me.
Surely, for the compiler it doesn't matter much (it doesn't hurt to
include the casts either). It doesn't "hurt" in the same sense that any unnecessary text (that
neither changes nor clarifies the meaning of the program) doesn't hurt.
You could cast every expression you type, throw in a few dozen
parenthesis for good measure, and have a haiku comment after every line
in your program if you wanted to, and it wouldn't "hurt", at least in
the sense that the program would still behave the same.
My line was a response to the statement that not including the cast
doesn't make a whole lot of difference to the compiler.

Haiku comments and superfluous parentheses, you (and I) don't do that.
However we probably both use indenting and a consisting bracing style.
There's a whole spectrum of things one can do to source code without
altering its meaning, everybody draws a line somewhere.
Of course, this only applies to casts as long as you haven't made a
mistake. Unnecessary casts are harmful (for normal people) mainly
because they can hide mistakes. If you never make a mistake in your
code, then you can certainly cast all you want without any harm.
Incorrect casts are harmful almost by definition. Unnecessary casts, in
my opinion, depends a lot on one's definition of the word "unnecessar y".

I have stated my criterion for using casts several times now, which is
overriding the type inferred by the compiler for an expression when I,
the programmer, know better. That's a pretty clear criterion. It's also
a defensible criterion, I think. Followinging this criterion, malloc
casts are no longer unneccesary, but an integral part of my particular
coding style.
Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.


What makes you think a pointer cast doesn't generate code?


Experience with modern hardware. Surely the standard allows for
architectures that have type-tagged memory and perhaps there are some
architectures even today that do need to execute code on a pointer type
conversion (either implicit or by cast), but I think it is fair to say
that this is rare. Especially compared to float-to-int conversions, that
must generate code.
If you don't like implicit floating point to integer conversions, you
are free to not use them. Since such a conversion could actually be a
problem (unlike the implicit conversion of malloc's return value), using
a cast as a "warning sign" like you mentioned before may be appropriate.


I think it is, yes.

Best regards,

Sidney

Nov 13 '05 #16
>August Derleth wrote:
[Some feel that]
Casts are ugly, and they should only be used when something /really/
odd is happening.
In article <news:bp******* ***@news.tudelf t.nl>
Sidney Cadot <si****@jigsaw. nl> writes:
...Like, changing the type of something, because I, the programmer, know
that the type inferred by the compiler is not correct? That's my rule
for determining whether a cast is warranted.
I think it is worth noting here that the phrase "changing the type
of something" has implications that are false. A cast from double
to int, for instance, does not change the type of the double value
being cast:

double x;
...
printf("(int)x = %d\n", (int)x);

but rather simply produces a new value, of the type given in the
cast, as defined by C's conversion rules for casts, which are a
superset of those for ordinary assignment. (The "superset" occurs
only because casts permit conversions that would otherwise be
forbidden, e.g., "int *" to "double *".)

Of course, since (as you mentioned earlier) you dislike the automatic
conversions -- e.g.:

int i;
...
i = x;

automatically truncates values like 3.1415926535897 9323846 (as
stored in x) to just 3 (then stored in i) -- then presumably you
will dislike the automatic conversions for "void *" (and apparently
you do):

[Sidney Cadot, in article <news:bp******* ***@news.tudelf t.nl>:]
Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.

Note that these are not "casts" but rather "conversion s", because in
C, "cast" refers specifically and only to the syntax in which a
type-name is enclosed in parentheses.

You say they "go one step further" in generating actual code, but
in fact, perhaps they do not. For instance, the Data General
Eclipse has two pointer formats, so that pointer conversions
sometimes generate code; and hypothetically, one could have a C
implementation in which "int"s are actually stored in the same
floating-point form as "double"s, but are simply forced to be
integral and within the range that avoids stepwise increases (e.g.,
where nextafter(x) is x+2.0 instead of x+1.0 or less).

(The latter -- storing "int"s in FP bitpatterns -- might be used
on a Burroughs A-series machine, as I understand it. These machines
would certainly make implementing C "interestin g", since they were
designed to produce only correct answers even if it took longer
than getting a fast-but-wrong answer. They did not survive
commercially. This pattern repeated later with the Intel 432.)
Or, if you must worry about it, choose a
type-safe language like Pascal or Ada.

There's many thinks about C that make it the better choice for my kind
of work. My software needs to be distributed and compiled by users, for
one thing; I can only safely assume that they'll have a C compiler.


In that case, write in Ada, and point them at GNAT. :-)
--
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 #17
In <Xn************ *************** *******@63.223. 8.240> August Derleth <li************ *****@onewest.n et> writes:
Da*****@cern.c h (Dan Pop) wrote in news:bp******** **@sunnews.cern .ch on
Thu 20 Nov 2003 10:09:51a:
In <b6************ *************@p osting.google.c om>
li************* **@yahoo.com (August Derleth) writes:
pe******@hot mail.com (pertheli) wrote in message
news:<48**** *************** *******@posting .google.com>...
Hello all

What is the difference between Method 1 and Method 2 below? Is Method
2 safe to use?

As a matter of fact, both are incorrect.


As a matter of fact, both are correct. Stylistically objectionable,
but technically correct.

Dan


I can't be held accountable for all of the crap the Standard implicitly
condones. ;)

The fact is that casting the return value of malloc (and all of the 'alloc
clan) is rather stupid and is a habit that should be broken in all C
programmers. It hides another error and implies a fundamental
misunderstandi ng of the whole point of having a pointer to void type.


Nevertheless, it is still technically correct, therefore you're wrong
calling it incorrect. It's OK to call it stupid or bad habit, but you
have no grounds on calling it incorrect.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #18
In <3f************ ***********@new s.optusnet.com. au> "Simon Biber" <ne**@ralminNOS PAM.cc> writes:
"Dan Pop" <Da*****@cern.c h> wrote:
The right way of doing it, however, is:

size_t size = nAllocSize * sizeof *pShort;

if (size < nAllocSize || size < sizeof *pShort) {
/* we want to allocate more bytes than size_t can represent */
}

pShort = malloc(size);


Assuming:
SIZE_MAX == 65535
nAllocSize == 30000
sizeof *pShort == 4
Then:
nAllocSize * sizeof *pShort == 120000
120000 % 65536 == 54464
54464 > nAllocSize
54464 > sizeof *pShort

Or are you relying on the assumption that sizeof *pShort is 2? This
is not good code then...


I've merely used the rule for detecting addition overflow, instead of the
one for multiplication overflow:

if (size / nAllocSize != sizeof *pShort) { ...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 13 '05 #19
Chris Torek wrote:
...Like, changing the type of something, because I, the programmer, know
that the type inferred by the compiler is not correct? That's my rule
for determining whether a cast is warranted.
I think it is worth noting here that the phrase "changing the type
of something" has implications that are false. A cast from double
to int, for instance, does not change the type of the double value
being cast:

double x;
...
printf("(int)x = %d\n", (int)x);

but rather simply produces a new value, of the type given in the
cast, as defined by C's conversion rules for casts, which are a
superset of those for ordinary assignment. (The "superset" occurs
only because casts permit conversions that would otherwise be
forbidden, e.g., "int *" to "double *".)


You are right. My terminology was imprecise.
[snipped a bit...]
Along the same lines, I don't particularly like implicit casts from
double to int in C. These go one step further than pointer casts, in
that they actually *do* generate code. I don't like that for one bit.

Note that these are not "casts" but rather "conversion s", because in
C, "cast" refers specifically and only to the syntax in which a
type-name is enclosed in parentheses.


Yes. Again, I stand corrected and will try my best to be more precise
next time.
You say they "go one step further" in generating actual code, but
in fact, perhaps they do not. For instance, the Data General
Eclipse has two pointer formats, so that pointer conversions
sometimes generate code;
I realize there are architectures where pointer casts would generate
code (although it is fair to say that nowadays they are quite rare, I
think).
and hypothetically, one could have a C
implementation in which "int"s are actually stored in the same
floating-point form as "double"s, but are simply forced to be
integral and within the range that avoids stepwise increases (e.g.,
where nextafter(x) is x+2.0 instead of x+1.0 or less).
That is an interesting possibility that I overlooked. Now that I think
of it: yes, it would be rather possible to use e.g. IEEE-754 doubles (or
even singles) as a valid integer type in C, by defining the exponent
part as padding bits. I think that could just be brought in line with C
integer semantics. Funny.
(The latter -- storing "int"s in FP bitpatterns -- might be used
on a Burroughs A-series machine, as I understand it. These machines
would certainly make implementing C "interestin g", since they were
designed to produce only correct answers even if it took longer
than getting a fast-but-wrong answer. They did not survive
commercially. This pattern repeated later with the Intel 432.)
Or, if you must worry about it, choose a
type-safe language like Pascal or Ada.

There's many thinks about C that make it the better choice for my kind
of work. My software needs to be distributed and compiled by users, for
one thing; I can only safely assume that they'll have a C compiler.


In that case, write in Ada, and point them at GNAT. :-)


There are more reasons. For starters, I don't know Ada :-)

Best regards,

Sidney

Nov 13 '05 #20

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

Similar topics

59
5240
by: Steve Zimmerman | last post by:
This program compiles fine, but are there any hidden dangers in it, or is it ok? Experiment 1 ################################################## #include <stdio.h> #include <stdlib.h> #include <malloc.h> #include <string.h>
14
8492
by: dam_fool_2003 | last post by:
Friends, cannot we malloc a array? So, I tried the following code: int main(void) { unsigned int y={1,3,6},i,j; for(i=0;i<3;i++) printf("before =%d\n",y); *y = 7; /* 1*/
13
83919
by: mike79 | last post by:
hi all.. if I wanted to malloc a struct, say the following: struct myStruct1 { int number; char *string; }
10
9050
by: Ian Todd | last post by:
Hi, I am trying to read in a list of data from a file. Each line has a string in its first column. This is what i want to read. I could start by saying char to read in 1000 lines to the array( i think!!). But I want to use malloc. Each string is at most 50 characters long, and there may be zero to thousands of lines. How do I actually start the array? I have seen char **array etc. At first I tried char *array but I think that gives 50...
231
23351
by: Brian Blais | last post by:
Hello, I saw on a couple of recent posts people saying that casting the return value of malloc is bad, like: d=(double *) malloc(50*sizeof(double)); why is this bad? I had always thought (perhaps mistakenly) that the purpose of a void pointer was to cast into a legitimate date type. Is this wrong? Why, and what is considered to be correct form?
5
2079
by: Grant Austin | last post by:
What would be the correct syntax for setting up a dynamic array of structs? Suppose you have a struct declared: struct relation { FILE * binFile; unsigned int numAttrs; struct attrList * relAttrs; /* definition shown at end of post */ };
68
15756
by: James Dow Allen | last post by:
The gcc compiler treats malloc() specially! I have no particular question, but it might be fun to hear from anyone who knows about gcc's special behavior. Some may find this post interesting; some may find it off-topic or confusing. Disclaimers at end. The code samples are intended to be nearly minimal demonstrations. They are *not* related to any actual application code.
14
2371
by: Chen Shusheng | last post by:
CSS white here: Simply strange, I found "define" can not work with "malloc". Together my complier will say "parse error". Could anyone tell me why? ------------------------- #define MAX 10000 ....... int main(void){ .....
24
3143
by: VijaKhara | last post by:
hi all, i am trying to create a dynamic 2D array with size N x 3 (N will be put in as a parameter) using the following code: int **xyz; int i,N; N=30000; xyz=malloc(3*sizeof(int*));
0
9980
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, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9829
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 effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
11236
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
0
10836
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
8018
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 presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
7172
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5856
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
6064
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
4278
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.