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 1 of 2  [1] 2  Next page →

#148672 — Pointer goes to null

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]

[toc] | [next] | [standalone]

#148675

On Thu, 2020-01-02, 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]

I won't try myself, but you'd probably get better help if you posted
code which at least /compiles/ and shows the problem.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#148679

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]

What Jorgen said.

However, some observations:
1) you use non-standard (and therefore, unknown) types to declare all your
   objects. This means that, with the code given, we cannot determine
   /anything/ about those objects, including sizeof and format. For all /we/
   know, <<u8>> is actually <<long float>>, or even <<struct FILE>>.

2) you set <<out_size>> and <<type>> to point to specific, pre-computed
   (magic number) locations in other objects. This is dangerous, especially
   as those objects are defined with (to us) indeterminate types. Given
     u64 T[2] = {0};
   and
     u8* type = ((u8*)T) + 15;
   does
     <<type>> point to a location /within/ T, or /outside/ it?

3) given your demonstrated tendancy to use unknown types and hardcode
   displacements within them, are you sure that
      UBI256(K, cfg, T, 256, G0);
   does not, somehow, walk over the storage set aside for the automatic
   variables and parameters of SkeinHash256()? This is where I would look
   for answers as to why, after UBI256(), the SkeinHash256() has changed to
   NULL.

HTH
-- 
Lew Pitcher
"In Skills, We Trust"

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

#148691

On 02/01/2020 13:55, Lew Pitcher wrote:
> 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]
> 
> What Jorgen said.
> 
> However, some observations:
> 1) you use non-standard (and therefore, unknown) types to declare all your
>     objects. This means that, with the code given, we cannot determine
>     /anything/ about those objects, including sizeof and format. For all /we/
>     know, <<u8>> is actually <<long float>>, or even <<struct FILE>>.

Then you can't really assume anything about any program, for example 
'int' may be defined as:

     #define int double

Most probably it isn't; and most probably u8 and u64 represent unsigned 
8- and 64-bit types.

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

#148693 — UB awaits... (Was: Pointer goes to null)

In article <3XqPF.691098$kBJ1.374933@fx12.am4>, Bart  <bc@freeuk.com> wrote:
...
>Then you can't really assume anything about any program, for example
>'int' may be defined as:
>
>     #define int double

Pretty sure that produces UB.

>Most probably it isn't; and most probably u8 and u64 represent unsigned
>8- and 64-bit types.

Of course.  Still, Lew's point is valid.

-- 
I shot a man on Fifth Aveneue, just to see him die.

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

#148696 — Re: UB awaits... (Was: Pointer goes to null)

On 02/01/2020 20:53, Kenny McCormack wrote:
> In article <3XqPF.691098$kBJ1.374933@fx12.am4>, Bart  <bc@freeuk.com> wrote:
> ...
>> Then you can't really assume anything about any program, for example
>> 'int' may be defined as:
>>
>>      #define int double
> 
> Pretty sure that produces UB.

It's a good starting point for the Obfuscated C competition.

> 
>> Most probably it isn't; and most probably u8 and u64 represent unsigned
>> 8- and 64-bit types.
> 
> Of course.  Still, Lew's point is valid.
> 

Yes - precisely because some people actually do stupid things.  Look at 
enough code, and you'll find someone who has written:

// typedef u8 unsigned char;
typedef u8 unsigned short int;		// Changed to avoid overflow


or simply:

typedef u32 unsigned long;

and then tried to port the code to 64-bit Linux.


In this particular case, I'd wonder if the bug lies in some code 
elsewhere, such as a pointer error in UBI256 that corrupts part of the 
stack leading to these symptoms.  It is always wise to boil the code 
down to a minimum /compilable/ snippet that can demonstrate the issue. 
(Also, that is a good exercise and often helpfully reveals the bug.)

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

#148698 — Re: UB awaits...

David Brown <david.brown@hesbynett.no> writes:
<cut>
> Yes - precisely because some people actually do stupid things.  Look
> at enough code, and you'll find someone who has written:
>
> // typedef u8 unsigned char;
> typedef u8 unsigned short int;        // Changed to avoid overflow

  typedef unsigned short int u8;        // Changed to avoid syntax error!

-- 
Ben.

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

#148701 — Re: UB awaits...

On 03/01/2020 02:43, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>> Yes - precisely because some people actually do stupid things.  Look
>> at enough code, and you'll find someone who has written:
>>
>> // typedef u8 unsigned char;
>> typedef u8 unsigned short int;        // Changed to avoid overflow
> 
>   typedef unsigned short int u8;        // Changed to avoid syntax error!
> 

Of course.  For some reason, I make that mistake in Usenet posts - this
is not the first time.

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

#148710 — Re: UB awaits...

David Brown <david.brown@hesbynett.no> writes:

> On 03/01/2020 02:43, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>> Yes - precisely because some people actually do stupid things.  Look
>>> at enough code, and you'll find someone who has written:
>>>
>>> // typedef u8 unsigned char;
>>> typedef u8 unsigned short int;        // Changed to avoid overflow
>> 
>>   typedef unsigned short int u8;        // Changed to avoid syntax error!
>> 
>
> Of course.  For some reason, I make that mistake in Usenet posts - this
> is not the first time.

Me too; I think because it's a rather unexpected syntax.

-- 
Ben.

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

#148718 — Re: UB awaits...

On 03/01/2020 15:30, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 03/01/2020 02:43, Ben Bacarisse wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> <cut>
>>>> Yes - precisely because some people actually do stupid things.  Look
>>>> at enough code, and you'll find someone who has written:
>>>>
>>>> // typedef u8 unsigned char;
>>>> typedef u8 unsigned short int;        // Changed to avoid overflow
>>>
>>>   typedef unsigned short int u8;        // Changed to avoid syntax error!
>>>
>>
>> Of course.  For some reason, I make that mistake in Usenet posts - this
>> is not the first time.
> 
> Me too; I think because it's a rather unexpected syntax.
> 

I don't typically make the same mistake in code, however - only in
posts.  Perhaps the difference is that I don't use types like "unsigned
short int" in my code - I mostly use size-specific types, and
occasionally "int".  (And char, pointers, etc.)  So I'd happily write
"typedef uint16_t adc_sample_t;" in code, but not "typedef unsigned
short int adc_sample_t;".

Or maybe I've been using "using" in C++ too much recently.

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

#148682

On 02/01/2020 09:34, 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]

You can try a few things such as commenting out lines that write to 
memory, one at a time until M stops changing to NULL. For example, the 
call to UBI256: how does it know how big those arrays are?

(They are all 32 bytes except T which is 16 bytes.)

Or print the value of M after each assignment:

     printf("M = %p\n",M);

So that you can see where it changes.

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

#148685

On Thursday, 2 January 2020 16:07:34 UTC+2, Bart  wrote:
> You can try a few things such as commenting out lines that write to 
> memory, one at a time until M stops changing to NULL. For example, the 
> call to UBI256: how does it know how big those arrays are?
> 
> (They are all 32 bytes except T which is 16 bytes.)
> 
> Or print the value of M after each assignment:
> 
>      printf("M = %p\n",M);
> 
> So that you can see where it changes.

First of all, thanks to Jorgen and Lew for their help
BTW u8 = 8bit unsigned integer. and u64 = 64bit unsigned integer.

Bart, my code does not contain global variables and as you see in my code UBI() does not take 'M' as an argument. The only possibility for 'M' to be updated by UBI() is that one pointer has gone out of supposed range and affected it.
I will revise my code and revisit this group. Thanks for printing 'M' values clue. it may help.

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

#148690

m.nasim85@gmail.com writes:
[...]
> BTW u8 = 8bit unsigned integer. and u64 = 64bit unsigned integer.

You code would be clearer if you used the standard uint8_t and uint64_t,
defined in <stdint.h>.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
    [Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

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

#148686

Il 02/01/2020 10:34, m.nasim85@gmail.com ha scritto:
> 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]
> 

Hi,
look inside your C compiler documentation. You should find the name of a 
source file in assembler called "main stub". To do what you want, you 
should edit and recompile that file. This is what I had to do with an 
old M$ compiler when I had the same issue as you.

Cheers

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

#148688

On Thu, 2 Jan 2020 01:34:08 -0800 (PST), 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..

If your code does not use M at all, why are you passing it into the
function in the first place?

>[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;

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;
would be a lot simpler.

>    UBI256(K, cfg, T, 256, G0);

Are you sure M is unchanged when UBI256 returns?  How does this
function know how big the arrays are?  What does the 256 signify?

All the arrays passed in are 32 bytes wide except T which is only 16.
Is that the way it's supposed to be?

>    *type = *type & zero; // here, 'M' starts pointing to NULL

If this statement actually causes the change to M, you need to find
out who changed type to point to M instead of pointing to the last
byte of T.  

Furthermore, since *type is a u8, this statement can change only the
one byte it points to, wherever that is.  Unless your pointers are
only one byte wide, it is very unlikely that changing one byte of a
pointer will cause it to become NULL.

-- 
Remove del for email

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

#148732

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.

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.

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

#148735

On Fri, 3 Jan 2020 16:20:20 -0800 (PST), 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.
>
>again Thanks to Bart and Barry for you help and thanks to all contributors.

I'll take your word that this solves your problem.  But it seems very
strange.  M was never passed to UBI256 so that function could not
change it.  test was passed by value so after UBI256 returns your
function will see it unchanged.  Therefore, the statement 
   *test = ....
cannot change M

The net effect of the change you made was to possibly change the value
of blk_cnt by 1.  For example, if data_bitlen is 384, integer division
by 256 results in 1 which is what ceil will return.  Floating point
division by 256.0 results in 1.5 and ceil will return 2.  If
data_bitlen is a multiple of 256, both expressions return that
multiple.  How can this affect M?

-- 
Remove del for email

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

#148831

On Saturday, 4 January 2020 08:16:21 UTC+2, Barry Schwarz  wrote:
> On Fri, 3 Jan 2020 16:20:20 -0800 (PST), m.nasim wrote:
> 
> >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.

> I'll take your word that this solves your problem.  But it seems very
> strange.  M was never passed to UBI256 so that function could not
> change it.  test was passed by value so after UBI256 returns your
> function will see it unchanged.  Therefore, the statement 
>    *test = ....
> cannot change M

Well, this is because blk_cnt will be used later in pointer arithmetic and blk_cnt should never be zero.
as you see
u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256.0);
the above line will return 1 even if there is no data at all to hash. But, 
u64 blk_cnt = (data_bitlen == 0) ? 1 : ceil(data_bitlen / 256);
will return 0 if data_bitlen is less than 256 bits.

again this solved the problem because of pointer arithmetic that uses blk_cnt.

Thank you Barry

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

#148851

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

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"

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

#148852

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"

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web