473,883 Members | 1,724 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

memset all bits to zero will let float/double to zero?

Hi, All
I am reading FAQ of this group. I have a question about this:
http://www.eskimo.com/~scs/C-faq/q7.31.html

It says:
"
p = malloc(m * n);
memset(p, 0, m * n);
The zero fill is all-bits-zero, and does not therefore guarantee useful null
pointer values (see section 5 of this list) or floating-point zero values.
"

but ieee754 defined float zero to be all-bits-zero.

Anyone can help to explain about this?

Thanks in advance.
Nov 14 '05
53 8256
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
This is generating a lot more discussion than it deserves.


And it is entirely due to your pointless remarks.

If all bits zero is an inconvenient representation for the null pointer on
a given platform, no implementor is going to use it and there is no point
in explaining how it could be used, anyway.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #41
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.or g> wrote:
This is generating a lot more discussion than it deserves.

Malcolm speculated upthread that on a hypothetical CPU that traps on
an attempt to load an illegal address, including all-bits-zero, into
an address register, a C implementation would have to use a
non-all-bits-zero value for the null pointer. I replied that, given a
couple of additional assumptions about the architecture, it still
could, and arguably should, use all-bits-zero for the null pointer.


I've seen you state that it could (and I agree), but I haven't seen you
arguing that it should. And IMO you'd need some pretty good arguments,
because sacrificing speed and safety just to cater for sloppy
programmers is rarely a good idea, IYAM.


My assumption was that there would be no performance penalty in using
data registers for any operations that are valid for null pointers.
And catering to sloppy programmers, unfortunately, can be an effective
way to sell more compilers.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #42
Da*****@cern.ch (Dan Pop) writes:
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
This is generating a lot more discussion than it deserves.
And it is entirely due to your pointless remarks.


Nonsense. I was merely responding to Malcolm's remarks about a
hypothetical architecture. He said that on a CPU where loading
all-bits-zero into an address register causes a trap, a C
implementation would have to use some other value for null pointers.
I pointed out that, given a few additional assumptions, an
implementation *could* use all-bits-zero for null pointers, and there
are some advantages in doing so. One is that it makes it easy to trap
attempts to dereference null pointers. Another is that it avoids
breaking existing code that incorrectly assumes a null pointer is
all-bits-zero. (You and I might consider this second point to be a
disadvantage, but the sales and marketing departments might differ.)

BTW, none of this is intended as a criticism of Malcom; it was nothing
more than a friendly correction.

The length of this thread is due to your apparent need to jump in and
refute your misinterpretati on of what I actually wrote.
If all bits zero is an inconvenient representation for the null pointer on
a given platform, no implementor is going to use it and there is no point
in explaining how it could be used, anyway.


I'm not convinced of that. There's still a lot of code out there that
passes null pointers to functions without prototypes, and that will
break if null pointers are anything other than all-bits-zero. An
implementer is faced with a choice: use a non-zero value, causing such
code to break (and, we might hope, be fixed), or cater to it and very
likely sell more compilers to users who don't have time to go back and
fix their old code. I'm not necessarily arguing that the second
choice is a good one, but it's one that some implementers might be
likely to make.

But that's really beside the point I was trying to make, which is that
trapping on loading all-bits-zero into an address register doesn't
necessarily make all-bits-zero an inconvenient representation for the
null pointer.

On a typical platform, all-bits-zero and all-bits-one are equally
valid choices for the null pointer. Any compiler implementer could
easily choose to use the latter. (It's not an option if there are
existing libraries that use all-bits-zero, but presumably the choice
is available for new architectures.) And yet, every system I'm
familiar with uses all-bits-zero for null pointers. (Yes, I know
there are a lot of systems I'm not familiar with.) I'm sure a lot of
that is inertia, but I would guess that catering to existing broken
code is part of the motivation for that.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #43
In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.or g> wrote:
I'm not convinced of that. There's still a lot of code out there that
passes null pointers to functions without prototypes, and that will
break if null pointers are anything other than all-bits-zero.
That kind of code would also break if arguments are passed on the stack,
and int and pointers have different sizes.
An
implementer is faced with a choice: use a non-zero value, causing such
code to break (and, we might hope, be fixed), or cater to it and very
likely sell more compilers to users who don't have time to go back and
fix their old code. I'm not necessarily arguing that the second
choice is a good one, but it's one that some implementers might be
likely to make.

But that's really beside the point I was trying to make, which is that
trapping on loading all-bits-zero into an address register doesn't
necessarily make all-bits-zero an inconvenient representation for the
null pointer.

On a typical platform, all-bits-zero and all-bits-one are equally
valid choices for the null pointer. Any compiler implementer could
easily choose to use the latter. (It's not an option if there are
existing libraries that use all-bits-zero, but presumably the choice
is available for new architectures.) And yet, every system I'm
familiar with uses all-bits-zero for null pointers. (Yes, I know
there are a lot of systems I'm not familiar with.) I'm sure a lot of
that is inertia, but I would guess that catering to existing broken
code is part of the motivation for that.

Nov 14 '05 #44
Keith Thompson <ks***@mib.or g> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.or g> wrote:
I replied that, given a
couple of additional assumptions about the architecture, it still
could, and arguably should, use all-bits-zero for the null pointer.
I've seen you state that it could (and I agree), but I haven't seen you
arguing that it should. And IMO you'd need some pretty good arguments,
because sacrificing speed and safety just to cater for sloppy
programmers is rarely a good idea, IYAM.


My assumption was that there would be no performance penalty in using
data registers for any operations that are valid for null pointers.


That is, data registers must be used for every possible operation except
dereferencing and comparison for order (there's no exception for
equality comparisons!), if there is even a small chance of any operand
being a null pointer. I don't think that such an architecture is likely
to even have pointer registers - under those constraints, they're nearly
useless.
And catering to sloppy programmers, unfortunately, can be an effective
way to sell more compilers.


Ah, well, that's the difference between "should" and "will have to".
Unfortunately.

Richard
Nov 14 '05 #45
In article <40************ ****@news.indiv idual.net>,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Keith Thompson <ks***@mib.or g> wrote:
rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:
Keith Thompson <ks***@mib.or g> wrote:
> I replied that, given a
> couple of additional assumptions about the architecture, it still
> could, and arguably should, use all-bits-zero for the null pointer.

I've seen you state that it could (and I agree), but I haven't seen you
arguing that it should. And IMO you'd need some pretty good arguments,
because sacrificing speed and safety just to cater for sloppy
programmers is rarely a good idea, IYAM.


My assumption was that there would be no performance penalty in using
data registers for any operations that are valid for null pointers.


That is, data registers must be used for every possible operation except
dereferencing and comparison for order (there's no exception for
equality comparisons!), if there is even a small chance of any operand
being a null pointer. I don't think that such an architecture is likely
to even have pointer registers - under those constraints, they're nearly
useless.


Address registers could be used for any kind of pointer arithmetic,
which I think is quite common. And of course you could use the address
registers for anything if you can prove that a null pointer will lead to
undefined behavior somewhere along the line; I think that will be quite
common as well.
Nov 14 '05 #46
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
Da*****@cern.c h (Dan Pop) writes:

The length of this thread is due to your apparent need to jump in and
refute your misinterpretati on of what I actually wrote.
Since I wasn't the only one to "misinterpr et" what you wrote, the guilty
party must be searched somewhere else.
If all bits zero is an inconvenient representation for the null pointer on
a given platform, no implementor is going to use it and there is no point
in explaining how it could be used, anyway.


I'm not convinced of that. There's still a lot of code out there that
passes null pointers to functions without prototypes, and that will
break if null pointers are anything other than all-bits-zero.


You're badly confusing null pointers and the null pointer constant.
There is absolutely nothing wrong with passing a null pointer to a
non-prototyped function, regardless of the representation of the null
pointer.

Passing 0 to a non-prototyped function expecting a pointer is and has
*always* been an error. Read the standard. Read K&R1.
But that's really beside the point I was trying to make, which is that
trapping on loading all-bits-zero into an address register doesn't
necessarily make all-bits-zero an inconvenient representation for the
null pointer.


It does, every time address registers have different properties than
data registers. And even otherwise, as it puts a greater pressure on
the data registers. If the architecture has address registers, there
must be a *good* reason for that and using data registers instead for
pointer operations is defeating that good reason.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #47
Da*****@cern.ch (Dan Pop) writes:
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
Da*****@cern.c h (Dan Pop) writes: [snip]
If all bits zero is an inconvenient representation for the null pointer on
a given platform, no implementor is going to use it and there is no point
in explaining how it could be used, anyway.


I'm not convinced of that. There's still a lot of code out there that
passes null pointers to functions without prototypes, and that will
break if null pointers are anything other than all-bits-zero.


You're badly confusing null pointers and the null pointer constant.
There is absolutely nothing wrong with passing a null pointer to a
non-prototyped function, regardless of the representation of the null
pointer.

Passing 0 to a non-prototyped function expecting a pointer is and has
*always* been an error. Read the standard. Read K&R1.


Yes, I meant null pointer constants. I didn't badly confuse them; I
made a minor error.

Yes, passing 0 (or NULL, if it's #defined as 0) to a non-prototyped
function expecting a pointer is an error. The fact remains that there
is code in the real world that makes this error, and happens to work
as expected on platforms where pointers are the same size as int and
the null pointer has the same representation as (int)0.

Dan, did you really think that I don't know already this? I've
written enough here about null pointers and null pointer constants
that it should be pretty obvious that I do understand this stuff
reasonably well. If I type "null pointers" when "null pointer
constants" would make more sense, a reasonable reader would assume I
made a minor mistake, not that I have no idea what I'm talking about.
But that's really beside the point I was trying to make, which is that
trapping on loading all-bits-zero into an address register doesn't
necessarily make all-bits-zero an inconvenient representation for the
null pointer.


It does, every time address registers have different properties than
data registers. And even otherwise, as it puts a greater pressure on
the data registers. If the architecture has address registers, there
must be a *good* reason for that and using data registers instead for
pointer operations is defeating that good reason.


I didn't think about the hypothetical CPU architecture to that level
of detail, because I was only trying to make a minor point about
what's possible.

I don't currently have convenient access to 68k machine code, but the
68k does have separate data and address registers. If I recall
correctly (which I might not), adding a value other than 1, 2, or 4 to
an address requires loading it into a data register and performing
integer arithmetic on it (adding 1, 2, or 4 can be done with
auto-increment addressing modes). There may even be cases where it
makes sense to use address registers for some operations on integers.

Not all CPU architectures are flawless. Once the architecture is
fixed, I would expect a compiler to do whatever is most convenient
and/or efficient, even if it means using data registers for address
operations or vice versa.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #48
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
Da*****@cern.c h (Dan Pop) writes:
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
>Da*****@cern.c h (Dan Pop) writes:[snip] >> If all bits zero is an inconvenient representation for the null pointer on
>> a given platform, no implementor is going to use it and there is no point
>> in explaining how it could be used, anyway.
>
>I'm not convinced of that. There's still a lot of code out there that
>passes null pointers to functions without prototypes, and that will
>break if null pointers are anything other than all-bits-zero.
You're badly confusing null pointers and the null pointer constant.
There is absolutely nothing wrong with passing a null pointer to a
non-prototyped function, regardless of the representation of the null
pointer.

Passing 0 to a non-prototyped function expecting a pointer is and has
*always* been an error. Read the standard. Read K&R1.


Yes, I meant null pointer constants. I didn't badly confuse them; I
made a minor error.

Yes, passing 0 (or NULL, if it's #defined as 0) to a non-prototyped
function expecting a pointer is an error. The fact remains that there
is code in the real world that makes this error, and happens to work
as expected on platforms where pointers are the same size as int and
the null pointer has the same representation as (int)0.


This is not enough to make it work. If the platform has separate data
and address registers, the value *may* be passed in the "wrong" register
and the code will fail miserably.
Dan, did you really think that I don't know already this? I've


I have no clue about what you know and what you don't, especially
since there are many technical inaccuracies in your posts, as the
ones pointed out above. It's none of my business to figure out what you
know or what you mean, when what you write is downright incorrect.

I don't know why you keep invoking severely broken code that happens to
work by accident as an argument. Please show us some *concrete* evidence
that implementors care about such code when making their decisions and
that they're ready to sacrifice performance in order to keep broken code
working as intended by its developer.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Nov 14 '05 #49


Dan Pop wrote:
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
Da*****@cern.c h (Dan Pop) writes:
In <ln************ @nuthaus.mib.or g> Keith Thompson <ks***@mib.or g> writes:
>"Malcolm" <ma*****@55bank .freeserve.co.u k> writes:
>> "E. Robert Tisdale" <E.************ **@jpl.nasa.gov > wrote in message
>> > But, there are no implementations of the C 89 or C99 standard
>> > that use anything but all zero bits to represent NULL or +0.0.
>> >
>> The problem is that the standard allows it. For instance, if an
>> architecture appeared that trapped whenever an illegal address
>> (including 0) was loaded into an address register, then obviously
>> NULL would have to be some other value.
>[...]
>
>Maybe not. I think the only operation for which it matters is
>equality comparison. If the compiler doesn't load a pointer value
>into an address register for a pointer comparison, it might still be
>able to use all-bits-zero for null pointers.

OTOH, if the CPU has dedicated address registers, it may be that ALL
pointer operations are more efficient if using address registers.

Think about a CPU with 32-bit data registers and 48-bit address registers.


On any CPU, the code generated by a C compiler has to be able to do
assignments and equality comparisons on pointer values, including null
pointer values. If loading a null pointer into an address register
causes a trap, the C implementation won't be able to use the address
registers for pointer assignment and equality comparison (unless it
can recover in the trap handler, but that's likely to be inefficient).


But there is nothing preventing the implementor to use a null pointer
representation that doesn't trap! Even if that representation is not
all bits zero.
If it's possible to perform these operations efficiently without using
the address registers, that's great;


Even then, why bother? If address registers exist in the first place,
there *must* be a reason. Not using them for pointer operation is very
likely to be inefficient, even if they have the same size as data
registers for the simple reason that data registers get under greater
pressure, while the address registers are unused. When the sizes are
different, as in my example, the difference is going to be even more
important.
a C compiler will be able to use
all-bit-zero as the null pointer value, and everything will work.


You make it sound as if there is any merit in having null pointers
represented as all bits zero. Why would the implementor try to use
that representation, if it's causing even the slightest inconvenience?
If it isn't, either the C compiler will be forced to use a different
value for null pointers,


The representation of null pointers is supposed to be the most convenient
and efficient for the implementation, so there is no reason to consider
all bits zero as an a priori solution, unless it is a convenient choice.
or it won't be possible to implement C efficiently.


Only an idiot would create an inefficient implementation for the sake of
having null pointers represented as all bits zero. See below.
The same will probably be true for languages other than
C, which probably means that no such CPU will be designed for
general-purpose computers.


Sheer nonsense. There is always an efficient solution: create a
"reserved" object at some address and use its address as the null pointer
representation. This is what most implementations are doing anyway, using
the address 0 for this purpose. But there is nothing magic about this
address, it just happens to be very convenient for this particular
purpose, on most architectures.

Since most modern machines treat addresses as unsigned integers,
address 0 happens to be at the beginning of the address space and it's
traditionally reserved anyway, on non-virtual memory architectures:
it's the address of a GPR or an interrupt vector or the entry point in
the boot loader (possibly ROM space). On virtual memory architectures,
it's simply a matter of either leaving page zero unmapped (best choice,
IMHO) or mapping but not using it (in read only mode, preferably).


Or people could look at the c faq to see how this has been done in the past. At
symbolics we had a tagged architecture to handle this situation. If you are
using a theoretical system, you might as well add tags to it! BTW, this is not a
slam on anyone.

Wayne

Nov 14 '05 #50

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

Similar topics

26
26258
by: 69dbb24b2db3daad932c457cccfd6 | last post by:
Hello, I have to initialize all elements of a very big float point array to zero. It seems memset(a, 0, len) is faster than a simple loop. I just want to know whether it is safe to do so, since I know it's danger to initialize NULL pointers this way. But how about floats? Zhang Le
22
26757
by: silversurfer2025 | last post by:
Hello everybdy, I am a little confused for the following reason: In my code I used a simple for-loop in order to initialize a 2D-array of floats to zero. Because of efficiency reasons, I changed it to use memset and I get totally different results.. How can this be? Here is the example: float gaborfilter;
0
11109
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
10726
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
10833
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10405
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
0
9558
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7114
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
5782
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
5979
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4602
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system

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.