Can't find string in memory

This is a discussion on Can't find string in memory within the C Programming forums, part of the General Programming Boards category; I am working on a project,and can't figure out why the segment and offset does not point to the 123456789 ...

  1. #1
    Registered User
    Join Date
    Sep 2001
    Posts
    5

    Can't find string in memory

    I am working on a project,and can't figure out why the segment and offset does not point to the 123456789 string in memory ?
    If I use an array I can see the number string in memory, but
    not when I use the a pointer and malloc ???


    #include <stdio.h>
    #include <dos.h>

    main()
    {
    char far *buffer;
    buffer = (char *) farmalloc(15);
    buffer = "\n12345678901234567890\0";

    printf("\n DS: %x ES %x\n", _DS,_ES);
    printf("\n buffer: %x\n", &buffer);
    printf("\n far off buffer=%x far seg buffer=%x\n", FP_OFF(buffer), FP_SEG(buffer));
    puts(buffer);
    exit(0);
    }

  2. #2
    Registered User
    Join Date
    Sep 2001
    Location
    Australia
    Posts
    212
    im not familar with
    buffer = (char *) farmalloc(15);
    I would use malloc, Im not exactly sure at what your trying to do, I just had a quick look and fixed a few things the compiler didn't like and got the output down below.

    Code:
    #include <stdio.h>
    #include <stdlib.h>
    
    
    main()
    {
    char far, *buffer;
    buffer = (char *) malloc(sizeof(char));
    buffer = "\n12345678901234567890\0";
    
    printf("\n DS: %x ES %x\n", _DS,_ES);
    printf("\n buffer: %x\n", &buffer);
    printf("\n far off buffer=%x far seg buffer=%x\n", buffer, buffer);
    puts(buffer);
    getchar();
    exit(0);
    }
    ------------------------------OUTPUT-------------------------------------------

    DS: 23 ES 23

    buffer: 12ff84

    far off buffer=40b120 far seg buffer=40b120

    12345678901234567890

  3. #3
    Unregistered
    Guest
    > buffer = (char *) farmalloc(15);
    > buffer = "\n12345678901234567890\0";

    This is absolutely wrong. Here's why:

    line 1 = allocate 15 bytes for buffer. now buffer is acutally pointing at allocated space

    line 2 = make buffer point an entirely new string--a string literal--that we've just created. ...oops, what happened to the 15 bytes we allocated? buh-bye. It's lost now. This is a Bad Thing(TM).

    line 2 should read:

    strncpy( buffer, "\n1234567890" 11 );

    Additionally, using \0 in a string is another Bad Thing(TM).


    Quzah.

  4. #4
    Registered User
    Join Date
    Sep 2001
    Posts
    5
    OK, the strncpy works, but I still don't se the string in the buffer. PUTS() converts the \0 to \n.
    What I am expecting is to go into debug and dump the
    segment and offset and see my 1234567890 string there.
    When I run the program I get the following
    C:\TC>pointer

    DS: a3b ES a3b

    buffer: ffda

    far off buffer=5e6 far seg buffer=a3b

    1234567890

    C:\TC>debug
    -d a3b:ffda

    0A3B:FFD0 E6 05 E8 FF 1D 01
    0A3B:FFE0 01 00 E6 FF C6 05 EA FF-00 00 43 3A 5C 54 43 5C
    This address a3b:ffda has the offset of the buffer E6 05 > 5E6
    from above.
    I would think when I go to this address, I would see my string
    that I copied into the buffer. But, the string is not there.
    -d a3b:05e6

    0A3B:05E0 FE 05-E9 A0 01 24 C7 3C C0 74
    0A3B:05F0 36 80 3E D3 64 00 75 4A-80 3E 39 64 08 74 43 80

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,344
    > C:\TC>pointer
    > C:\TC>debug
    Erm, once your program exits, all bets are off as to whats in the memory it used to use.
    There's a pretty good chance that loading debug overwrote the memory previously occupied by pointer
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  6. #6
    Registered User
    Join Date
    Sep 2001
    Posts
    5
    I agree that all bets are off on what's in memory after the program ends, but I have run basically the exact same program
    using an array. Whenever, I run the array program the string is always in memory. I am running WIN95, TurboC 2.0, and I have
    two command prompt windows open, one with debug, the other to run the pointer program. I don't think the memory is being over written. I even tried the program with a getch(),
    at the end, just to pause the program while I dumped the memory.

  7. #7
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,344
    > but I have run basically the exact same program
    using an array.
    Different memory - different outcome. You can't extrapolate from one set of results to the other.

    > Whenever, I run the array program the string is always in memory
    Just as the system is not obliged to preserve all the memory for you to look at, it's also not obliged to destroy it all either (some operating systems do this).

    > I am running WIN95, TurboC 2.0,
    As far as I know, each DOS box is a separate virtual machine, using different areas of virtual memory, so it's even less comparable than if you were trying this all in the same DOS box. That's the whole point, so that one small error in one program can't bring the whole machine down (although it seems like it can at times).

    What are you trying to write - a password sniffer, looking for strings which might have been left behind?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  8. #8
    Registered User
    Join Date
    Sep 2001
    Posts
    5
    Nothing so exotic as a password sniffer just a simple int25
    disk read, the code I was using passed the disk read packet as a structure. I can't seem to get the structure right. If I use:

    struct parm_block {
    unsigned long start_sector;
    unsigned num_of_sectors;
    char far *buffer;
    } p_block;

    I can get the Segment with FP_SEG(buffer), but the Offset comes up 0 with FP_OFF(buffer).

    --------D-25----CXFFFF-----------------------
    INT 25 - DOS 3.31+ - ABSOLUTE DISK READ (32M-2047M hard-disk partition)
    CX = FFFFh
    AL = drive number (0=A, 1=B, etc)
    DS:BX -> disk read packet (see #02548)
    Return: CF clear if successful

    Format of disk read packet:
    Offset Size Description
    00h DWORD sector number
    04h WORD number of sectors to read
    06h DWORD transfer address

  9. #9
    Registered User
    Join Date
    Sep 2001
    Posts
    5
    I meant Segment FP_SEG(p_block.buffer),
    Offset FP_OFF(p_block.buffer).

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. String Class
    By BKurosawa in forum C++ Programming
    Replies: 117
    Last Post: 08-09-2007, 01:02 AM
  2. Replies: 4
    Last Post: 03-03-2006, 01:11 AM
  3. Classes inheretance problem...
    By NANO in forum C++ Programming
    Replies: 12
    Last Post: 12-09-2002, 02:23 PM
  4. Is it necessary to write a specific memory manager ?
    By Morglum in forum Game Programming
    Replies: 18
    Last Post: 07-01-2002, 01:41 PM
  5. Warnings, warnings, warnings?
    By spentdome in forum C Programming
    Replies: 25
    Last Post: 05-27-2002, 06:49 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21