Allocating an array, several ways

Index > Main > Allocating an array, several ways

Author

Thread

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 08 Oct 2017, 23:39

I'm trying to create an array/buffer where I can read a file into. Are these 3 instructions the same? If now, what's the difference?

Code:

    ; 1 
    buff: times 1000 db ?
    
    ; 2
    buff rb 1000

    ; 3
    buff db 0 dup 1000

Do they all allocate a space of 1000 elements 1 byte each?
What's the correct and most common way?

When I'm using the #3, only a part of a file is printed out, other parts, beginning and end, are getting lost. Unlike in #1 and #2 -- using them it's printed correctly.

Last edited by jorido on 09 Oct 2017, 02:26; edited 1 time in total

08 Oct 2017, 23:39

system error

Joined: 01 Sep 2013
Posts: 670

system error 09 Oct 2017, 01:45

#3
buff db 1000 dup(0)

1000 = size
dup(0) = initializers

09 Oct 2017, 01:45

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 09 Oct 2017, 02:34

system error wrote:

#3
buff db 1000 dup(0)

1000 = size
dup(0) = initializers

how come, say

"buff db 100" allocates a single byte and puts value "100" in it

and

"buff db 100 dup(0)" allocates 100 bytes?

that is, they have the same part buff db 100 in common but do different things[/b]

09 Oct 2017, 02:34

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20526
Location: In your JS exploiting you and your system

revolution 09 Oct 2017, 04:17

The first option with times gives a slightly different result because there is no size attached to the buff variable.

Code:

buff: db ?
mov [buff],0xff ;<--- error operand size not specified

Compare to this:

Code:

buff db ?
mov [buff],0xff ;<-- okay

09 Oct 2017, 04:17

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8367
Location: Kraków, Poland

Tomasz Grysztar 09 Oct 2017, 07:07

jorido wrote:

how come, say

"buff db 100" allocates a single byte and puts value "100" in it

and

"buff db 100 dup(0)" allocates 100 bytes?

that is, they have the same part buff db 100 in common but do different things[/b]

The fasm's language was designed to be mostly LL(1), but there are a few places where it is not, including the DUP feature which was implemented for compatibility with some older assemblers.

09 Oct 2017, 07:07

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 09 Oct 2017, 09:37

Ok.

"buff db 100" and "buff db 100 dup(0)" indeed do different things: allocating single byte with value 100 and 100 bytes with zeroes, right?

09 Oct 2017, 09:37

system error

Joined: 01 Sep 2013
Posts: 670

system error 09 Oct 2017, 19:37

jorido wrote:

Ok.

"buff db 100" and "buff db 100 dup(0)" indeed do different things: allocating single byte with value 100 and 100 bytes with zeroes, right?

Right.

One more little step to make it easier for you is to use a constant

MAXSIZE = 1000

xdata TIMES MAXSIZE db 0
xdata rb MAXSIZE
xdata db MAXSIZE dup(0)

You show some genuine efforts, we give you help some more Very Happy

09 Oct 2017, 19:37

Furs

Joined: 04 Mar 2016
Posts: 2599

Furs 09 Oct 2017, 20:47

jorido wrote:

how come, say

"buff db 100" allocates a single byte and puts value "100" in it

and

"buff db 100 dup(0)" allocates 100 bytes?

that is, they have the same part buff db 100 in common but do different things[/b]

Yeah, it's messed up, unfortunately. It's a syntax quirk FASM got from other assemblers Confused

Sadly, "buf times 100 db 0" is not valid... you should use a macro to get rid of this stupid syntax.

09 Oct 2017, 20:47

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 11 Oct 2017, 13:42

Are

Code:

    buff rb 1000
    buff db 1000 dup(0)

exactly the same?

11 Oct 2017, 13:42

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20526
Location: In your JS exploiting you and your system

revolution 11 Oct 2017, 13:48

jorido wrote:

Are

Code:

    buff rb 1000
    buff db 1000 dup(0)

exactly the same?

No.

The first is uninitialised. In some file formats the data is not included in the executable, only its size is given.

The second has explicit initialisation of all 0's. The executable will contain every one of those zero bytes.

11 Oct 2017, 13:48

Furs

Joined: 04 Mar 2016
Posts: 2599

Furs 11 Oct 2017, 14:11

Note that "uninitialized" means also zero-ed (by the OS) on load on most platforms (Linux, Windows, etc), so there's no point in using dup(0) at all. It will only waste space on disk for no gain.

If you want something zero-initialized use rb since it saves space on disk and is otherwise "the same" functionally, unless the target OS doesn't zero-initialize data (DOS maybe? idk).

11 Oct 2017, 14:11

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 12 Oct 2017, 01:00

but when I compile it using first buff rb 1000 and then buff db 1000 dup(0), the sizes, in bytes, of output files are identical

12 Oct 2017, 01:00

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20526
Location: In your JS exploiting you and your system

revolution 12 Oct 2017, 01:40

It depends on the layout of the code. If you are using a PE file for example then if you have initialised values following uninitialised space then the uninitialised will still be included.

Code:

format pe ..
section ...
 uninit rb 1000
 inited db 'a' ;<--- this value will force all preceding values to be inclucded

Compare to:

Code:

format pe ..
section ...
 inited db 'a'
 uninit rb 1000 ;<--- this won't be included in the output file.

12 Oct 2017, 01:40

jorido

Joined: 23 Jan 2017
Posts: 53

jorido 12 Oct 2017, 14:16

linux, x64

or did Furs mean only if I initialize an array but don't actually use it at all?

12 Oct 2017, 14:16

Furs

Joined: 04 Mar 2016
Posts: 2599

Furs 12 Oct 2017, 15:37

I'm not sure I understand the question, but...

Initialization means that the value of that buffer will be the given value on entry to the program. 'rb' reserves bytes, but those bytes are initialized to zero on Linux/Windows, without taking space on disk. So when at your program's entry point, they'll be zeros.

It's like allocating a block of memory containing all your 'rb' stuff and then zero-ing them in a loop before your program's entry point is even executed. (that's what the OS does)

If you used 'db' instead, it would copy them from the disk to the memory block instead of zeroing it, thus if data is zeros, it would waste it on the disk for no reason, since it ends up being zeros in memory anyway.

Note that, as revolution said, you shouldn't mix db with rb in same section/segment. Just put all 'rb' in their separate section/segment.

12 Oct 2017, 15:37

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20526
Location: In your JS exploiting you and your system

revolution 13 Oct 2017, 00:18

Furs wrote:

Note that, as revolution said, you shouldn't mix db with rb in same section/segment. Just put all 'rb' in their separate section/segment.

I was suggesting that if you put the uninitialised data at the end of a segment then the assembler can mark it with just a length. But you can still put initialised data with it as long as it comes first.

13 Oct 2017, 00:18

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum