Author Topic: Extended disruption  (Read 1518 times)

0 Members and 1 Guest are viewing this topic.

Brian Alvarez

  • Guest
Extended disruption
« on: May 25, 2019, 10:36:50 AM »
Hello Charles, here's another weird one for you, i hope i am still on time to
include this fix in the update, i hope you dont mind the senseless code, the
code ended like this when i narrowed the error to this corner:

Code: [Select]
MACRO fill_zstring(v, c   nc)
    zstring nc = c       
END MACRO

FUNCTION NEEDED() AS INT

ZSTRING vstringz[32]
EXTENDED v3

fill_zstring(vstringz, ("Hello world 30"))

v3 = ((v3) - 1)

print "EXTENDED value: " v3 chr(13, 10)

END FUNCTION

NEEDED()

Output:

Code: [Select]
EXTENDED value: #qNAN
  • Execute the code outside of NEEDED() and the error dissapears.
  • Do not bracket the "Hello world 30" string, the error dissapears.
  • Change "Hello world 30" to "Hello world", the error dissapears (whatever text longer than 12 characters triggers it back).
  • Call zstring nc = c outside of a macro, the error dissapears.
  • Do not assign a value to nc, the error dissapears.
  • Use v3 = -1, the error dissapears (v3 -= 1 also causes this disruption).
  • Initializing v3 to a 0 value before the macro, doesn't fix it.
  • Initializing v3 to a 0 value after the macro, the error dissapears.
  • Declare v3 before vstringz, the error dissapears.
  • Define another variable after v3, the error dissapears (unless you increase the length of the string literal).
  • Using a DOUBLE data type instead of Extended... you guessed, the error dissapears.
« Last Edit: May 25, 2019, 11:47:08 AM by Brian Alvarez »

Aurel

  • Guest
Re: Extended disruption
« Reply #1 on: May 25, 2019, 10:47:08 AM »
Heh ..it looks to me that you like to made same mistakes ..
add content when you declare zstring.
..and what a heck is extended v3  :o

also last param nc should be optional ...
not just extension of first letter ..right?

Charles ...sorry but such a construction should be illegal
no type under macro params ???

Brian Alvarez

  • Guest
Re: Extended disruption
« Reply #2 on: May 25, 2019, 11:04:41 AM »
Aurel, please re-read everything. Did you tried your solutions before suggesting them?

I  explained that this code makes no sense, it ended like this after narrowing the error.

 About the no type under macro params... do you understand macros? :)

Aurel

  • Guest
Re: Extended disruption
« Reply #3 on: May 25, 2019, 11:32:45 AM »
Yes  i understand that such a thing should be error but because of tooooo liberal o2 syntax that sort of things are
possible.
about your first post about zstring2 i tried ..yes

do i understand macro ?
what kind of question is that man  :o
oups ..sorry i made mistake  ,i was thinking about something else.
ok continue...  :D

Brian Alvarez

  • Guest
Re: Extended disruption
« Reply #4 on: May 25, 2019, 11:40:38 AM »

Im trying very hard to make sense of what you say.  :P

Charles Pegge

  • Guest
Re: Extended disruption
« Reply #5 on: May 25, 2019, 06:27:33 PM »
Hi Brian,

The problem is caused by zstring/char overflow in the macro.

This works:

zstring nc[32] = c

Code: [Select]
MACRO fill_zstring(v, c,   nc)
    zstring nc[32] = c
END MACRO

Brian Alvarez

  • Guest
Re: Extended disruption
« Reply #6 on: May 25, 2019, 07:58:39 PM »
I understand.

 The problem with that is that i dont know the size of the buffer at compilation time,
i can pass a variable with the length, but i cant use anything else than a literal in there.

I will try using a notmal buffer created with getmemory.

Brian Alvarez

  • Guest
Re: Extended disruption
« Reply #7 on: May 25, 2019, 08:07:19 PM »
 I changed the macro like this and it works:

Code: [Select]
MACRO fill_zstring(v, c, l   nc)
    if l<1 then
        copy @v, chr(0), 1
    else
        bstring nc = left(c, l-1) + chr(0)
        copy @v, strptr(nc), len(nc)
        frees nc         
    end if       
END MACRO

I thought that when zstrings were not provided with a size, the size would depend on the buffer being stored in them.

Thanks!

Charles Pegge

  • Guest
Re: Extended disruption
« Reply #8 on: May 26, 2019, 02:16:40 AM »
I would do it this way:

v=left(c,spanof(v)-1)

Code: [Select]
MACRO fill_zstring(v, c)
  'v direct zstring, asciiz or char
  'c dynamic string source of any length
  v=left(c,spanof(v)-1)
END MACRO

zstring v[6]
print spanof(v)
fill_zstring(v,"BB") 'fills with 2 chars and null char
print v
fill_zstring(v,"BBBBBBBBBB") 'fills with 5 chars and null char
print v
« Last Edit: May 26, 2019, 05:45:29 AM by Charles Pegge »

Aurel

  • Guest
Re: Extended disruption
« Reply #9 on: May 26, 2019, 06:11:10 AM »
fill_zstring(v, c, l   nc)

Is there anyone who can explain to me
what  is a param l  nc
..and why is not error  :o

// I don't use very much macro()s in my programs so i don't care
but there are some advantages using them.  ;)

thanks
« Last Edit: May 26, 2019, 06:18:06 AM by Aurel »

Brian Alvarez

  • Guest
Re: Extended disruption
« Reply #10 on: May 26, 2019, 06:31:00 AM »
Is there anyone who can explain to me
what  is a param l  nc
..and why is not error  :o

PluriBASIC generates this macro containing, v,  "variable" address, This can also be a pointer to the UDT member space,
 thats why it cannot be simply v = "". The new contents come in c, it can also exceed the length of the targed space,
so, it must be trimmed. The l is the length of the target zstring, required to trim the new contents. nc is just a "macrotemp".

Macros are like another compiler inside the compiler. If you dont learn how to use them, you are missing. You will have to hard-code
stuff or write much more code. Macros generate dynamic code at compilation time.

 For example, in my code i use macros to generate array classes for all data types. Using just a few macros, the code for all data-types are
generated. If it wasnt for macros i would have to write like 20 times more code and mantain every class separately. With macros, editing
one macro, the changes expands to all the generated classes.