Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #16057 > unrolled thread

zero up memory

Back to article view | Back to comp.lang.c

Contents

  zero up memory "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-01-23 10:51 -0500
    Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 16:30 +0000
    Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-23 17:57 +0100
      Re: zero up memory Kenneth Brody <kenbrody@spamcop.net> - 2012-01-23 12:07 -0500
      Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 09:08 -0800
        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 09:22 -0800
          Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 10:13 -0800
            Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-23 12:00 -0800
          Re: zero up memory Kaz Kylheku <kaz@kylheku.com> - 2012-01-23 20:14 +0000
            Re: zero up memory "Joel C. Salomon" <joelcsalomon@gmail.com> - 2012-01-23 16:46 -0500
            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-23 14:05 -0800
              Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 23:21 +0000
                Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 09:35 -0800
                  Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-24 20:56 +0000
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:07 -0800
                      Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:38 +0000
                  Re: zero up memory Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-01-24 23:15 +0100
                    Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:31 -0800
                      Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:39 +0000
                        Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-25 15:49 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:09 -0800
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-25 13:05 -0800
                          Re: zero up memory Sjouke Burry <s@b> - 2012-01-25 23:25 +0000
                          Re: zero up memory Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-26 03:11 -0800
                            Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-26 11:48 -0800
                            Re: zero up memory gordonb.p79fg@burditt.org (Gordon Burditt) - 2012-03-12 17:55 -0500
                              Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 22:10 -0400
                                Re: zero up memory Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-03-12 23:24 -0400
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-12 23:53 -0400
                                Re: zero up memory gordonb.pu5nu@burditt.org (Gordon Burditt) - 2012-03-13 00:58 -0500
                                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-03-14 11:17 -0400
                          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-26 11:19 -0800
                            Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-27 08:13 +0000
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:42 +0000
                        Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-25 12:33 -0800
                          Re: zero up memory Kleuske <kleuske@nowhere.net> - 2012-01-26 14:12 +0000
                  Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 17:43 -0500
                    Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 16:29 -0800
                      Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-24 21:43 -0500
                        Re: zero up memory Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-01-24 23:58 -0800
                          Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:52 +0000
                        Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-25 17:48 +0000
                          Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 12:15 -0600
                            Re: zero up memory blp@cs.stanford.edu (Ben Pfaff) - 2012-01-25 10:35 -0800
                              Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:15 -0600
                                Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-25 17:23 -0600
                                Re: zero up memory "BartC" <bc@freeuk.com> - 2012-01-25 23:51 +0000
                                  Re: zero up memory Robert Wessel <robertwessel2@yahoo.com> - 2012-01-26 18:35 -0600
                          Re: zero up memory James Kuyper <jameskuyper@verizon.net> - 2012-01-25 13:17 -0500
            Re: zero up memory Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-23 22:55 +0000
        Re: zero up memory jgk@panix.com (Joe keane) - 2012-01-24 20:45 +0000
          Re: zero up memory Keith Thompson <kst-u@mib.org> - 2012-01-24 14:13 -0800

Page 1 of 3  [1] 2 3  Next page →

#16057 — zero up memory

Hello,

consider the following code:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>

#define NAME_LEN 16
#define MAX_INSTANCES 64

struct inst_info
{
  uint32_t state;
  uint32_t port_mem;
};

struct vid_entry
{
  struct vid_entry *prev;
  struct vid_entry *next;
  uint16_t vid;
  uint32_t vid_state;
};

struct hsl
{
  char name[NAME_LEN + 1];
  uint32_t ageing_time;
  unsigned char flags;
  int learning;

  /* Platform specific information. */
  void *system_info;

  struct vid_entry *inst_table[MAX_INSTANCES];
  struct inst_info inst_info_table[MAX_INSTANCES];
};

int main(void)
{
  struct hsl *br;

  br = malloc (sizeof (struct hsl));
  if ( !br)
  {
    puts("malloc() failed");
    return -1;
  }

  memset ((void *)&br->inst_info_table, 0, sizeof (struct inst_info) * 
MAX_INSTANCES);
  memset ((void *)&br->inst_table, 0, sizeof (struct vid_entry *) * 
MAX_INSTANCES);

  free (br);

  return 0;
}

As I understand it, 'inst_table' is the array of pointers to 'struct 
vid_entry' and on my system pointer is 32-bit wide, so I want to make sure 
that the code is correctly initializing memory allocated for 'struct hsl' 
object.

Also, is (void *) necessary or more a pedantic element?

Thanks !

Mark 

[toc] | [next] | [standalone]

#16058

"Mark" <mark_cruzNOTFORSPAM@hotmail.com> writes:

> Hello,
>
> consider the following code:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <stdint.h>
>
> #define NAME_LEN 16
> #define MAX_INSTANCES 64
>
> struct inst_info
> {
>   uint32_t state;
>   uint32_t port_mem;
> };
>
> struct vid_entry
> {
>   struct vid_entry *prev;
>   struct vid_entry *next;
>   uint16_t vid;
>   uint32_t vid_state;
> };
>
> struct hsl
> {
>   char name[NAME_LEN + 1];
>   uint32_t ageing_time;
>   unsigned char flags;
>   int learning;
>
>   /* Platform specific information. */
>   void *system_info;
>
>   struct vid_entry *inst_table[MAX_INSTANCES];
>   struct inst_info inst_info_table[MAX_INSTANCES];
> };
>
> int main(void)
> {
>   struct hsl *br;
>
>   br = malloc (sizeof (struct hsl));
>   if ( !br)
>   {
>     puts("malloc() failed");
>     return -1;
>   }
>
>   memset ((void *)&br->inst_info_table, 0, sizeof (struct inst_info) * 
> MAX_INSTANCES);
>   memset ((void *)&br->inst_table, 0, sizeof (struct vid_entry *) * 
> MAX_INSTANCES);
>
>   free (br);
>
>   return 0;
> }
>
> As I understand it, 'inst_table' is the array of pointers to 'struct 
> vid_entry' and on my system pointer is 32-bit wide, so I want to make sure 
> that the code is correctly initializing memory allocated for 'struct hsl' 
> object.

Well, it zeros only two elements of the struct hsl object.  The other
elements are still indeterminate.

There is a technical issue that memset sets the memory to all zero bits
whereas C permits a null pointer to be represented by something else.
It's therefore possible that memset is setting the pointers to some
undesirable value.  You may spend your whole life without ever seeing
such a system but, once you know about it, it's hard not to prefer a
loop:

  for (int i = 0; i < MAX_INSTANCES; i++)
      br->inst_table[i] = NULL;

> Also, is (void *) necessary or more a pedantic element?

No, it's not.  Neither is the & since (in this situation) an array is
converted to a pointer to it's first element.  Also, you can simplify
the code by making better use of sizeof:

  br = malloc (sizeof *br);

Just by looking, I know sizeof *br is the right size -- I don't have to
check the definition of br.  Then later:

  memset (br->inst_info_table, 0, sizeof br->inst_info_table);
  memset (br->inst_table,      0, sizeof br->inst_table);

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16060

Hello,

It is a bit shorter if you do:

     br = calloc(1,sizeof (struct hsl));
     if ( !br)
     ....[as above]


calloc implicitly zeroes the allocated memory(all the struct fields).

[toc] | [prev] | [next] | [standalone]

#16061

On 1/23/2012 11:57 AM, Johann Klammer wrote:
> Hello,
>
> It is a bit shorter if you do:
>
> br = calloc(1,sizeof (struct hsl));
> if ( !br)
> ....[as above]
>
>
> calloc implicitly zeroes the allocated memory(all the struct fields).

<nit>

calloc initializes the memory to "all bits zero".

As the footnote for 7.20.3.1p2 states:

     Note that this need not be the same as the representation of
     floating-point zero or a null pointer constant.

</nit>

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#16062

On Jan 23, 4:57 pm, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
>
> calloc implicitly zeroes the allocated memory(all the struct fields).
>
Yes. Calloc() was specified before the C standard was worked out.

All bits zero isn't necessarily a floating point zero, and it isn't
necessarily a null pointer. Which makes calloc() pretty useless.

--
MiniBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#16064

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Jan 23, 4:57 pm, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
>>
>> calloc implicitly zeroes the allocated memory(all the struct fields).
>>
> Yes. Calloc() was specified before the C standard was worked out.
>
> All bits zero isn't necessarily a floating point zero, and it isn't
> necessarily a null pointer. Which makes calloc() pretty useless.

It's useful if the allocated memory doesn't contain any floating-point
or pointer subobjects.

(it can also, I hesitate to mention,  be useful in code that isn't
intended to be portable.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16066

On Jan 23, 5:22 pm, Keith Thompson <ks...@mib.org> wrote:
>
> It's (calloc) useful if the allocated memory doesn't contain any floating-point
> or pointer subobjects.
>
It's too easy to change a structure to add a floating point or pointer
field, test it, and of course find that the code behaves exactly as
you want.
Calloc() is best avoided.

--
MinBasic - how to write a script interpreter
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#16068

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Jan 23, 5:22 pm, Keith Thompson <ks...@mib.org> wrote:
>> It's (calloc) useful if the allocated memory doesn't contain any floating-point
>> or pointer subobjects.
>>
> It's too easy to change a structure to add a floating point or pointer
> field, test it, and of course find that the code behaves exactly as
> you want.
> Calloc() is best avoided.

Agreed, mostly -- but if the allocated space contains an array of some
integer type, it's not unreasonable to use calloc() (with a comment).
But yes, there is a risk if the integer array is later changed to a
floating-point array.

(Hmm, I wonder if there are any systems where all-bits-zero is not a
representation of 0.0 for all floating-point types.  Could a future
standard impose such a requirement without breaking existing
implementations?)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16070

On 2012-01-23, Keith Thompson <kst-u@mib.org> wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> On Jan 23, 4:57 pm, Johann Klammer <klamm...@NOSPAM.a1.net> wrote:
>>>
>>> calloc implicitly zeroes the allocated memory(all the struct fields).
>>>
>> Yes. Calloc() was specified before the C standard was worked out.
>>
>> All bits zero isn't necessarily a floating point zero, and it isn't
>> necessarily a null pointer. Which makes calloc() pretty useless.
>
> It's useful if the allocated memory doesn't contain any floating-point
> or pointer subobjects.

It's useful even if it isn't, just no portable.

Nonportable and useless are different things.

I can think of a lot of code that will never need to run on a machine
where null pointers or 0.0 aren't all zero bits.

All-zero memory can be very efficiently procured on a virtual memory OS: 
you can alias all of the pages to the same physical frame of memory.

This is very useful for, for instance, large sparse matrices.

An architecture where zero bits don't make a 0.0 floating point value
is plain stupid (and not IEEE 754 compatible).

[toc] | [prev] | [next] | [standalone]

#16075

On 01/23/2012 03:14 PM, Kaz Kylheku wrote:
> An architecture where zero bits don't make a 0.0 floating point value
> is plain stupid (and not IEEE 754 compatible).

How about a 754 implementation where the in-core representation is the
bitwise complement; that way the all-bits-zero memory word represent the
all-bits-one datum which (on this hypothetical platform) is the
signaling NaN.

However crazy this may be, "plain stupid" it's not -- and it should be
754 compliant.

--Joel

[toc] | [prev] | [next] | [standalone]

#16078

On Jan 23, 8:14 pm, Kaz Kylheku <k...@kylheku.com> wrote:
>
> An architecture where zero bits don't make a 0.0 floating point value
> is plain stupid (and not IEEE 754 compatible).
>
Zero cannot be represented in floating point, because the exponent is
minus infinity.

If you have a signed exponent, zero would represent unity, or number
within the range 1 - 2.  You might reserve high bit set for special
numbers, and zero could be one of those special numbers.
Most existing floating point formats use an offset to represent
exponents, so zero exponent represents the lowest representable value,
and all bits zero can be used for zero. However this isn't
particularly logical, and there might be low-level circuit reasons for
preferring a two's complement exponent.

[toc] | [prev] | [next] | [standalone]

#16081

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Jan 23, 8:14 pm, Kaz Kylheku <k...@kylheku.com> wrote:
>>
>> An architecture where zero bits don't make a 0.0 floating point value
>> is plain stupid (and not IEEE 754 compatible).
>>
> Zero cannot be represented in floating point, because the exponent is
> minus infinity.

In systems where the mantissa is not normalised (i.e. there is no
implicit leading 1) then zero is specified quite naturally with a zero
mantissa.  A zero sign bit and exponent (even it biased) makes no
difference.  Systems like this are common: IEEE decimal floating point
and IBM's hexadecimal floating point come to mind.

> If you have a signed exponent, zero would represent unity, or number
> within the range 1 - 2.  You might reserve high bit set for special
> numbers, and zero could be one of those special numbers.
> Most existing floating point formats use an offset to represent
> exponents, so zero exponent represents the lowest representable value,
> and all bits zero can be used for zero. However this isn't
> particularly logical, and there might be low-level circuit reasons for
> preferring a two's complement exponent.

In IEEE binary floating point formats, a zero exponent is special.  It
is not simply the lowest exponent, but flags up a set of special values:
+0 and -0 when the mantissa is 0 and denormalised numbers when it
is not zero (and the actual exponent used is 1 not zero i.e. the lowest
"real" exponent).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16102

On Jan 23, 11:21 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
> In systems where the mantissa is not normalised (i.e. there is no
> implicit leading 1) then zero is specified quite naturally with a zero
> mantissa.  A zero sign bit and exponent (even it biased) makes no
> difference.  Systems like this are common: IEEE decimal floating point
> and IBM's hexadecimal floating point come to mind.
>
So how does the processor do equality comparisons, efficiently?

If the mantissa is not normalized then there are many possible
representations for each number, including zero.

--
MPI tutorial - learn parallel programming in C
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#16121

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Jan 23, 11:21 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>>
>> In systems where the mantissa is not normalised (i.e. there is no
>> implicit leading 1) then zero is specified quite naturally with a zero
>> mantissa.  A zero sign bit and exponent (even it biased) makes no
>> difference.  Systems like this are common: IEEE decimal floating point
>> and IBM's hexadecimal floating point come to mind.
>>
> So how does the processor do equality comparisons, efficiently?
>
> If the mantissa is not normalized then there are many possible
> representations for each number, including zero.

I am not 100% sure I have the terminology right.  The mantissa may be
normalised in the sense of having no redundant leading zero digits but
in the systems I am describing (ones that don't use binary) there can't
be an implicit leading digit.  A normalised binary mantissa always
starts 0.1... so such system don't bother to store the leading 1.  As a
result, zero can't be represented with a zero mantissa.  On systems with
non binary digits, the leading digit can't be omitted so a zero
mantissa represents zero no matter what the exponent is.

I can't answer your question about efficient equality testing -- you'd
have to ask a hardware designer.  However, the fact that there are
redundant representations should not be a surprise.  I don't know any FP
format that does not have multiple representations that must compare
equal (+0 and -1 being the most common example).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16132

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> I can't answer your question about efficient equality testing -- you'd
> have to ask a hardware designer.  However, the fact that there are
> redundant representations should not be a surprise.  I don't know any FP
> format that does not have multiple representations that must compare
> equal (+0 and -1 being the most common example).

I think you mean +0 and -0.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16201

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
<snip>
>>                                                 I don't know any FP
>> format that does not have multiple representations that must compare
>> equal (+0 and -1 being the most common example).
>
> I think you mean +0 and -0.

<facepalm>  Thanks.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#16135

Malcolm McLean wrote:
> So how does the processor do equality comparisons, efficiently?
>
> If the mantissa is not normalized then there are many possible
> representations for each number, including zero.
>
> --
> MPI tutorial - learn parallel programming in C
> http://www.malcolmmclean.site11.com/www

Usually one does an epsilon test.
with epsilon rather small

if(((a+epsilon)<b)&&((a-epsilon)>b))
{

}

The following will most likely evaluate to false on intel machines
The compiler just does a (bitwise)equality test.

a=+0.0;
b=-0.0;

if(a==b)
{

}

[toc] | [prev] | [next] | [standalone]

#16136

Johann Klammer <klammerj@NOSPAM.a1.net> writes:
> Malcolm McLean wrote:
>> So how does the processor do equality comparisons, efficiently?
>>
>> If the mantissa is not normalized then there are many possible
>> representations for each number, including zero.
>
> Usually one does an epsilon test.
> with epsilon rather small
>
> if(((a+epsilon)<b)&&((a-epsilon)>b))
> {
>
> }

That doesn't address the question, which is how the processor performs a
floating-point equality test, the one specified by C's "==" operator.

> The following will most likely evaluate to false on intel machines
> The compiler just does a (bitwise)equality test.
>
> a=+0.0;
> b=-0.0;
>
> if(a==b)
> {
>
> }

Only if the compiler is broken.  "a==b" yields 1 if a and b are
*numerically* equal, 0 if they're not.  If two bit patterns represent
the same value, bitwise comparison will not work.

Oh, and "b=-0.0" won't set b to a floating-point negative zero.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16198

On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish the
following:

> Johann Klammer <klammerj@NOSPAM.a1.net> writes:
>> Malcolm McLean wrote:
>>> So how does the processor do equality comparisons, efficiently?
>>>
>>> If the mantissa is not normalized then there are many possible
>>> representations for each number, including zero.
>>
>> Usually one does an epsilon test.
>> with epsilon rather small
>>
>> if(((a+epsilon)<b)&&((a-epsilon)>b))
>> {
>>
>> }
> 
> That doesn't address the question, which is how the processor performs a
> floating-point equality test, the one specified by C's "==" operator.

In fact it did, if only in passing. The comparison is a bit-wise one, IIRC,
and using '==' for floats and doubles is strongly discouraged where i work.

I think it might be a universal best practice.




-- 
Killing is stupid; useless!
		-- McCoy, "A Private Little War", stardate 4211.8

[toc] | [prev] | [next] | [standalone]

#16199

On Wed, 25 Jan 2012 15:39:15 +0000, Kleuske saw fit to publish the
following:

> On Tue, 24 Jan 2012 14:31:38 -0800, Keith Thompson saw fit to publish
> the following:
> 
>> Johann Klammer <klammerj@NOSPAM.a1.net> writes:
<snip>
>>> if(((a+epsilon)<b)&&((a-epsilon)>b))
>>> {
>>>
>>> }
>> 
>> That doesn't address the question, which is how the processor performs
>> a floating-point equality test, the one specified by C's "==" operator.
> 
> In fact it did, if only in passing. The comparison is a bit-wise one,
> IIRC, and using '==' for floats and doubles is strongly discouraged
> where i work.

"Strongly discouraged" as in "Do it again, and you're fired".

-- 
If some day we are defeated, well, war has its fortunes, good and bad.
		-- Commander Kor, "Errand of Mercy", stardate 3201.7

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web