440,874 Members | 1,027 Online
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,874 IT Pros & Developers. It's quick & easy.

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

 P: n/a 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 #1
53 Replies

 P: n/a In article , Zhiqiang Ye wrote: The zero fill is all-bits-zero, and does not therefore guarantee useful nullpointer values (see section 5 of this list) or floating-point zero values. but ieee754 defined float zero to be all-bits-zero. So *if* your C omplementation uses IEEE floating point, the values will be zero. -- Richard Nov 14 '05 #2

 P: n/a Zhiqiang Ye wrote: 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? Here's a wild guess. Because IEEE 754 support is not mandatory? Thus you cannot, portably, assume that every compiler will implement the formats specified by the IEEE 754 standard. Nov 14 '05 #3

 P: n/a In "Zhiqiang Ye" writes: I am reading FAQ of this group. I have a question about this:http://www.eskimo.com/~scs/C-faq/q7.31.htmlIt says:"p = malloc(m * n);memset(p, 0, m * n);The zero fill is all-bits-zero, and does not therefore guarantee useful nullpointer 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? The C standard doesn't say that floating point types *must* follow the IEEE-754 specification. There are other floating point representations where all bits zero doesn't mean zero. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #4

 P: n/a Zhiqiang Ye wrote: 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? C doesn't require implementations to use IEEE754, if I recall correctly. -- Chris "electric hedgehog" Dollin C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html Nov 14 '05 #5

 P: n/a Zhiqiang Ye wrote: 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? Very simple. There are other floating-point formats than those defined in IEEE754. The C standard does not guarantee or require that IEEE754 is used. -- Erik Trulsson er******@student.uu.se Nov 14 '05 #6

 P: n/a In Grumble writes: Zhiqiang Ye wrote: 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?Here's a wild guess.Because IEEE 754 support is not mandatory? Thus you cannot, portably,assume that every compiler will implement the formats specified by theIEEE 754 standard. IEEE 754 is particularly expensive when done in software, because the underlying hardware provides no floating point support. Therefore, implementations for such hardware either use a different floating point format or provide two floating point representations: IEEE 754 and something faster. For example, MS C implementations for the 80[23]86 came with both 80[23]87 emulation (i.e. IEEE 754 implemented in software) and with an implementation of a Microsoft-designed floating point format. The former could transparently exploit an 80[23]87 chip, if present, the latter was significantly faster on systems without an 80[23]87 chip, but couldn't benefit from such a chip, if present. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #7

 P: n/a Zhiqiang Ye wrote: 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? IEEE 754 specification is not a part of C language specification. Implementations are not required to conform to IEEE 754. -- Best regards, Andrey Tarasevich Nov 14 '05 #8

 P: n/a >p = malloc(m * n);memset(p, 0, m * n);The zero fill is all-bits-zero, and does not therefore guarantee useful nullpointer values (see section 5 of this list) or floating-point zero values."but ieee754 defined float zero to be all-bits-zero. ieee754 defined two DIFFERENT floating point representations for zero, and they can't both be all-bits-zero. Also, not everyone uses ieee754 floating point. Gordon L. Burditt Nov 14 '05 #9

 P: n/a In article , "Zhiqiang Ye" wrote: 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? But C doesn't guarantee ieee754. Nov 14 '05 #10

 P: n/a go***********@burditt.org (Gordon Burditt) writes:p = malloc(m * n);memset(p, 0, m * n);The zero fill is all-bits-zero, and does not therefore guarantee useful nullpointer values (see section 5 of this list) or floating-point zero values."but ieee754 defined float zero to be all-bits-zero. ieee754 defined two DIFFERENT floating point representations for zero, and they can't both be all-bits-zero. Also, not everyone uses ieee754 floating point. IEEE754 0.0 is not necessarily all-bits-zero, but all-bits-zero is necessarily IEEE754 0.0. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #12

 P: n/a Da*****@cern.ch (Dan Pop) writes: [...] The C standard doesn't say that floating point types *must* follow the IEEE-754 specification. There are other floating point representations where all bits zero doesn't mean zero. Are any such representations currently being used? -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #13

 P: n/a "E. Robert Tisdale" wrote: .... snip ... 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. Obviously you have secured and exhaustively examined every std C implementation on any machine whatsoever. Sounds like a lot of work. Was this funded by NASA, and how did you determine that you checked each and every one? Where did you put those myriad systems? Maybe we should all write NASA and ask for the report. The exhaustive listing should be useful. Being government funded it should be freely available. While doing all this, how did you find time for trolling and spewing misinformation? -- fix (vb.): 1. to paper over, obscure, hide from public view; 2. to work around, in a way that produces unintended consequences that are worse than the original problem. Usage: "Windows ME fixes many of the shortcomings of Windows 98 SE". - Hutchison Nov 14 '05 #14

 P: n/a -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keith Thompson wrote: | Da*****@cern.ch (Dan Pop) writes: | [...] | |>The C standard doesn't say that floating point types *must* follow the |>IEEE-754 specification. There are other floating point representations |>where all bits zero doesn't mean zero. | | | Are any such representations currently being used? | IIRC, my TI-83 calculator uses a packed BCD representation for the mantissa and an 8-bit 2's compliment number for the (decimal) exponent. I would imagine BCD is quite common in calculators. However, you get lucky again as all bits zero still means zero and, FWIW, I don't believe there is an ISO C compiler for it. Ross -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA0W/P9bR4xmappRARAvd8AJwNpS+6UpF2SFil/Dasb2/zJGolSACgtRyn BwPyCXIFzRQQF6+mpAiXQxk= =Z19n -----END PGP SIGNATURE----- Nov 14 '05 #15

 P: n/a > Are any such representations currently being used? No, none at all. It is just fun for the regulars to insist on possibility even when all computers out there are using IEEE-754 or IEEE-854. Anarchist Nov 14 '05 #16

 P: n/a In go***********@burditt.org (Gordon Burditt) writes: p = malloc(m * n);memset(p, 0, m * n);The zero fill is all-bits-zero, and does not therefore guarantee useful nullpointer values (see section 5 of this list) or floating-point zero values."but ieee754 defined float zero to be all-bits-zero.ieee754 defined two DIFFERENT floating point representations for zero,and they can't both be all-bits-zero. This is irrelevant, if ieee754 implementations must support both of them at the same time. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #17

 P: n/a In Keith Thompson writes: Da*****@cern.ch (Dan Pop) writes:[...] The C standard doesn't say that floating point types *must* follow the IEEE-754 specification. There are other floating point representations where all bits zero doesn't mean zero.Are any such representations currently being used? Not that I know of. Those representations were usually used by software implementations of floating point, which are today quasi-extinct (at least on hosted implementations). Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #18

 P: n/a "Anarchist" writes: Are any such representations currently being used? No, none at all. It is just fun for the regulars to insist on possibility even when all computers out there are using IEEE-754 or IEEE-854. The question was whether there are floating-point representations being used in which all-bit-zero does not represent 0.0. So far, nobody has cited one. But it's certainly not the case that all computers out there are using IEEE-754 or IEE-854. Non-IEEE representations are becoming less common, but there's not extinct. VAXen, Cray vector systems, and IBM mainframes all have their own floating-point formats predating the IEEE standards. It may (or may not) be possible for a future C standard to mandate that all-bits-zero is a valid representation of 0.0 for floating-point types. Mandating IEEE format won't be practical for a long time, if ever. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #19

 P: n/a In article , Keith Thompson wrote: But it's certainly not the case that all computers out there are usingIEEE-754 or IEE-854. Non-IEEE representations are becoming lesscommon, but there's not extinct. VAXen, Cray vector systems, and IBMmainframes all have their own floating-point formats predating theIEEE standards. True, but do any of the ones you mention not have all-bits-zero -> 0.0? -- Richard Nov 14 '05 #20

 P: n/a ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: In article , Keith Thompson wrote:But it's certainly not the case that all computers out there are usingIEEE-754 or IEE-854. Non-IEEE representations are becoming lesscommon, but there's not extinct. VAXen, Cray vector systems, and IBMmainframes all have their own floating-point formats predating theIEEE standards. True, but do any of the ones you mention not have all-bits-zero -> 0.0? For the VAX and Cray formats, 0.0 is represented as all-bits-zero (confirmed just now by experiment). For the IBM mainframe format, I think that's the case but I can't confirm it. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #21

 P: n/a In Keith Thompson writes: For the VAX and Cray formats, 0.0 is represented as all-bits-zero(confirmed just now by experiment). The PDP-11 and VAX cases are still well documented. For the IBM mainframe format, Ithink that's the case but I can't confirm it. Given the nature of IBM's representation (no "hidden" mantissa bits), any all zeros mantissa should be a representation of zero, unless it's a trap representation (I don't remember IBM 360 floating point actually using any trap representations). Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #22

 P: n/a In ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: In article ,Keith Thompson wrote:But it's certainly not the case that all computers out there are usingIEEE-754 or IEE-854. Non-IEEE representations are becoming lesscommon, but there's not extinct. VAXen, Cray vector systems, and IBMmainframes all have their own floating-point formats predating theIEEE standards.True, but do any of the ones you mention not have all-bits-zero -> 0.0? The obvious candidate for all-bits-zero != 0.0 is a binary representation with "hidden" mantissa bit that doesn't use excess-whatever for the exponent. On such a representation, all-bits-zero would be 1.0 or 0.5, depending on the position of the "binary point". 0.0 would either not be exactly representable (no big deal) or use a bit pattern with the exponent set to its minimum value. I am not aware of any hardware implementation of such a representation, but I'm not sure that I haven't seen/used at least one software implementation like this. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #23

 P: n/a In article Keith Thompson writes: ri*****@cogsci.ed.ac.uk (Richard Tobin) writes: In article , Keith Thompson wrote:But it's certainly not the case that all computers out there are usingIEEE-754 or IEE-854. Non-IEEE representations are becoming lesscommon, but there's not extinct. VAXen, Cray vector systems, and IBMmainframes all have their own floating-point formats predating theIEEE standards. True, but do any of the ones you mention not have all-bits-zero -> 0.0? For the VAX and Cray formats, 0.0 is represented as all-bits-zero (confirmed just now by experiment). For the IBM mainframe format, I think that's the case but I can't confirm it. The only computer I have used that did have 0.0 with not all bits zero was the CDC Cyber 205. I understand that the f-p format it used is the same as in some MIL-STD computer. -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131 home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/ Nov 14 '05 #24

 P: n/a "Dan Pop" wrote in message news:ca**********@sunnews.cern.ch... In ri*****@cogsci.ed.ac.uk (Richard Tobin) writes:In article ,Keith Thompson wrote:But it's certainly not the case that all computers out there are usingIEEE-754 or IEE-854. Non-IEEE representations are becoming lesscommon, but there's not extinct. VAXen, Cray vector systems, and IBMmainframes all have their own floating-point formats predating theIEEE standards.True, but do any of the ones you mention not have all-bits-zero -> 0.0? The obvious candidate for all-bits-zero != 0.0 is a binary representation with "hidden" mantissa bit that doesn't use excess-whatever for the exponent. On such a representation, all-bits-zero would be 1.0 or 0.5, depending on the position of the "binary point". 0.0 would either not be exactly representable (no big deal) or use a bit pattern with the exponent set to its minimum value. I am not aware of any hardware implementation of such a representation, but I'm not sure that I haven't seen/used at least one software implementation like this. On a machine with no bias in the exponent, without a hidden mantissa bit, all-bits-zero is an un-normalized floating point zero. As such machines did not have gradual underflow, performing arithmetic between such operands and other operands of magnitude < 0.5 gave truncated results. For example, had been implemented at that time, 0.9*LDBL_EPSILON + would give 0.0. One of the early C implementations (gcos) was on such a machine. I over-simplify, since "long double" was not supported as a memory storage data type, only in register. Nov 14 '05 #25

 P: n/a Just to add to the confusion, there are really two different questions here. One, the issue raised by the OP, is whether using memset to assign all-bits-zero to a floating-point object will result in a value equal to 0.0. The other is whether assigning the value 0.0 to a floating-point object will result in the object containing all-bits-zero. The possible existence of multiple representations for 0.0 means that these are not the same question. However, I'd be very surprised if there were an implementation for which these questions have different answers. In other words, I'm guessing that if all-bits-zero is a valid representation of 0.0, it's the default representation of 0.0 (for each floating-point type in each implementation). -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #26

 P: n/a In article , Keith Thompson wrote: Just to add to the confusion, there are really two different questions here. One, the issue raised by the OP, is whether using memset to assign all-bits-zero to a floating-point object will result in a value equal to 0.0. The other is whether assigning the value 0.0 to a floating-point object will result in the object containing all-bits-zero. The possible existence of multiple representations for 0.0 means that these are not the same question. However, I'd be very surprised if there were an implementation for which these questions have different answers. In other words, I'm guessing that if all-bits-zero is a valid representation of 0.0, it's the default representation of 0.0 (for each floating-point type in each implementation). I have seen one implementation where long double was 12 byte, with two padding bytes. Nov 14 '05 #27

 P: n/a "E. Robert Tisdale" 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. If someone invented a fast floating-point unit which relied on zero not being all bits clear, then similarly an exception would have to be made. The fact is that C is such a common language that most architectures are designed with C compilers in mind, and many programs would break if NULL or 0.0 was not all bits zero. It's the problem of programs which are portable enough for practical purposes, but not strictly compliant. Nov 14 '05 #29

 P: n/a Trolling away again, I see. WWKKWWWWWWKKWWWWWWKKWWWWWWKKWWKKWWWWKKWWWWKKWWWWWW WWKKWWWWKKWWWWWWWWWW WWWWWWKKWWWWWWKKWWWWWWKKWWWWWWWWWWWWWWWWWWWWWWKKWW WWWWWWWWWWWWKKWWKKWW WWKKWWWWKKWWWWWWWWKKWWWWWWWW.. WWWW WWWWWWKKWWKKWWKKWWWWWWWWWW WWWWWWWWWWWWKKWWWWWWWWWW WWWWWWWWWWWWWWKKWWWWKK WWKKWWKKWWWWWWWWKKWWWW WWWWKKWWKKWWWWWWWWWW WWWWWWWWWWKKWWWWWW WWWWWWWWWWKKWWKKWW WWKKWWKKWWWWKKWW WWWWKKWWWWWWWWWW WWWWWWWWWWWWWW.. ,,::::.. WWWWWWWWKKWWWW WWKKWWWWKKWWWW ,,iittttii,,::.. WWWWKKWWWWWWKK WWWWWWWWWWKK ,,;;;;iittii;;,,,,,,:: ..,, WWWWKKWWWWWW WWKKWWKKWWWW .. ::;;;;,,;;,,,,,,,,::.. :::: WWWWWWWWKKWW WWWWWWWWWWWW ,,;;,,,,,,,,,,,,,,:: ,,.. ..KKWWWWWWWW WWKKWWKKWW ..,,;;;;,,,,,,,,,,,,::.. ..,,,, ..WWKKWWKKWW WWWWWWWWWW ::;;;;ii;;,,,,::,,::::::.. ::::;; WWWWWWWWWW WWKKWWWWWW ..iiiiii;;,,,,,,::,,::,,::,,,,;;;;.. WWKKWWKKWW WWWWWWKK ..;;iiiiii;;;;,,;;,,,,,,;;iiiiii;;.. WWWWWWWWWW WWKKWWWW ,,;;iiiiii;;;;,,,,,,,,,,;;iiiiiiii.. WWWWKKWWWW WWWWWWWW ::iiiiiiiiii;;;;;;,,,,,,;;;;;;;;ttii,, WWWWWWKK WWKKWWKK ..;;;;iittLLGGttttttiiiiiiiittjjttiiiiii.. WWKKWWWW WWWWWWWW ..;;;;iiffLLDDEEEEDDffttLLEEKKKKEELLfftt::.. WWWWWWWW WWKKWWWW ..;;iittjjffffDDEEGGjjiiDDKKDDGGDDDDffjj;; WWKKWWWW WWWWWWKKWW ..::;;;;iijjGGEEEEEEGGjj;;LLEEEEEEEEEELLjjii:: WWWWWWKK WWKKWWWWWW ..,,;;;;iittiitttttttttt;;ffGGffffLLtt,,tttt:: WWWWKKWWWW WWWWWWKKWWWW,,,,;;;;;;iiiiiiiiiitttt,,;;LLtttttt,, ;;ttLL,,WWKKWWWWWWWW WWKKWWWWWWKKii,,;;ii;;;;,,;;,,iiii;;;;,,jjjjii;;;; ;;ttGG::WWWWWWWWKKWW WWWWWWKKWWWWttiiiiii;;;;;;;;ttLLffttjjLLGGDDffiiii ttttLL WWKKWWWWWWWW WWKKWWWWWWWWiiii;;;;;;ii;;ttGGLLEEEEEEKKKKDDLLjjff ffffff..WWWWWWKKWWWW WWWWWWKKWWWWjjtt;;iiiiiittLLGGffLLLLDDEEDDDDGGLLff LLGGGG;;WWKKWWWWKKWW WWKKWWWWKKWW;;iiiiiiiiiiffDDDDLLLLLLGGGGDDEEEEGGff GGGGGGttWWWWWWWWWWWW WWWWWWWWWWWW,,iiiiiittttffDDEEDDEEEEGGEEKKKKEEffLL DDDDDDffKKWWKKWWKKWW WWKKWWKKWW,,,,iittiiiittffGGttttttffLLGGGGGGLLjjLL DDEEEEttWWWWWWWWWWWW WWWWWWWWiiiiiijjjjjjttffffffjjttjjGGGGGGLLGGLLGGDD DDEEEE;;WWWWKKWWKKWW WWKKWWfftt;;LLjjffLLffffLLLLjjiittttjjLLffLLDDEEEE EEEEff;;iiWWWWWWWWWW WWWWWW;;..ttEEttffLLGGGGLLLLffjjttttjjffLLDDEEKKKK KKKKLL,,ttttWWKKWWWW WWWW::..,,ffEEffjjLLLLLLGGDDGGLLffLLLLLLDDEEKKKKKK EEKKDD,,::;;;;WWWWii ::....;;ffLLEEDDttffLLGGLLLLGGEEEEEEEEKKKKKKKKEEKK EEEEEEii;;..,,,,;;tt .....::jjGGGGDDEEffjjffLLLLffffffGGEEEEEEEEEEKKEEK KEEKKEEfftt;;::..::tt ...::;;jjDDDDGGEEGGiijjffGGffLLLLLLGGGGDDEEKKEEKKE EKKKKDDLLjjtt;;::::.. ,,,,iiiiEEDDDDDDDDttttffLLLLLLGGLLGGDDEEEEEEKKEEDD KKEEDDffjjLLGGtt,,.. ,,;;ttffDDEEDDDDEELLttjjLLLLLLGGLLDDEEEEEEEEEEDDDD KKDDLLffGGEEEEtt,,:: ,,;;iiGGGGEEKKEEEEDDjjttffffLLLLDDGGDDDDEEGGDDDDEE GGLLjjDDEEKKLLii,,,, ;;iiiiLLEEDDEEEEDDDDffffffjjffLLGGGGDDGGLLGGGGDDLL GGLLEEEEKKGGjjii;;;; iiiittttLLEEEEEEKKKKjjttffffjjffffffjjffffLLDD;;GG KKKKKKEEDDffttii;;;; iiiiiittffLLGGDDEEKKDDffffffjjjjttttiittffjjiittKK KKEEEEGGLLttiiii;;;; iiiittiiffffjjffjjLLDDEEDDLLttjjjjjjttjjttffKKKKDD GGGGLLLLttttiiii;;;; iiiiiittttjjffjjffffffLLDDEEEELLffffjjttDDKKKKDDGG GGffffffttiiii;;;;ii iiiiiittttttjjjjjjjjffffffLLLLGGDDffffEEEEDDGGGGLL LLffjjttiiii;;iiiiii -- Sev Nov 14 '05 #30

 P: n/a "Malcolm" writes: "E. Robert Tisdale" 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. -- Keith Thompson (The_Other_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #31

 P: n/a In article , Keith Thompson wrote: Maybe not. I think the only operation for which it matters isequality comparison. If the compiler doesn't load a pointer valueinto an address register for a pointer comparison, it might still beable to use all-bits-zero for null pointers. Surely it would have to ensure that it never loaded a pointer that might be null into a register? Even, say, when assigning a possibly-null pointer to a variable, or passing it to a procedure. This would be possible on architectures with memory-to-memory move instructions and which passed all arguments on the stack, but probably inefficient. -- Richard Nov 14 '05 #32

 P: n/a In Christian Bau writes: In article , Keith Thompson wrote: Just to add to the confusion, there are really two different questions here. One, the issue raised by the OP, is whether using memset to assign all-bits-zero to a floating-point object will result in a value equal to 0.0. The other is whether assigning the value 0.0 to a floating-point object will result in the object containing all-bits-zero. The possible existence of multiple representations for 0.0 means that these are not the same question. However, I'd be very surprised if there were an implementation for which these questions have different answers. In other words, I'm guessing that if all-bits-zero is a valid representation of 0.0, it's the default representation of 0.0 (for each floating-point type in each implementation).I have seen one implementation where long double was 12 byte, with twopadding bytes. That's quite common nowadays on x86 compilers, due to alignment issues. E.g. gcc and the Intel C compiler on x86. The other common option for x86 implementations is 8 bytes (the same as double). Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #35

 P: n/a In Keith Thompson writes: "Malcolm" writes: "E. Robert Tisdale" 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 isequality comparison. If the compiler doesn't load a pointer valueinto an address register for a pointer comparison, it might still beable 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. Dan -- Dan Pop DESY Zeuthen, RZ group Email: Da*****@ifh.de Nov 14 '05 #36

 P: n/a In Keith Thompson 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

 P: n/a rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: Keith Thompson 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_Keith) ks***@mib.org San Diego Supercomputer Center <*> We must do something. This is something. Therefore, we must do this. Nov 14 '05 #42

 P: n/a In article , Keith Thompson 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

 P: n/a Keith Thompson wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: Keith Thompson 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

 P: n/a In article <40****************@news.individual.net>, rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote: Keith Thompson wrote: rl*@hoekstra-uitgeverij.nl (Richard Bos) writes: Keith Thompson 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