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

Groups > comp.lang.c > #148852

Re: Pointer goes to null

Followups directed to: comp.lang.c

Show all headers | View raw

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))

OK, so above gives undefined behaviour when data_bitlen%256 == 0
(division by zero)

So, a variation

  ((data_bitlen/256) + ((data_bitlen%256) != 0))

should simplify things

> give the the same results as
>   (int)ceil(data_bitlen/256.)
> ?
> 
> Could you drop the floatingpoint math in favour of all-integer math?
> 
>> 
>> again Thanks to Bart and Barry for you help and thanks to all
>> contributors.
>> 
>> After all, that was my first post in comp.lang.c group. and this is the
>> first group where i find replies out of topic. People are commenting
>> coding style instead of helping solve problems. Comments are tough
>> somewhat "dumb, stupid, Obfuscated C competition, ...etc" I am totally
>> impressed why people talk like so. It is easier to say "i don't know" or
>> just don't post a reply.
> 
> 


-- 
Lew Pitcher
"In Skills, We Trust"

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web