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

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

Pointer goes to null

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

Contents

  Pointer goes to null m.nasim85@gmail.com - 2020-01-02 01:34 -0800
    Re: Pointer goes to null Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-02 12:47 +0000
    Re: Pointer goes to null Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-02 08:55 -0500
      Re: Pointer goes to null Bart <bc@freeuk.com> - 2020-01-02 18:49 +0000
        UB awaits... (Was: Pointer goes to null) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-02 19:53 +0000
          Re: UB awaits... (Was: Pointer goes to null) David Brown <david.brown@hesbynett.no> - 2020-01-02 23:34 +0100
            Re: UB awaits... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 01:43 +0000
              Re: UB awaits... David Brown <david.brown@hesbynett.no> - 2020-01-03 09:50 +0100
                Re: UB awaits... Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 14:30 +0000
                  Re: UB awaits... David Brown <david.brown@hesbynett.no> - 2020-01-03 17:27 +0100
    Re: Pointer goes to null Bart <bc@freeuk.com> - 2020-01-02 14:07 +0000
      Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-02 07:29 -0800
        Re: Pointer goes to null Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-02 10:12 -0800
    Re: Pointer goes to null jak <nospam@please.ty> - 2020-01-02 16:46 +0100
    Re: Pointer goes to null Barry Schwarz <schwarzb@delq.com> - 2020-01-02 08:50 -0800
      Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-03 16:20 -0800
        Re: Pointer goes to null Barry Schwarz <schwarzb@delq.com> - 2020-01-03 22:16 -0800
          Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-07 03:21 -0800
        Re: Pointer goes to null Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-07 12:24 -0500
          Re: Pointer goes to null Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-07 12:38 -0500
            Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-15 09:36 -0800
              Re: Pointer goes to null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-15 18:36 +0000
                Re: Pointer goes to null Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-15 17:31 -0500
                  Re: Pointer goes to null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-16 02:20 +0000
                  Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-17 14:51 -0800
                    Re: Pointer goes to null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-17 23:32 +0000
                Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-17 14:47 -0800
                  Re: Pointer goes to null Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-17 23:25 +0000
              Re: Pointer goes to null James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 10:49 -0800
                Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-17 14:49 -0800
          Re: Pointer goes to null Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-01-07 09:42 -0800
            Re: Pointer goes to null m.nasim85@gmail.com - 2020-01-15 09:40 -0800
    Re: Pointer goes to null James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:38 -0500

Page 2 of 2 — ← Prev page 1 [2]

#149139

Lew, acctually, I cannot accept either
>   blk_cnt = ((data_bitlen)/256) + ((data_bitlen%256)/(data_bitlen%256)) 
or
>   blk_cnt = ((data_bitlen/256) + ((data_bitlen%256) != 0)) 

1st form may divide by zero. (you mentioned this)
2nd form may have unpredictable behavior as ((data_bitlen%256) != 0) returns TRUE ,which is only guaranteed not to be zero. it may be 1 (which you intended) or -1.
imagine if -1 has been processed as an unsigned long long int, it will be enormous number, and my CPU will have to handle a very long loop.

after all, thank you for effort and reply.

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

#149150

m.nasim85@gmail.com writes:

> Lew, acctually, I cannot accept either
>>   blk_cnt = ((data_bitlen)/256) + ((data_bitlen%256)/(data_bitlen%256)) 
> or
>>   blk_cnt = ((data_bitlen/256) + ((data_bitlen%256) != 0)) 
>
> 1st form may divide by zero. (you mentioned this)
> 2nd form may have unpredictable behavior as ((data_bitlen%256) != 0)
> returns TRUE ,which is only guaranteed not to be zero. it may be 1
> (which you intended) or -1.

No.  All of C's equality and comparison operators are defined to give
either 0 or 1.  No other value is possible.  Some of C's /functions/
don't behave this way (strcmp, isascii etc.), but that another matter.

But Lew's second suggestion does not do what your original code did.
Your code had the odd exception that the block count should be 1 when
the bit length was zero.  If you just want the number of whole or part
256-bit blocks, the usual way is to write

  blk_cnt = (data_bitlen + 255) / 256;

but that does not give blk_cnt == 1 when data_bitlen == 0.  Do you
really want that?

-- 
Ben.

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

#149162

Ben Bacarisse wrote:

> m.nasim85@gmail.com writes:
> 
>> Lew, acctually, I cannot accept either
>>>   blk_cnt = ((data_bitlen)/256) + ((data_bitlen%256)/(data_bitlen%256))
>> or
>>>   blk_cnt = ((data_bitlen/256) + ((data_bitlen%256) != 0))
>>
>> 1st form may divide by zero. (you mentioned this)
>> 2nd form may have unpredictable behavior as ((data_bitlen%256) != 0)
>> returns TRUE ,which is only guaranteed not to be zero. it may be 1
>> (which you intended) or -1.
> 
> No.  All of C's equality and comparison operators are defined to give
> either 0 or 1.  No other value is possible.  Some of C's /functions/
> don't behave this way (strcmp, isascii etc.), but that another matter.
> 
> But Lew's second suggestion does not do what your original code did.
> Your code had the odd exception that the block count should be 1 when
> the bit length was zero.  If you just want the number of whole or part
> 256-bit blocks, the usual way is to write
> 
>   blk_cnt = (data_bitlen + 255) / 256;
> 
> but that does not give blk_cnt == 1 when data_bitlen == 0.  Do you
> really want that?

My suggested
  ((data_bitlen)/256) + ((data_bitlen%256) != 0);
expression gives the same results as the OP's original
  ceil(data_bitlen/256.)
expression.

I apologize if I did not make it clear that the suggested expression was a substitution for the original ceil() 
expression, making the OP's
  u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
into
  u64 blk_cnt = (data_bitlen == 0) ? 1 : ((data_bitlen)/256) + ((data_bitlen%256) != 0);
and thus keeping the computation within the realm of integer math.


-- 
Lew Pitcher
"In Skills, We Trust"

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

#149168

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> Ben Bacarisse wrote:
>
>> m.nasim85@gmail.com writes:
>> 
>>> Lew, acctually, I cannot accept either
>>>>   blk_cnt = ((data_bitlen)/256) + ((data_bitlen%256)/(data_bitlen%256))
>>> or
>>>>   blk_cnt = ((data_bitlen/256) + ((data_bitlen%256) != 0))
>>>
>>> 1st form may divide by zero. (you mentioned this)
>>> 2nd form may have unpredictable behavior as ((data_bitlen%256) != 0)
>>> returns TRUE ,which is only guaranteed not to be zero. it may be 1
>>> (which you intended) or -1.
>> 
>> No.  All of C's equality and comparison operators are defined to give
>> either 0 or 1.  No other value is possible.  Some of C's /functions/
>> don't behave this way (strcmp, isascii etc.), but that another matter.
>> 
>> But Lew's second suggestion does not do what your original code did.
>> Your code had the odd exception that the block count should be 1 when
>> the bit length was zero.  If you just want the number of whole or part
>> 256-bit blocks, the usual way is to write
>> 
>>   blk_cnt = (data_bitlen + 255) / 256;
>> 
>> but that does not give blk_cnt == 1 when data_bitlen == 0.  Do you
>> really want that?
>
> My suggested
>   ((data_bitlen)/256) + ((data_bitlen%256) != 0);
> expression gives the same results as the OP's original
>   ceil(data_bitlen/256.)
> expression.

Ah, sorry, I thought you were replacing the whole thing.  Easy to miss
since the OP's whole expression is rather odd.  I don't think I've ever
wanted a "block" count of 1 when the "part" count is 0!

> I apologize if I did not make it clear that the suggested expression
> was a substitution for the original ceil() expression, making the OP's
>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
> into
>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ((data_bitlen)/256) + ((data_bitlen%256) != 0);
> and thus keeping the computation within the realm of integer math.

-- 
Ben.

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

#149244

> 
> I apologize if I did not make it clear that the suggested expression was a substitution for the original ceil() 
> expression, making the OP's
>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
> into
>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ((data_bitlen)/256) + ((data_bitlen%256) != 0);
> and thus keeping the computation within the realm of integer math.
> 
don't apologize to me, i have figured that out since first post.
apologize to Ben Bacarisse :)

actually, i am the one who should apologize to you, Ben Bacarisse and James Kuyper has shown that your expression was correct.

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

#149249

m.nasim85@gmail.com writes:

>> 
>> I apologize if I did not make it clear that the suggested expression was a substitution for the original ceil() 
>> expression, making the OP's
>>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
>> into
>>   u64 blk_cnt = (data_bitlen == 0) ? 1 : ((data_bitlen)/256) + ((data_bitlen%256) != 0);
>> and thus keeping the computation within the realm of integer math.
>> 
> don't apologize to me, i have figured that out since first post.
> apologize to Ben Bacarisse :)

He did -- the message you are relying to here was a rely to me!  Mind
you, I hardly think it was called for.  He is obviously a very polite
person.  It was, after all, my mistake to assume he had discarded the
unusual requirement to have the block count be 1.

-- 
Ben.

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

#149242

> 
> but that does not give blk_cnt == 1 when data_bitlen == 0.  Do you
> really want that?
> 
> -- 
> Ben.

Yes, i want that.
In an implementation for a hash function, there must be something to hash. Try running MD5 or SHA against empty string, and you still have output.
In my case, i process a block of all zeros.
May be this is not the most ideal method to implement the hashing function. however, it still works.

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

#149247

m.nasim85@gmail.com writes:

>> but that does not give blk_cnt == 1 when data_bitlen == 0.  Do you
>> really want that?
>> 
> Yes, i want that.
> In an implementation for a hash function, there must be something to
> hash. Try running MD5 or SHA against empty string, and you still have
> output.

With SHA-1 the source bits have the length appended (after some padding)
so there is always something to hash.  The data length being zero is not
a special case.

> In my case, i process a block of all zeros.

I don't know the structure of the rest of the code, but that would imply
the data_bitlen == 0 is a special case requiring more action than
setting a fake block count.  In other words, I'd handle it the top level:

  void hash(const void *data, size_t bit_len, void *output_buffer)
  {
      static char zeros[512/CHAR_BIT];
      if (len == 0)
          hash(zeros, 512, output_buffer);
      else {
          ...
      }
  }

Anyway, if setting a block count of 1 when the bit length is 0 works
with the rest of the code there's no point in changing it.

> May be this is not the most ideal method to implement the hashing
> function. however, it still works.

It does seem odd.  You've set up two known inputs with the same hash
which is usually considered a bad idea, but it may not matter for your
usage.

-- 
Ben.

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

#149153

> 2nd form may have unpredictable behavior as
> ((data_bitlen%256) != 0) returns TRUE ,which is only guaranteed
> not to be zero. it may be 1 (which you intended) or -1.

C is a case sensitive language. The C standard doesn't define the
identifier "TRUE". The identifier "true" is #defined as a macro
by <stdbool.h>, but here's what the standard says about it:

"[the true macro] expands to the integer constant 1." (7.18p3).

That isn't actually relevant, however, because the standard makes
no use of that macro in connection with the != operator. What it
actually says is:

"[the == and != operators] yield 1 if the specified relation is
true, and 0 if it is false" (6.5.9p3).

It says something similar about each of the other logical
Operators: ! < > <= >= && and ||.

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

#149243

On Wednesday, 15 January 2020 20:49:54 UTC+2, James Kuyper  wrote:
> > 2nd form may have unpredictable behavior as
> > ((data_bitlen%256) != 0) returns TRUE ,which is only guaranteed
> > not to be zero. it may be 1 (which you intended) or -1.
> 
> C is a case sensitive language. The C standard doesn't define the
> identifier "TRUE". The identifier "true" is #defined as a macro
> by <stdbool.h>, but here's what the standard says about it:
> 
> "[the true macro] expands to the integer constant 1." (7.18p3).
> 
> That isn't actually relevant, however, because the standard makes
> no use of that macro in connection with the != operator. What it
> actually says is:
> 
> "[the == and != operators] yield 1 if the specified relation is
> true, and 0 if it is false" (6.5.9p3).
> 
> It says something similar about each of the other logical
> Operators: ! < > <= >= && and ||.

I know that C is a case sensitive language. just was trying to highlight the return value.

Thank you for mentioning what standard says, now i can use Lew's expression.

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

#148853

On Tuesday, 7 January 2020 17:24:15 UTC, Lew Pitcher  wrote:
> m.nasim85@gmail.com wrote:
> 
> > On Thursday, 2 January 2020 18:51:02 UTC+2, Barry Schwarz  wrote:
> >> Are you aware that ANDing zero to anything produces zero ...
> >> 
> >> >    *type = *type | CFG;
> >> 
> >> and ORing any value to zero results in that value.  Why not use the
> >> simpler
> >>     *type = CFG:
> >> 
> >> Is your machine big- or little-endian?  If little, you have modified
> >> the high-order byte and produced a pretty strange value.  If big
> >> endian, then
> >>    T[1] = CFG;
> > 
> > thank you Barry for your comment.
> > 
> > Why not use the
> > simpler
> >     *type = CFG:
> > 
> > I just was editing code, not initiating a new one. just wanted to comment
> > some lines to see the effect.
> > 
> > Finally, i have found the error. Somewhere in UBI256(), i found this line:
> > u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256);
> > which should be
> > u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
> > Later, this simple change would affect pointer location.
> 
> If <<data_bitlen>> were an integer, than (data_bitlen/256) would give the 
> floor() value, making ceil(data_bitlen/256) off by one when
> (data_bitlen%256 != 0). Coercing the division into floatingpoint by dividing 
> by 256. would give a value that /could/ be rounded up under those 
> conditions.
> 
> This implies to me that <<data_bitlen>> is defined as an integer.
> 
> If so, then wouldn't the integer-only
>   ((data_bitlen)/256) + ((data_bitlen%256)/(data_bitlen%256))
> give the the same results as
>   (int)ceil(data_bitlen/256.)
> ?
> 
Looks wrong to me. It generates a divide by zero if data_bitlen is a multiple
of 256.

You probably want

data_bitlen == 0 ? 1 : (data_bitlen + 255)/256;

However beware of overflow if int is 16 bits and bit lengths are high.

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

#149142

> You probably want
> 
> data_bitlen == 0 ? 1 : (data_bitlen + 255)/256;
> 
> However beware of overflow if int is 16 bits and bit lengths are high.


Thank you Malcolm,
  i will use this form in my code and remove #include <cmath> :)

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

#148699

On 1/2/20 4:34 AM, m.nasim85@gmail.com wrote:
> hello everybody,
> i have a piece of code that never call or affect pointer 'M', but i realize that pointer 'M' change to point to NULL.
> can someone revise my code..
> 
> [code]
> void SkeinHash256(u8* M, u64 Ni, u64 No, u8* hash)
> {
>     // "SHA3" string + version 0x0001
>     u8 cfg[32] = {0x53, 0x48, 0x41, 0x33, 0x01, 0x00, 0x00, 0x00};
>     u64* out_size = (u64*) (cfg + 8);
>     *out_size = No;
> 
>     u8 K[32] = {0};
>     u64 T[2] = {0};
>     u8 G0[32] = {0};
>     u8 G1[32] = {0};
> 
>     u8* type = ((u8*)T) + 15;
> 
>     u8 zero = 0;
>     *type = *type & zero;
>     *type = *type | CFG;
>     UBI256(K, cfg, T, 256, G0);
> 
>     *type = *type & zero; // here, 'M' starts pointing to NULL
> [/code]
> 
Assuming that u8 and u64 are typedefs for uint8_t and uint64_t
respectively (which would be a dumb thing to do), then the visible part
of this code doesn't seem to have any way in which it could change the
value of M.

However, you don't provide any definition for UBI256(). If that is the
name of a function, it might change the value of M writing past the end
(or, less likely, before the beginning) of the arrays pointed at by it's
arguments. All of those arrays are local to this function, and stand a
decent chance of being stored near the same location as M.

If UBI256 is the name of a function-like macro, all bets are off - just
about anything could go wrong when invoking it, there's no way to tell
from what you've written here.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web