473,321 Members | 1,667 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,321 software developers and data experts.

malloc experiments

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>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));

strcpy(president->name, "George Washington");
president->next = (struct pres *)malloc(sizeof(struct pres));

printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);

return 0;
}

################################################## #################

--Steve

Nov 13 '05 #1
59 5077
Steve Zimmerman <st******@sonic.net> wrote in
news:3F**************@sonic.net:
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>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));
This is a problem. If you had neglected to include <stdlib.h> there would
be no prototype for malloc(), thus it would return an integer. Your cast
would have hidden this mistake. In C (but not C++), we do not cast the
return value of malloc(). Second, it is best to specify the size of the
object not its type. That way, if the type of the object changes you don't
have to find the malloc() call and change that line too. E.g.

president = malloc(sizeof *president);

Next, be sure you were handed a valid pointer, malloc() can fail. If it
does, maybe you could return EXIT_FAILURE.
strcpy(president->name, "George Washington");
Use strncpy() and tell strncpy not to exceed sizeof president->name - 1.
president->next = (struct pres *)malloc(sizeof(struct pres));
(Same malloc() comments here too).
printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);

return 0;
}


--
- Mark ->
--
Nov 13 '05 #2

"Steve Zimmerman" <st******@sonic.net> wrote in message
news:3F**************@sonic.net...
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>
Add this definition to avoid magic numbers
#define PRES_NAME_LEN 25


int main()
{
struct pres {
char name[25];
struct pres *next;
};
Use PRES_NAME_LEN instead of magic 25.

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres)); You have to check if malloc was successful.
The condition to continue execution is (president != NULL)
Just a minor remark;
You don't have to cast the result from malloc as long as stdlib.h is
included (and it should be!).

strcpy(president->name, "George Washington"); Oops.
What happens if the string exceeds the size of "name" field in the struct?
Something will be destroyed and overwritten!
Protect the field from overflow by using
strncpy(president->name, "George Washington", PRES_NAME_LEN);
president->next = (struct pres *)malloc(sizeof(struct pres));

printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);

return 0;
}

################################################## #################

--Steve


Finally, you must free the memory you've allocated when this program will
transform from prototype to a real application.

Mikael T
Nov 13 '05 #3
Steve Zimmerman wrote:

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>
Non-Standard header. It's anybody's guess what it might do.
#include <string.h>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));
Two minor points: the cast is unnecessary, and it would be
better to write `sizeof *president'. One major gaffe: malloc()
can fail and return NULL, and you should check for this before
trying to use the possibly-not-allocated memory.
strcpy(president->name, "George Washington");
president->next = (struct pres *)malloc(sizeof(struct pres));

printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);
"%i" is for converting integers, not pointer values. You
need to use "%p", and you need to convert the pointer value
from a `struct pres*' to a `void*'.
return 0;
}

################################################## #################

--Steve


--
Er*********@sun.com
Nov 13 '05 #4
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok? president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.

--Daniel

--
"With me is nothing wrong! And with you?" (from r.a.m.p)
Nov 13 '05 #5


Steve Zimmerman wrote:

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>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));

strcpy(president->name, "George Washington"); Danger - what if the name is longer than 24 characters?

president->next = (struct pres *)malloc(sizeof(struct pres));

printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);

return 0;
}

################################################## #################

--Steve


--
Fred L. Kleinschmidt
Associate Technical Fellow
Boeing Common User Interface Services
Nov 13 '05 #6
"Mark A. Odell" <no****@embeddedfw.com> wrote:
Steve Zimmerman <st******@sonic.net> wrote:
strcpy(president->name, "George Washington");


Use strncpy() and tell strncpy not to exceed sizeof president->name - 1.


strncpy is the wrong tool for this job. If the string supplied is
too large it will leave the array unterminated, so there is not a
valid string. Use strncat instead, by zeroing the string first:
*president->name = 0; /* or president->name[0] = '\0'; */
strncat(president->name, "George Washington", sizeof president->name - 1);
printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);


This is undefined behaviour. The printf is looking for an int, but you
never supplied an int, you supplied a pointer to struct pres, which
may be stored in an entirely different place.

You should print pointers with the %p conversion, and remember to
cast the pointer to (void *), as that is the type expected by %p.

printf("next structure address = %p\n", (void*)president->next);

--
Simon.
Nov 13 '05 #7
"Mikael Thorgren" <mi*************@senet.abb.se> wrote:
strcpy(president->name, "George Washington");


Oops.
What happens if the string exceeds the size of "name" field in the struct?
Something will be destroyed and overwritten!
Protect the field from overflow by using
strncpy(president->name, "George Washington", PRES_NAME_LEN);


You want strncat instead, because strncpy doesn't null-terminate
the string if the length argument is exhausted. You also want to
specify PRES_NAME_LEN - 1 here, to leave room for the null char.

--
Simon.
Nov 13 '05 #8
"Mikael Thorgren" <mi*************@senet.abb.se> writes:
"Steve Zimmerman" <st******@sonic.net> wrote in message
news:3F**************@sonic.net...
struct pres {
char name[25];
struct pres *next;
};


Use PRES_NAME_LEN instead of magic 25.
strcpy(president->name, "George Washington");


What happens if the string exceeds the size of "name" field in the struct?
Something will be destroyed and overwritten!
Protect the field from overflow by using
strncpy(president->name, "George Washington", PRES_NAME_LEN);


This is still problematic, as `strncpy' does not write a '\0' character if
the source string has length equal to or greater than the length specified
in the third argument.

A better solution:

strncpy (president->name, "George Washington", PRES_NAME_LEN - 1);
president->name [PRES_NAME_LEN - 1] = '\0';

Martin
Nov 13 '05 #9
bd
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steve Zimmerman wrote:
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>
No such header. malloc(), calloc(), and free() are in stdlib.h
#include <string.h>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));
The cast is unnecessary, and could prevent the compiler warning you if you
accidentally forget to include stdlib.h.

strcpy(president->name, "George Washington");
president->next = (struct pres *)malloc(sizeof(struct pres));
See above.

printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);
%i is for an int. president->next is a struct pres *. Try;
printf("next structure address = %p\n", (void *)president->next);
return 0;
}


- --
There's another way to survive. Mutual trust -- and help.
-- Kirk, "Day of the Dove", stardate unknown

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQE/VjfEx533NjVSos4RAnHNAJd0IU66hKYlV4fDyPlNCSTGqaOeAJ 9oWWaS
BDUTzHsSo6ZqFeR3WZR8AA==
=msbg
-----END PGP SIGNATURE-----
Nov 13 '05 #10
bd
Fred L. Kleinschmidt wrote:


Steve Zimmerman wrote:

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>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));

strcpy(president->name, "George Washington");
Danger - what if the name is longer than 24 characters?


strcpy() like this is ok - the string literal requires 18 bytes. There's
little point in checking the size of a string if you know it beforehand,
after all.

--
Magic is always the best solution -- especially reliable magic.

Nov 13 '05 #11
Simon Biber wrote:
"Mikael Thorgren" <mi*************@senet.abb.se> wrote:
strcpy(president->name, "George Washington");


Oops.
What happens if the string exceeds the size of "name" field in the struct?
Something will be destroyed and overwritten!
Protect the field from overflow by using
strncpy(president->name, "George Washington", PRES_NAME_LEN);

You want strncat instead, because strncpy doesn't null-terminate
the string if the length argument is exhausted. You also want to
specify PRES_NAME_LEN - 1 here, to leave room for the null char.


Not really, because the memory returned from malloc is going to
contain garbage. In either case, you're still going to have to
insert a null somewhere.

Nov 13 '05 #12
"Matt Gregory" <ms********@earthlink.net> wrote:
Simon Biber wrote:
You want strncat instead, because strncpy doesn't
null-terminate the string if the length argument is
exhausted. You also want to specify PRES_NAME_LEN -
1 here, to leave room for the null char.


Not really, because the memory returned from malloc is
going to contain garbage. In either case, you're still
going to have to insert a null somewhere.


Yes, the choice is between the equivalent
president->name[0] = '\0';
strncat(president->name, "George Washington", PRES_NAME_LEN - 1);
and
strncpy (president->name, "George Washington", PRES_NAME_LEN - 1);
president->name[PRES_NAME_LEN - 1] = '\0';

Of those I would take the first, as strncpy makes me
instinctively suspicious when reading code.

--
Simon.
Nov 13 '05 #13
Daniel Haude <ha***@physnet.uni-hamburg.de> wrote in message news:<sl*****************@kir.physnet.uni-hamburg.de>...
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok?

president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.


It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.
Nov 13 '05 #14
Steve Zimmerman wrote:
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>

^^^^^^^^
Here's one obvious danger: that it might not compile with C compiler.
<malloc.h> is not one of the standard headers. malloc() and friends are
handled by <stdlib.h>
--
Martin Ambuhl

Nov 13 '05 #15
[snip]

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));
This is a problem. If you had neglected to include <stdlib.h> there would
be no prototype for malloc(), thus it would return an integer. Your cast
would have hidden this mistake.


Can you elaborate on this. Isnt the prototype of malloc:
void *malloc( size_t size );

malloc returns a void pointer to the allocated space, or NULL if there is
insufficient memory available.
Since it returns a pointer to void if casted to the variables type thats in
use, that seems correct ! than not casting at all !.

In C (but not C++), we do not cast the return value of malloc(). Second, it is best to specify the size of the
object not its type. That way, if the type of the object changes you don't
have to find the malloc() call and change that line too. E.g.

president = malloc(sizeof *president);

[ snip ]
Nov 13 '05 #16

On Thu, 3 Sep 2003, Ravi Uday wrote:
president = (struct pres *)malloc(sizeof(struct pres));


This is a problem. If you had neglected to include <stdlib.h> there would
be no prototype for malloc(), thus it would return an integer. Your cast
would have hidden this mistake.


Can you elaborate on this. Isnt the prototype of malloc:
void *malloc( size_t size );

malloc returns a void pointer to the allocated space,
or NULL if there is insufficient memory available.
Since it returns a pointer to void if casted to the
variables type thats in use, that seems correct !
than not casting at all !.


If you cast malloc's return value, that *is* correct C.
It *will* compile, and, if you haven't made any foolish
errors, it *will* do exactly what you expect. It's just
not the nicest possible way of doing things.

Consider the following program fragment:
#include <stdio.h>

int main(void)
{
int *p;
...
p = (int *) malloc(sizeof (int));
...
}

Do you see the bug?

If not, here it is: The programmer forgot to #include <stdlib.h>.
So there's no prototype for 'malloc' in scope inside 'main'.
So, when the compiler sees the call to 'malloc', it just *assumes*
that 'malloc' is a function taking one argument (of type 'size_t',
because that's what 'sizeof' yields), and returning an 'int'
(because that's just the traditional return type in C). So we
effectively have a program that looks like this:

int main(void)
{
int wrong_return_type_malloc(size_t);
int *p;
...
p = (int *) wrong_return_type_malloc( foo );
...
}

Now, look at that cast. In the current program, it's *hiding*
the error from the compiler. (Remember that a cast always says
to the compiler, "Be quiet and let me do this my way, right or
wrong.") So this program will compile without diagnostics, and
run, and crash, because we're expecting 'malloc' to return an
'int' (by mechanism A) when really it's returning a 'void *' (by
mechanism B). Really, some machines will actually use different
registers for different types, and so on.
So our program crashes at runtime -- or, insidiously, doesn't
crash until the day of the big demo, when the boss is around.

Now look at the same program, minus the cast (but *still* missing
the <stdlib.h> header file).

int main(void)
{
int wrong_return_type_malloc(size_t);
int *p;
...
p = wrong_return_type_malloc( foo );
...
}

*Now*, minus the cast, we have an assignment of an
'int' to an 'int *'. That's a problem that the
compiler is required to warn us about. So, instead
of the big-demo-day crash, we get a nice error message
from the compiler, along the lines of

Line xxx: Incompatible types in assignment

and we add the missing header, and everything is fine!

So *that's* why most people here will tell you not to
cast 'malloc'.

Tak-Shing Chan came up with an example or two of places
where it's actually more foolproof to cast malloc than
not, involving 'extern' declarations. Look them up on
Google Groups if you're interested. But the main point
stands: Don't cast malloc, and don't cast *anything*
unless you can abundantly justify the cast. Because
casts are blunt instruments, capable of doing great
damage when used indiscriminately.

HTH,
-Arthur
Nov 13 '05 #17
"Simon Biber" <sb****@optushome.com.au> wrote in
news:3f**********************@news.optusnet.com.au :
strncat(president->name, "George Washington", PRES_NAME_LEN - 1);


Question on style here. How does PRES_NAME_LEN improve readability versus
the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.

--
- Mark ->
--
Nov 13 '05 #18
"Mark A. Odell" <no****@embeddedfw.com> writes:
"Simon Biber" <sb****@optushome.com.au> wrote in
news:3f**********************@news.optusnet.com.au :
strncat(president->name, "George Washington", PRES_NAME_LEN - 1);


Question on style here. How does PRES_NAME_LEN improve readability versus
the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.


Although I'm not the person who suggested `PRES_NAME_LEN' originally in
this thread, I still like the idea. The reason is that I prefer to #define
/all/ magic numbers in one place per file, so if this were my code, I
would have used the macro in the structure declaration, but still referred
to the size of the member as `sizeof president->name' later.

Martin
Nov 13 '05 #19
Daniel Haude wrote:
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok?

president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.

--Daniel


The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17

Thank you for your post.

--Steve

Nov 13 '05 #20
"Mark A. Odell" wrote:

"Simon Biber" <sb****@optushome.com.au> wrote in
news:3f**********************@news.optusnet.com.au :
strncat(president->name, "George Washington", PRES_NAME_LEN - 1);


Question on style here. How does PRES_NAME_LEN improve readability versus
the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.


It doesn't clarify the struct declaration. However,
elsewhere in the code we find things like the above-mentioned

strncat(president->name, "George Washington",
PRES_NAME_LEN - 1);

.... and this "spelling" of the third argument is superior to
a bare `24' or even `25 - 1' for the simple reason that it's
easier to alter the program to accommodate "George Herbert
Walker Bush" (26 letters, plus terminating '\0'): just change
the #define and all your worries are over. No need to go
groveling through the code looking for all occurrences of
`24' and `25' and trying to figure which need changing.

To my taste, though, it's still not a good solution. If
you come upon this strncat() call in the middle of some code
somewhere, how can you tell that `president->name' is in fact
an array of `PRES_NAME_LEN' characters? To me, the name
suggests that the array should have `PRES_NAME_LEN+1' elements,
but the main point would be the same even with a less equivocal
identifier: How do you know that the coder used the manifest
constant associated with `president->name' and not with some
other array altogether? The situation is analogous to the
oft-deprecated

ptr = malloc(sizeof(struct header_type_6));

.... where there's no immediate confirmation that the coder has
passed the correct type to `sizeof'.

The recommended cure for the malloc case is to write

ptr = malloc(sizeof *ptr);

.... and I'd suggest that the cure for the strncat() case should
be similar:

strncat(president->name, "George Washington",
sizeof president->name - 1);

No worries about whether the argument should be `PRES_NAME_LEN'
or `PRES_NAME_LEN - 1' or perhaps `NAME_BUFFER_SIZE - 1', and
the correctness can be established by purely local inspection.

"Almost established," anyhow, because the coder needs to
know that `president->name' is an actual array and not a pointer
to the start of an array elsewhere. But that's a burden that
C coders shoulder pretty much all the time anyhow, and we should
by now be accustomed to and wary of it.

Summary: `sizeof' is your friend most of the time, and you
should enjoy that friendship whenever it's offered.

--
Er*********@sun.com
Nov 13 '05 #21
Steve Zimmerman wrote:

Daniel Haude wrote:
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok?

president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.

--Daniel


The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17


Oh, dear. They also void main(). That website seems to be living up to its
name.

--
Tim Hagan
Nov 13 '05 #22
Martin Dickopp <ex*************@zero-based.org> wrote in
news:bj*************@news.t-online.com:
Question on style here. How does PRES_NAME_LEN improve readability
versus the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.


Although I'm not the person who suggested `PRES_NAME_LEN' originally in
this thread, I still like the idea. The reason is that I prefer to
#define /all/ magic numbers in one place per file, so if this were my
code, I would have used the macro in the structure declaration, but
still referred to the size of the member as `sizeof president->name'
later.


Fair enough.

--
- Mark ->
--
Nov 13 '05 #23
Eric Sosman <Er*********@sun.com> wrote in news:3F***************@sun.com:
"Mark A. Odell" wrote:
Question on style here. How does PRES_NAME_LEN improve readability
versus the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.
It doesn't clarify the struct declaration. However,
elsewhere in the code we find things like the above-mentioned


[snip]
Summary: `sizeof' is your friend most of the time, and you
should enjoy that friendship whenever it's offered.


In the end, do I take it that you agree with me? That is, to use the
sizeof on the array and not create a manifest constant? I appreciate
Martin's desire to put all magic numbers in one place however. I might
amend this to "comment" all my magic numbers w/ a manifest constant, use
them in the definition of the size of the array, but then never use them
in the code again using only sizeof arrayname. How does this sound?

--
- Mark ->
--
Nov 13 '05 #24
"Mark A. Odell" wrote:

Eric Sosman <Er*********@sun.com> wrote in news:3F***************@sun.com:
"Mark A. Odell" wrote:
Question on style here. How does PRES_NAME_LEN improve readability
versus the orignal

struct pres {
char name[25];
struct pres *next;
};

if we use sizeof president->name instead of PRES_NAME_LEN? I see the
manifest constant as extra work without real additional clarity.
It doesn't clarify the struct declaration. However,
elsewhere in the code we find things like the above-mentioned


[snip]
Summary: `sizeof' is your friend most of the time, and you
should enjoy that friendship whenever it's offered.


In the end, do I take it that you agree with me? That is, to use the
sizeof on the array and not create a manifest constant?


It certainly seems we agree. There remains the problem
of an "array" that's actually a pointer (perhaps by virtue of
being passed as a function argument), but them's the breaks.
I appreciate
Martin's desire to put all magic numbers in one place however. I might
amend this to "comment" all my magic numbers w/ a manifest constant, use
them in the definition of the size of the array, but then never use them
in the code again using only sizeof arrayname. How does this sound?


Personally, I don't think I'd find it helpful. YMMV.

However, if you've got several arrays that are all supposed
to have the same number of elements, it may make sense to use
just one manifest constant for all the declarations even if you
go on to use `sizeof' everywhere else:

#define WIDE 20
#define TALL 50
int matrix[TALL][WIDE];
int row_totals[TALL];
int row_maxima[TALL];
int col_totals[WIDE];
int col_maxima[WIDE];

It's possible to eliminate the manifest constants:

int matrix[50][20];
int row_totals[ sizeof matrix / sizeof matrix[0] ];
int row_maxima[ sizeof matrix / sizeof matrix[0] ];
int col_totals[ sizeof matrix[0] / sizeof matrix[0][0] ];
int col_maxima[ sizeof matrix[0] / sizeof matrix[0][0] ];

.... but to my taste this is surpassingly ugly, and not an aid
to clarity. (Confession: When I first wrote this, I got it
backwards.)

--
Er*********@sun.com
Nov 13 '05 #25
In article <3F**************@sonic.net>, st******@sonic.net says...
The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17


Suffice it to say that you shouldn't believe everything
you find on that site.
--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #26
August Derleth wrote:

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote

Who taught you to cast malloc()'s return value?


It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.

Common practice indeed, because it's REQUIRED in C++.


Brian Rodenborn
Nov 13 '05 #27
In article <3F***************@boeing.com>, no*****@boeing.com says...
The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17


Oh, dear. They also void main(). That website seems to be living up to its
name.


I downloaded the source code archives posted there for the "book form" of
this website. It is filled with similar problems. I sent an email to the
author about some of it, I don't know how it will turn out.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #28
In article <3F***************@company.com>,
Default User <fi********@company.com> wrote:
August Derleth wrote:

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote

> Who taught you to cast malloc()'s return value?


It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.

Common practice indeed, because it's REQUIRED in C++.


'Tis? I thought using new and delete was also an option.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

Generally speaking, undefined behavior invokes nethack, not Quake.
--Ben Pfaff in comp.lang.c
Nov 13 '05 #29
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote in
<bj**********@tabloid.uwaterloo.ca>:
In article <3F***************@company.com>,
Default User <fi********@company.com> wrote:
August Derleth wrote:

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote

> Who taught you to cast malloc()'s return value?

It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.

Common practice indeed, because it's REQUIRED in C++.


'Tis? I thought using new and delete was also an option.


The latter has no impact on the requirement to explicitly
cast malloc's return value in (here off-topic) C++.

Irrwahn
--
Sig. Sic.
Nov 13 '05 #30
In article <7j********************************@4ax.com>,
Irrwahn Grausewitz <ir*****@freenet.de> wrote:
dj******@csclub.uwaterloo.ca (Dave Vandervies) wrote in
<bj**********@tabloid.uwaterloo.ca>:
In article <3F***************@company.com>,
Default User <fi********@company.com> wrote:
August Derleth wrote:

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote

> Who taught you to cast malloc()'s return value?

It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.
Common practice indeed, because it's REQUIRED in C++.


'Tis? I thought using new and delete was also an option.


The latter has no impact on the requirement to explicitly
cast malloc's return value in (here off-topic) C++.


Butbutbut... if you avoid using malloc at all, there's no need to
explicitly cast its return value.

I think it's time for me to give up on this thread.
dave
[pokes the sigmonster with a pointy stick]

--
Dave Vandervies dj******@csclub.uwaterloo.ca

I don't know if I'm being pedantic here or just being silly.
--Joona I Palaste in comp.lang.c
Nov 13 '05 #31
Dave Vandervies wrote:
In Irrwahn Grausewitz:
Dave Vandervies wrote:

'Tis? I thought using new and delete was also an option.


The latter has no impact on the requirement to explicitly
cast malloc's return value in (here off-topic) C++.


Butbutbut... if you avoid using malloc at all, there's no need to
explicitly cast its return value.


You are allowed to smoke at the petrol station
because you rode in on a bicycle? :o)

<SNIP>

--
Sig. Sic.
Nov 13 '05 #32
In article <1i********************************@4ax.com>,
Irrwahn Grausewitz <ir*****@freenet.de> wrote:
Dave Vandervies wrote:
In Irrwahn Grausewitz:
Dave Vandervies wrote:

'Tis? I thought using new and delete was also an option.

The latter has no impact on the requirement to explicitly
cast malloc's return value in (here off-topic) C++.


Butbutbut... if you avoid using malloc at all, there's no need to
explicitly cast its return value.


You are allowed to smoke at the petrol station
because you rode in on a bicycle? :o)


No, more like if you avoid petrol stations and other areas where you'd
find flammable vapors (which is a sensible thing to do if you're riding
a bicycle), you don't have to avoid smoking for fire-safety reasons.
dave
(Look! I changed the subject, so it's a different thread that I don't
have to give up on!)

--
Dave Vandervies dj******@csclub.uwaterloo.ca

I don't know if I'm being pedantic here or just being silly.
--Joona I Palaste in comp.lang.c
Nov 13 '05 #33
Steve Zimmerman <st******@sonic.net> wrote in message news:<3F**************@sonic.net>...
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>
Huh? This isn't a standard header. Besides, the prototype for
malloc() is in stdlib.c anyway.
#include <string.h>

int main()
{
struct pres {
char name[25];
struct pres *next;
};

struct pres *president;

president = (struct pres *)malloc(sizeof(struct pres));
Don't cast the return value of malloc in C. First of all, you don't
need to; malloc() returns a void*, which is implicitly converted to
the target pointer type. Secondly, doing so will suppress a
diagnostic if you forget to include stdlib.h or otherwise don't have a
prototype for malloc() in scope.

*ALWAYS* check the return value of malloc() before attempting to use
it.

BTW, you can use sizeof *president instead of sizeof (struct pres) as
an argument to malloc(). That way, if the base type of president ever
changes, you don't have to hack all your calls to malloc().

strcpy(president->name, "George Washington");
It's a good idea to protect against potential buffer overruns; don't
just blindly assume that your target is always big enough to hold the
string you're copying. Even though you *know* that it is in this
particular case, it's a good idea to put in sanity checks anyway.
president->next = (struct pres *)malloc(sizeof(struct pres));

Same rant as above re: casting the return value of malloc().
printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);
Use the %p conversion specifier to print pointer values, not %i.

return 0;
}

################################################## #################

--Steve


I know you're just experimenting, but when you create abstract data
types like this, it's a good idea to create an abstract interface for
them as well. Instead of calling malloc() and strcpy() directly from
the application code, create a set of functions that encapsulate all
the operations necessary to create and manage objects of that type.
For example (off the top of my head, untested, all the usual caveats
apply):

struct pres *newPresident (char *name)
{
struct pres *p;

p = malloc (sizeof *p);
if (p)
{
p->next = NULL;
if (name)
{
if (strlen (name) > sizeof p->name - 1)
printf ("Name too long -- truncating...\n");

strncpy (p->name, name, sizeof p->name - 1);
p->name[sizeof p->name - 1] = 0;
}
}

return p;
}

void addToList (struct pres *p, struct pres *head)
{
struct pres *cur;
assert (head != NULL);

cur = head;
while (cur->next)
cur = cur->next;

cur->next = p;
}

void printEntry (struct pres *p)
{
printf ("addr = %p\nname = %s\nnext = %p\n\n",
p, p != NULL ? p->name : "(null)",
p != NULL ? p->next : "(null)");
}

void printList (struct pres *head)
{
struct pres *cur = head->next;
while (cur)
{
printEntry (cur);
cur = cur->next;
}
}

And a very crude example of these functions in use:

int main (void)
{
struct pres head, *newp;

newp = newPresident ("George Washington");
if (newp)
addToList (newp, &head);

newp = newPresident ("Abraham Lincoln");
if (newp)
addToList (newp, &head);

newp = newPresident ("James K. Polk");
if (newp)
addToList (newp, &head);

printList (&head);

return 0;
}
Nov 13 '05 #34
John Bode <jo*******@my-deja.com> wrote:
Steve Zimmerman <st******@sonic.net> wrote in message news:<3F**************@sonic.net>...
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>
Huh? This isn't a standard header. Besides, the prototype for
malloc() is in stdlib.c anyway.
ITYM: stdlib.h

<snip>
printf("The first structure has been created:\n");
printf("president->name = %s\n", president->name);
printf("next structure address = %i\n", president->next);

Use the %p conversion specifier to print pointer values, not %i.


....and cast your pointer to (void *), as that is what %p expects.

Alex

Nov 13 '05 #35
Randy Howard wrote:

<other attrs snipped>
> http://www.c-for-dummies.com/lessons/chapter.17


Oh, dear. They also void main(). That website seems to be living up to
its name.


I downloaded the source code archives posted there for the "book form" of
this website. It is filled with similar problems. I sent an email to the
author about some of it, I don't know how it will turn out.


It is unlikely to turn out well. Last time I checked his web site, he seemed
to be downright proud of his rebellious stance on matters such as void
main(). He is clearly aware of the issue, and chooses (metaphorically) to
clap his hands over his ears and shout "Nah nah I can't hear you nah nah".

Heaven knows why.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #36
Dave Vandervies wrote:

In article <3F***************@company.com>,
Default User <fi********@company.com> wrote:
August Derleth wrote:

Daniel Haude <ha***@physnet.uni-hamburg.de> wrote

> Who taught you to cast malloc()'s return value?

It's common practice in C++, one of the differences between that
language and C and one of the reasons experienced C programmers blanch
at the meaningless term 'C/C++'.

Common practice indeed, because it's REQUIRED in C++.


'Tis? I thought using new and delete was also an option.

What do new and delete have to do with whether you cast the return of
malloc()?


Brian Rodenborn
Nov 13 '05 #37
Dave Vandervies wrote:
Butbutbut... if you avoid using malloc at all, there's no need to
explicitly cast its return value.

What return value? If you don't use it, then there isn't one.


Brian Rodenborn
Nov 13 '05 #38
In article <3F**************@company.com>,
Default User <fi********@company.com> wrote:
Dave Vandervies wrote:
Butbutbut... if you avoid using malloc at all, there's no need to
explicitly cast its return value.

What return value? If you don't use it, then there isn't one.


Fine, then, the value it would have returned had you used it.

(I should know better than to get myself into this sort of thing by now.)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca

I don't know if I'm being pedantic here or just being silly.
--Joona I Palaste in comp.lang.c
Nov 13 '05 #39
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Randy Howard wrote:

<other attrs snipped>
> http://www.c-for-dummies.com/lessons/chapter.17

Oh, dear. They also void main(). That website seems to be living up to
its name.


I downloaded the source code archives posted there for the "book form" of
this website. It is filled with similar problems. I sent an email to the
author about some of it, I don't know how it will turn out.


It is unlikely to turn out well. Last time I checked his web site, he seemed
to be downright proud of his rebellious stance on matters such as void
main(). He is clearly aware of the issue, and chooses (metaphorically) to
clap his hands over his ears and shout "Nah nah I can't hear you nah nah".


Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."

He did mention that the books were written before the standard and are
being revamped right now, so some of the items might be clarified in the
next edition.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #40
Randy Howard wrote:
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Last time I checked his web site, he
seemed to be downright proud of his rebellious stance on matters such as
void main(). He is clearly aware of the issue, and chooses
(metaphorically) to clap his hands over his ears and shout "Nah nah I
can't hear you nah nah".
Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."


Firstly, that's not the point. The behaviour is undefined, and he shouldn't
be promulgating egregious undefined behaviour.

Secondly, I have searched the Google archives, and could find only one
article by Dan Gookin in comp.lang.c, which didn't mention main() at all.

Thirdly, several such hardware systems have been identified (did the author
think to check Google?), and it's trivial to construct a software system
that could crash on void main, even on a Microsoft platform:

@echo off
voidmainprg.exe
if errorlevel 2 goto spacecadet
if errorlevel 1 goto failed
echo It worked.
goto end
:spacecadet
echo Here we go...
rem insert your favourite Windows exploit here
spacecadet.exe
:failed
echo It failed.
:end


He did mention that the books were written before the standard


Huh? It was published in 1997, almost a decade /after/ the Standard.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 13 '05 #41
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Randy Howard wrote:
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Last time I checked his web site, he
seemed to be downright proud of his rebellious stance on matters such as
void main(). He is clearly aware of the issue, and chooses
(metaphorically) to clap his hands over his ears and shout "Nah nah I
can't hear you nah nah".
Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."


Firstly, that's not the point. The behaviour is undefined, and he shouldn't
be promulgating egregious undefined behaviour.


Just let me say that I wasn't defending it, I was just passing the info
along.
Huh? It was published in 1997, almost a decade /after/ the Standard.


I think he may have been referring to C99 (I know, I know...).

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #42
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Randy Howard wrote:
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Last time I checked his web site, he
seemed to be downright proud of his rebellious stance on matters such as
void main(). He is clearly aware of the issue, and chooses
(metaphorically) to clap his hands over his ears and shout "Nah nah I
can't hear you nah nah".
Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."


Firstly, that's not the point. The behaviour is undefined, and he shouldn't
be promulgating egregious undefined behaviour.


Just let me say that I wasn't defending it, I was just passing the info
along.
Huh? It was published in 1997, almost a decade /after/ the Standard.


I think he may have been referring to C99 (I know, I know...).

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com
Nov 13 '05 #43
Richard Heathfield <do******@address.co.uk.invalid> writes:
Randy Howard wrote:
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Last time I checked his web site, he
seemed to be downright proud of his rebellious stance on matters such as
void main(). He is clearly aware of the issue, and chooses
(metaphorically) to clap his hands over his ears and shout "Nah nah I
can't hear you nah nah".
Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."

[...]
Thirdly, several such hardware systems have been identified (did the author
think to check Google?), and it's trivial to construct a software system
that could crash on void main, even on a Microsoft platform:


This has actually happend to me in a real situation. It was a rather long
and rather important script on a Unix system, and like all my scripts, it
was written in such a way that it immediately terminates if any program
reports an unsuccessful exit status (<OT> `set -e' in bash </OT>).

This script sometimes failed mysteriously, under hard-to-reproduce
circumstances. After much tinkering I found that one of the programs I
called used `void main' and returned a random exit status.

Martin
Nov 13 '05 #44
Steve Zimmerman <st******@sonic.net> wrote in message news:<3F**************@sonic.net>...
Daniel Haude wrote:
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok?
president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.

--Daniel


The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17


gak.

There's a reason that "for-dummies" type books and Web sites have a
bad reputation. Last time I checked there were on the order of 7.3354
x 10^13* books and Web sites purporting to teach C, and maybe 10 or
12** of them aren't crap. Although this isn't the worst I've ever
seen (Schildt's "C The Complete Reference", 1st ed. will forever hold
that particular honor), he definitely teaches some bad habits.

You can find a list of recommended, authoritative references for
introductory C programming at the following site:

http://www.accu.org/bookreviews/publ...ginner_s_c.htm

* Okay, so maybe that's a *slight* exaggeration.
** That isn't.
Nov 13 '05 #45
Richard Heathfield <do******@address.co.uk.invalid> writes:
Randy Howard wrote:
In article <bj**********@hercules.btinternet.com>,
do******@address.co.uk.invalid says...
Last time I checked his web site, he
seemed to be downright proud of his rebellious stance on matters such as
void main(). He is clearly aware of the issue, and chooses
(metaphorically) to clap his hands over his ears and shout "Nah nah I
can't hear you nah nah".
Perhaps. The response I received was basically (paraphrasing) "Thank you,
but I have asked on comp.lang.c about this in the past, and nobody could
point to a single system that would actually crash with void main()."

[...]
Thirdly, several such hardware systems have been identified (did the author
think to check Google?), and it's trivial to construct a software system
that could crash on void main, even on a Microsoft platform:


This has actually happend to me in a real situation. It was a rather long
and rather important script on a Unix system, and like all my scripts, it
was written in such a way that it immediately terminates if any program
reports an unsuccessful exit status (<OT> `set -e' in bash </OT>).

This script sometimes failed mysteriously, under hard-to-reproduce
circumstances. After much tinkering I found that one of the programs I
called used `void main' and returned a random exit status.

Martin
Nov 13 '05 #46
[ snip ]
int main(void)
{
int wrong_return_type_malloc(size_t);
int *p;
...
p = (int *) wrong_return_type_malloc( foo );
...
}

Now, look at that cast. In the current program, it's *hiding*
the error from the compiler. (Remember that a cast always says
to the compiler, "Be quiet and let me do this my way, right or
wrong.") So this program will compile without diagnostics, and
run, and crash, because we're expecting 'malloc' to return an
'int' (by mechanism A) when really it's returning a 'void *' (by
mechanism B). Really, some machines will actually use different
registers for different types, and so on.
So our program crashes at runtime -- or, insidiously, doesn't
crash until the day of the big demo, when the boss is around.

So can i do something like this :
typedef struct mystr{
char *p;
int i[10];
}my_str;

int main (void)
{
void *data;
my_str *use;

data = malloc ( sizeof my_str);
use = ( my_str*)data ;
use->i[0] = 3333;

free ( use );
return 0;
}
So, everytime i need to use 'malloc', get its return value in a '
void* ' variable and then use this variable to cast according to my
requirement which can be of struct/int/char type. ? Is this correct.

Also what actually happens if variable 'p' is of my_str type.

p = malloc ( *p ); /* which seems to be the most suggested option ! */

- Ravi

[ snip ]
Nov 13 '05 #47
Dave Vandervies wrote:
What return value? If you don't use it, then there isn't one.
Fine, then, the value it would have returned had you used it.


Great, now you are arguing my side of the question.
(I should know better than to get myself into this sort of thing by now.)

How about, don't make dopey statements? Your premise was ludicrous.


Brian Rodenborn
Nov 13 '05 #48
Steve Zimmerman <st******@sonic.net> wrote in message news:<3F**************@sonic.net>...
Daniel Haude wrote:
On Wed, 03 Sep 2003 14:23:55 GMT,
Steve Zimmerman <st******@sonic.net> wrote
in Msg. <3F**************@sonic.net>
This program compiles fine, but are there any hidden dangers
in it, or is it ok?
president = (struct pres *)malloc(sizeof(struct pres));


Who taught you to cast malloc()'s return value? Others have pointed out
the reasons why this is bad; I just want to know where you got the idea
from.

--Daniel


The honest answer is, "No one taught me to cast malloc()'s return value.
I've never written any code using malloc." See

http://www.c-for-dummies.com/lessons/chapter.17


gak.

There's a reason that "for-dummies" type books and Web sites have a
bad reputation. Last time I checked there were on the order of 7.3354
x 10^13* books and Web sites purporting to teach C, and maybe 10 or
12** of them aren't crap. Although this isn't the worst I've ever
seen (Schildt's "C The Complete Reference", 1st ed. will forever hold
that particular honor), he definitely teaches some bad habits.

You can find a list of recommended, authoritative references for
introductory C programming at the following site:

http://www.accu.org/bookreviews/publ...ginner_s_c.htm

* Okay, so maybe that's a *slight* exaggeration.
** That isn't.
Nov 13 '05 #49
[ snip ]
int main(void)
{
int wrong_return_type_malloc(size_t);
int *p;
...
p = (int *) wrong_return_type_malloc( foo );
...
}

Now, look at that cast. In the current program, it's *hiding*
the error from the compiler. (Remember that a cast always says
to the compiler, "Be quiet and let me do this my way, right or
wrong.") So this program will compile without diagnostics, and
run, and crash, because we're expecting 'malloc' to return an
'int' (by mechanism A) when really it's returning a 'void *' (by
mechanism B). Really, some machines will actually use different
registers for different types, and so on.
So our program crashes at runtime -- or, insidiously, doesn't
crash until the day of the big demo, when the boss is around.

So can i do something like this :
typedef struct mystr{
char *p;
int i[10];
}my_str;

int main (void)
{
void *data;
my_str *use;

data = malloc ( sizeof my_str);
use = ( my_str*)data ;
use->i[0] = 3333;

free ( use );
return 0;
}
So, everytime i need to use 'malloc', get its return value in a '
void* ' variable and then use this variable to cast according to my
requirement which can be of struct/int/char type. ? Is this correct.

Also what actually happens if variable 'p' is of my_str type.

p = malloc ( *p ); /* which seems to be the most suggested option ! */

- Ravi

[ snip ]
Nov 13 '05 #50

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

Similar topics

2
by: Steve Zimmerman | last post by:
Esteemed contributors to clc: Thank you for all the responses. Experiments 2 and 3 below are identical, except that experiment 2 does not call free(), while experiment 3 does. With such a...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
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...

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.