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

is a pointer memset to zero necessarily eqal to NULL?

Hi all

Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
assert( NULL == (void*)ptr );
}

Thanks,
viza
Jul 5 '08 #1
32 13445
In article <3I*******************@newsfe18.ams2>,
viza <to******@gm-il.com.obviouschange.invalidwrote:
>Is this assertion guaranteed?
No, none of them are. There is no necessary relation between a
pointer with all bits zero and a null pointer.

On the other hand, it's true on all widely-used platforms.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 5 '08 #2
>Is this assertion guaranteed?
>{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}
No. It is not guaranteed that the internal representation of a
null pointer is 0xdeadbeef, even on a machine with 32-bit pointers.
But it might be.
>What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
No.
assert( NULL == (void*)ptr );
No.
>}
Jul 5 '08 #3
On Sat, 05 Jul 2008 17:52:40 -0500, Gordon Burditt wrote:
>>Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

No. It is not guaranteed that the internal representation of a null
pointer is 0xdeadbeef, even on a machine with 32-bit pointers. But it
might be.
Is there then some library function to set an array of objects of
size 1 to the same value? Something like wmemset() but for things the
size of pointers, or even larger structs?

Thanks,
viza
Jul 5 '08 #4
viza wrote:
Hi all

Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
assert( NULL == (void*)ptr );
}

None of those.

These assertions are guaranteed:
{
void *vptr = 0;
sometype *ptr = 0;

assert( NULL == vptr );
assert( NULL == 0 );
assert( 0 == vptr );
assert( ptr == vptr );
}

--
pete
Jul 5 '08 #5
In article <lp******************************@earthlink.com> ,
pete <pf*****@mindspring.comwrote:
>viza wrote:
>Hi all

Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
assert( NULL == (void*)ptr );
}


None of those.

These assertions are guaranteed:
{
void *vptr = 0;
sometype *ptr = 0;

assert( NULL == vptr );
assert( NULL == 0 );
assert( 0 == vptr );
assert( ptr == vptr );
}

--
pete
As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

char *peteIsMoron = "Yes, it is almost beyond belief what a turd he is";
char *yup = peteIsMoron;
assert(yup == peteIsMoron);

Jul 5 '08 #6
viza wrote:
On Sat, 05 Jul 2008 17:52:40 -0500, Gordon Burditt wrote:
>>Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}
No. It is not guaranteed that the internal representation of a null
pointer is 0xdeadbeef, even on a machine with 32-bit pointers. But it
might be.

Is there then some library function to set an array of objects of
size 1 to the same value? Something like wmemset() but for things the
size of pointers, or even larger structs?
There's no such function in the standard library. You
can write a simple loop, or you can use memcpy() repeatedly
to copy 1,2,4,8,... instances, or you can use memset() or
calloc() to set everything to all-bits-zero and brazen it out.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jul 6 '08 #7
Kenny McCormack wrote:
In article <lp******************************@earthlink.com> ,
pete <pf*****@mindspring.comwrote:
>viza wrote:
>>Hi all

Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}

What about these ones?
{
sometype *ptr;
memset( & ptr, 0, sizeof ptr);
assert( (sometype*)NULL == ptr );
assert( NULL == (void*)ptr );
}

None of those.

These assertions are guaranteed:
{
void *vptr = 0;
sometype *ptr = 0;

assert( NULL == vptr );
assert( NULL == 0 );
assert( 0 == vptr );
assert( ptr == vptr );
}

--
pete

As are these (and are equally relevant):

int three = 3;
assert(threee == 3);
The difference between integer constants
and integer variables in that context, is an interesting point.

{
int zero = 0;
char *ptr = 0;

assert( 0 == zero );
assert( 0 == ptr );

The above two assertions are guaranteed to be true,
but the next one below,
is guaranteed to generate a diagnostic message.

assert( ptr == zero );
}

--
pete
Jul 6 '08 #8
In article <kb******************************@earthlink.com> ,
pete <pf*****@mindspring.comwrote:
....
>The above two assertions are guaranteed to be true, but the next one
below, is guaranteed to generate a diagnostic message.

assert( ptr == zero );
}

--
pete
Even more to the point:

#define three 3
assert(three == 3);

Jul 6 '08 #9
Kenny McCormack wrote:
In article <kb******************************@earthlink.com> ,
pete <pf*****@mindspring.comwrote:
...
>The above two assertions are guaranteed to be true, but the next one
below, is guaranteed to generate a diagnostic message.

assert( ptr == zero );
}

--
pete

Even more to the point:

#define three 3
assert(three == 3);
The point is that
even if memset could be used to portably generate a null pointer
(which it can't),
it would be an overly complicated way to do it;
overly complicated to the point of being the wrong way.

--
pete
Jul 6 '08 #10
viza wrote:
Is this assertion guaranteed?
{
void *vptr;
memset( & vptr, 0, sizeof vptr);
assert( NULL == vptr );
}
Have you tried reading the FAQ?

viza wrote:
Is there then some library function to set an array of
objects of size 1 to the same value?
Where does the size come into it?

Just use a loop...

static const struct foo foo_zero; /* zero initialised */
for (i = 0; i < N; i++)
array[i] = foo_zero;

--
Peter
Jul 6 '08 #11
Peter Nilsson <ai***@acay.com.auwrites:
[...]
viza wrote:
>Is there then some library function to set an array of
objects of size 1 to the same value?

Where does the size come into it?
It's not an entirely unreasable question. memset() lets you
copy a specified 1-byte value repeatedly into a target array.
A generalization of memset() that can copy an N-byte pattern
repeatedly in the same manner could be useful.

But since there is no such function in the standard library, the
best solution is ...
Just use a loop...

static const struct foo foo_zero; /* zero initialised */
for (i = 0; i < N; i++)
array[i] = foo_zero;
Though I'd probably declare foo_zero as:

static const struct foo foo_zero = { 0 };

It's exactly equivalent, but sometimes being a bit more explicit
can be a good thing.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 7 '08 #12
On 6 Jul, 00:51, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
In article <lp-dnd8phd0wmO3VnZ2dnUVZ_t7in...@earthlink.com>,
pete *<pfil...@mindspring.comwrote:
viza wrote:
Is this assertion guaranteed?
{
* void *vptr;
* memset( & vptr, 0, sizeof vptr);
* assert( NULL == vptr );
}
What about these ones?
{
* sometype *ptr;
* memset( & ptr, 0, sizeof ptr);
* assert( (sometype*)NULL == ptr );
* assert( NULL == (void*)ptr );
}
None of those.
These assertions are guaranteed:
{
* void *vptr = 0;
* sometype *ptr = 0;
* assert( NULL == vptr );
* assert( NULL == 0 );
* assert( 0 == vptr );
* assert( ptr == vptr );
}
As are these (and are equally relevant):

int three = 3;
assert(threee == 3);
Kenny is (probably on purpose) missing the point.
Although all-bits-zero may not be a null pointer
(and hence the memset() trick won't work)
all the asserts that pete quotes *do* work.

The 0 in the declarations can be thought of
as a null pointer constant. The FAQ discusses
this at length.

<snip rudeness>

Note: Kenny is a troll and shouldn't normally
be responded to.

--
Nick Keighley

I have found that all ugly things are made by those who strive to make
something beautiful and that all beautiful things are made by those
who
strive to make something useful.
-- Oscar Wilde
Jul 7 '08 #13
Nick Keighley said:
On 6 Jul, 00:51, gaze...@xmission.xmission.com (Kenny McCormack)
wrote:
>In article <lp-dnd8phd0wmO3VnZ2dnUVZ_t7in...@earthlink.com>,
pete <pfil...@mindspring.comwrote:
<snip>
>>
>These assertions are guaranteed:
{
void *vptr = 0;
sometype *ptr = 0;
assert( NULL == vptr );
assert( NULL == 0 );
assert( 0 == vptr );
assert( ptr == vptr );
}
>As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

Kenny is (probably on purpose) missing the point.
No, his assertion is simply wrong (probably because he can't type).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 7 '08 #14
In article <c0**********************************@m3g2000hsc.g ooglegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:
....
>As are these (and are equally relevant):

int three = 3;
assert(threee == 3);

Although all-bits-zero may not be a null pointer
(and hence the memset() trick won't work)
all the asserts that pete quotes *do* work.
Nobody disputes that. As are all of my asserts. The relevance is all
of equal value.
>The 0 in the declarations can be thought of
as a null pointer constant. The FAQ discusses
this at length.

<snip rudeness>

Note: Kenny is a troll and shouldn't normally
be responded to.
The response was normal for you.

Jul 7 '08 #15
Keith Thompson wrote:
Peter Nilsson <ai***@acay.com.auwrites:
[...]
>viza wrote:
>>Is there then some library function to set an array of
objects of size 1 to the same value?
Where does the size come into it?

It's not an entirely unreasable question. memset() lets you
copy a specified 1-byte value repeatedly into a target array.
A generalization of memset() that can copy an N-byte pattern
repeatedly in the same manner could be useful.
[...]
Here's one I wrote some years ago. It looks at first glance
like it would be murder on cache lines, TLB's, and the like, but
in testing on a few different machine architectures no such bad
effects have appeared.

#include <string.h>

void
fillmem(void *pdest, size_t sdest, const void *pfrom, size_t sfrom)
/*
* Fills the `sdest' bytes starting at `pdest' with copies of the
* `sfrom' bytes starting at `pfrom'. The final copy will be partial
* if `sfrom' does not divide `sdest'.
*/
{
if (sdest sfrom) {
/* Put one copy of the source pattern at the start of
* the destination.
*/
memcpy (pdest, pfrom, sfrom);
pfrom = pdest;
pdest = (char*)pdest + sfrom;
sdest -= sfrom;

/* Copy data from the beginning of the destination to the
* end, with each iteration doubling the amount copied.
*/
while (sdest sfrom) {
memcpy (pdest, pfrom, sfrom);
pdest = (char*)pdest + sfrom;
sdest -= sfrom;
sfrom += sfrom;
}
}

/* Fill the final (or only) piece of the destination.
*/
memcpy (pdest, pfrom, sdest);
}
--
Eric Sosman
es*****@ieee-dot-org.invalid
Jul 7 '08 #16
Hi

On Mon, 07 Jul 2008 08:35:12 -0400, Eric Sosman wrote:
Keith Thompson wrote:
>Peter Nilsson <ai***@acay.com.auwrites: [...]
>>viza wrote:
>>>Is there then some library function to set an array of objects of
size 1 to the same value?

Where does the size come into it?

It's not an entirely unreasable question. memset() lets you copy a
specified 1-byte value repeatedly into a target array. A generalization
of memset() that can copy an N-byte pattern repeatedly in the same
manner could be useful. [...]

Here's one I wrote some years ago. It looks at first glance
like it would be murder on cache lines, TLB's, and the like, but in
testing on a few different machine architectures no such bad effects
have appeared.
void
fillmem(void *pdest, size_t sdest, const void *pfrom, size_t sfrom)
/* Copy data from the beginning of the destination to the
* end, with each iteration doubling the amount copied. */
Well that is quite cunning. Not quite the fox appointed as professor of
cunning at oxford, but better than a loop.

If I was going to really squeeze it for every last drop of speed I would
do several loops of copying the system's largest words first, and then
use memcpy as above, once the call overhead was offset. Obviously that
would only be of use on systems where memcpy was faster than a raw loop
anyway.
Jul 7 '08 #17
On Jul 7, 12:42 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 6 Jul, 00:51, (Kenny the Troll)
<snip>
int three = 3;
assert(threee == 3);
first is 'three', second is 'threee'.
<snip>
Note: Kenny is a troll and shouldn't normally
be responded to.
So why did you reply to him?
Please just avoid replying to trolls.
Jul 7 '08 #18
viza wrote:
[... fill by repeated memcpy() with doubling sizes ...]
If I was going to really squeeze it for every last drop of speed I would
do several loops of copying the system's largest words first, and then
use memcpy as above, once the call overhead was offset. Obviously that
would only be of use on systems where memcpy was faster than a raw loop
anyway.
Two points, both of marginal topicality (since matters of
speed are implementation issues, not language issues):

First, the "call overhead" may well be zero, or close to it.
Compilers frequently generate in-line code for the simpler
library functions, sometimes using special instructions.

Second, it may well be slower to fill a large array by
copying its 1,2,4,8,...,(N/2)-element prefixes than by just
storing N copies with a straightforward loop. When told to
copy 1024 bytes, memcpy() can't know that they're really just
64 copies of the same 16-byte "atom," so it most likely must
go through the work of fetching 1024-16=1008 bytes it doesn't
actually need. These are the cache/TLB effects I'd worried
about, but they didn't seem to be a problem.

--
Er*********@sun.com
Jul 7 '08 #19
On 7 Jul, 19:24, vipps...@gmail.com wrote:
On Jul 7, 12:42 pm,Nick Keighley<nick_keighley_nos...@hotmail.com>
<snip>
Note: Kenny is a troll and shouldn't normally
be responded to.

So why did you reply to him?
Please just avoid replying to trolls.
because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

--
Nick Keighley

Jul 8 '08 #20
Nick Keighley wrote:
On 7 Jul, 19:24, vipps...@gmail.com wrote:
>On Jul 7, 12:42 pm,Nick Keighley<nick_keighley_nos...@hotmail.com>

<snip>
>>Note: Kenny is a troll and shouldn't normally
be responded to.
So why did you reply to him?
Please just avoid replying to trolls.

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

--
Nick Keighley
They are more worth than the posts from heathfield clique.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jul 8 '08 #21
jacob navia <ja***@nospam.comwrites:
Nick Keighley wrote:
[...]
>because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.
You can't possibly be serious.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 8 '08 #22
Keith Thompson said:
jacob navia <ja***@nospam.comwrites:
>Nick Keighley wrote:
[...]
>>because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

You can't possibly be serious.
Since there isn't a "heathfield clique", he's actually half-right if we
take him literally, because pete's posts are worth more than nothing.

But perhaps we shouldn't take him literally. Perhaps when he said
"heathfield clique" he actually means "the people in clc who know C". If
that's what he means, then I can only assume that (as usual?) he wrote
without thinking clearly about what he's saying, because a C group really
does need posts from people who know the C language, whereas it certainly
doesn't need ignorant flimflam from self-confessed trolls.

On point:

The representation of a null pointer may not be all-bits-zero, so memset
and calloc won't necessarily hand you null pointers. (Same applies to
floating point.) On the other hand, assigning 0 itself to a pointer object
does give you a null pointer value in that pointer object (and comparing
against 0 is equivalent to comparing against a null pointer). If
all-bits-zero isn't the native representation of a null pointer, compilers
are required to do some magic to make such assignments and comparisons
work correctly.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 8 '08 #23
In article <b8**********************************@e39g2000hsf. googlegroups.com>,
Nick Keighley <ni******************@hotmail.comwrote:
>On 7 Jul, 19:24, vipps...@gmail.com wrote:
>On Jul 7, 12:42 pm,Nick Keighley<nick_keighley_nos...@hotmail.com>

<snip>
Note: Kenny is a troll and shouldn't normally
be responded to.

So why did you reply to him?
Please just avoid replying to trolls.

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.
I doubt even the greenest of newbie would make that mistake.

Pete's stuff is obviously worthless; anyone can see that.

Jul 8 '08 #24
On 8 Jul 2008 at 8:40, Richard Heathfield wrote:
Perhaps when he said "heathfield clique" he actually means "the people
in clc who know C".
There really are no bounds to your arrogance, are there?

Jul 8 '08 #25
Antoninus Twink wrote:
On 8 Jul 2008 at 8:40, Richard Heathfield wrote:
>Perhaps when he said "heathfield clique" he actually means "the people
in clc who know C".

There really are no bounds to your arrogance, are there?
Well, it starts to look funny now, so it is not so bad as it could be
:-)
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
Jul 8 '08 #26
In article <sl******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 8 Jul 2008 at 8:40, Richard Heathfield wrote:
>Perhaps when he said "heathfield clique" he actually means "the people
in clc who know C".

There really are no bounds to your arrogance, are there?
Nope. None.

I think that's been pretty well established around here for quite some time.

Indeed.

Jul 8 '08 #27
In article <sl******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:
>On 8 Jul 2008 at 8:40, Richard Heathfield wrote:
>Perhaps when he said "heathfield clique" he actually means "the people
in clc who know C".

There really are no bounds to your arrogance, are there?
Nope. None.

I think that's been pretty well established around here for quite some time.

Indeed.

Jul 8 '08 #28
On Jul 8, 1:05*am, Keith Thompson <ks...@mib.orgwrote:
jacob navia <ja...@nospam.comwrites:
Nick Keighley wrote:
[...]
because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.
They are more worth than the posts from heathfield clique.

You can't possibly be serious.
No, he's just bitter because of his ongoing spat. I'm sure that he
does recognize Richard's ability (which is quite substantial) but his
animosity prevents a sensible reply here.
I guess that you also surmise as much and your answer is really
rhetorical. And while one is not supposed to answer a rhetorical
question, there are plenty of other faux-pas in this thread along the
same lines.
Jul 9 '08 #29
On Jul 8, 10:36 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 7 Jul, 19:24, vipps...@gmail.com wrote:
On Jul 7, 12:42 pm,Nick Keighley<nick_keighley_nos...@hotmail.com>

<snip>
Note: Kenny is a troll and shouldn't normally
be responded to.
So why did you reply to him?
Please just avoid replying to trolls.

because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.
Let it be. If the observer cares to know, he'll read more posts from
both and he'll decide accordingly.
Jul 9 '08 #30
user923005 wrote:
On Jul 8, 1:05*am, Keith Thompson <ks...@mib.orgwrote:
>jacob navia <ja...@nospam.comwrites:
Nick Keighley wrote:
[...]
>because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.
They are more worth than the posts from heathfield clique.

You can't possibly be serious.

No, he's just bitter because of his ongoing spat. I'm sure that he
does recognize Richard's ability (which is quite substantial) but his
animosity prevents a sensible reply here.
I guess that you also surmise as much and your answer is really
rhetorical. And while one is not supposed to answer a rhetorical
question, there are plenty of other faux-pas in this thread along the
same lines.
Was what Keith said even a question? Looks more like a statement to
me. :-)

Jul 9 '08 #31
santosh said:
user923005 wrote:
>On Jul 8, 1:05 am, Keith Thompson <ks...@mib.orgwrote:
>>jacob navia <ja...@nospam.comwrites:
Nick Keighley wrote:
[...]
because an observer unfamiliar with recent postings on this
ng might think pete and kenny's posts were of comparable worth.

They are more worth than the posts from heathfield clique.

You can't possibly be serious.

No, he's just bitter because of his ongoing spat. I'm sure that he
does recognize Richard's ability (which is quite substantial) but his
animosity prevents a sensible reply here.
I guess that you also surmise as much and your answer is really
rhetorical. And while one is not supposed to answer a rhetorical
question, there are plenty of other faux-pas in this thread along the
same lines.

Was what Keith said even a question? Looks more like a statement to
me. :-)
It was a rhetorical statement. :-)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 9 '08 #32
Kenny McCormack wrote:
In article <lp******************************@earthlink.com> ,
pete <pf*****@mindspring.comwrote:
>These assertions are guaranteed:
As are these (and are equally relevant):

int three = 3;
assert(threee == 3);
LOL!

I understand your point, and as always, you are wrong.

As is evidenced by your post,
the actual case is obviously that:

*Almost* any idiot can post an example
of a true assertion at will.

--
pete
Jul 9 '08 #33

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

Similar topics

69
by: Ken | last post by:
Hi all. When referring to a null pointer constant in C++, is there any reason to prefer using 0 over a macro called NULL that is defined to be 0? Thanks! Ken
5
by: Joe C | last post by:
I'm a hobbiest, and made the forray into c++ from non-c type languages about a year ago. I was "cleaning up" some code I wrote to make it more "c++ like" and have a few questions. I'm comfortable...
31
by: vp | last post by:
If I have a pointer char * p, is it correct to assign NULL to this pointer by: "memset( &p, 0, sizeof(p));" instead of "p = NULL;" The reason I ask is I have an array of structure of N...
35
by: tuko | last post by:
Hello kind people. Can someone explain please the following code? /* Create Storage Space For The Texture */ AUX_RGBImageRec *TextureImage; /* Line 1*/ /* Set The Pointer To NULL...
48
by: Foobarius Frobinium | last post by:
http://thelinuxlink.net/~fingolfin/pointer-guide Tell me what you think...
69
by: fieldfallow | last post by:
Hello all, Before stating my question, I should mention that I'm fairly new to C. Now, I attempted a small demo that prints out the values of C's numeric types, both uninitialised and after...
49
by: elmar | last post by:
Hi Clers, If I look at my ~200000 lines of C code programmed over the past 15 years, there is one annoying thing in this smart language, which somehow reduces the 'beauty' of the source code...
13
by: James Brown | last post by:
All, After reading the FAQ (Q 5.2) I see that: an "integral constant expression with the value 0" in a pointer context is converted to a null pointer at compile time. The FAQ goes on to say...
18
by: sam | last post by:
(newbie)Technically what's the difference between memset() and memcpy() functions?
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
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)...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
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....

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.