Strings

[Astro]

If you're taking arbitrary input, how do you allocate the right amount of memory for it in assembler?

I know MASM offers "easier" ways to do this, but I'd like to understand how it is done. As I type I'm looking to see if there are any macros that do this that I can look at.

Best regards,
Astro.

[Tedd]

Usually there's some expected maximum, so you allocate enough space for that and there shouldn't be a problem. (Don't forget to add one for a terminating NULL.)
In most cases you're able to restrict the amount input, so you can enforce a maximum - then you only need to allocate enough for that - e.g. for a text box you can set the maximum (EM_SETLIMITTEXT) to whatever is necessary for your needs.
For command-line arguments, the command prompt complains for any input over 259 characters, so 260 bytes should usually be enough (or 520 for the 'wide' version.) But I don't think that limit is imposed when processes are started by other programs, or in batch files; I've seen programs allocate 4096 bytes to be safe.

[Astro]

What about the case of opening text files, or similar?

Best regards,
Astro.

[sonic]

You could vitually allocate the memory according to filesize you are opening. Use GetFileSize.

[dedndave]

FindFirstFile may also be used to get the size
i generally prefer the heap allocation functions
they are easy to use
the blocks created may be resized
allocated blocks are not initialized to 0 - so it's fast
i have also noticed that, after releasing a block, it can still be used
although, any future allocation may overwrite the block, of course
so it's not a good idea to use it that way

[hutch--]

If you meed to you test the length of the input first THEN allocate at least that much memory. If there is some reason why you cannot test the length, make the input buffer BIG, 64k won't hurt you at all and few could last long enough tp type that many characters. Most people forget that a megabyte on a modern computer is trivial, what is the point of allocating 256 bytes when the memory page is 4k ? Even with stack variables 64k is no big deal, a default PE file has a 1 meg stack.

[Sponge Magnet]

If you meed to you test the length of the input first THEN allocate at least that much memory. If there is some reason why you cannot test the length, make the input buffer BIG, 64k won't hurt you at all and few could last long enough tp type that many characters. Most people forget that a megabyte on a modern computer is trivial, what is the point of allocating 256 bytes when the memory page is 4k ? Even with stack variables 64k is no big deal, a default PE file has a 1 meg stack.

Some have fears of going over the memory usage of 300 kb (or that's just me  :green2). I like to keep my programs around 250k or below.

[hutch--]

Look at the Task manager memory allocation size for your running app and saee why it does not matter.

[Sponge Magnet]

Look at the Task manager memory allocation size for your running app and saee why it does not matter.

176 kb while doing a cpu-intensive task.  :dance:

---

I am ABSOLUTELY BLOWN AWAY to how this file is 4 KB (3,584 bytes)!

[Astro]

I'm trying not to get size-obsessed!  :U  I must say though it is pretty awesome writing something that compiles to 2 kB when it previously compiled to 45 kB in unmanaged C++.  :eek

  ;TCHAR  DevicePath[ANYSIZE_ARRAY]
  DevicePath BYTE 4096 DUP (?)

Where I have an unknown size string, is the above code correct? This is defined in a structure. Original code is the comment (C++) and the assembler is my guess.

Best regards,
Astro.

[Sponge Magnet]

I'm trying not to get size-obsessed!  :U  I must say though it is pretty awesome writing something that compiles to 2 kB when it previously compiled to 45 kB in unmanaged C++.  :eek

  ;TCHAR  DevicePath[ANYSIZE_ARRAY]
  DevicePath BYTE 4096 DUP (?)

Where I have an unknown size string, is the above code correct? This is defined in a structure. Original code is the comment (C++) and the assembler is my guess.

Best regards,
Astro.

If you're not checking what's beginning inputted, you could do the following: (For directory searching/file open)

Code Select Expand

DevicePath db MAX_PATH dup(?)

To me, it depends on what you're doing. Looks like you're working with USB?

---

EDIT: Hell, just allocate 10kb.  :bdg

[Astro]

Hi,

Yes I am.

EDIT: Hell, just allocate 10kb.

:cheekygreen:

Best regards,
Astro.

[dedndave]

I must say though it is pretty awesome writing something that compiles to 2 kB when it previously compiled to 45 kB in unmanaged C++.

here, in the masm32 forum, we try not to "compile" anything - lol
we prefer to "assemble" stuff
(all part of the training for these former C guys)

[Astro]

Ahhh - OK!  :P

Best regards,
Astro.

[redskull]

if you are REALLY size-obsessed, then can do the input one character at a time, each time resizing the heap-reserved memory by a single character (HeapAlloc, HeapReAlloc).  The tradeoff is of course speed, and perhaps even increasing the code size past what a buffer would cost you.  But you don't waste a single byte of memory, nor do you impose any sort of maximum input.

-r