**Argv - where?

This is a discussion on **Argv - where? within the C++ Programming forums, part of the General Programming Boards category; argv is on main's stack right? so where is argv[0][0]?...

  1. #1
    Registered User
    Join Date
    Sep 2004
    Posts
    719

    **Argv - where?

    argv is on main's stack right? so where is argv[0][0]?
    i seem to have GCC 3.3.4
    But how do i start it?
    I dont have a menu for it or anything.

  2. #2
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,673
    > so where is argv[0][0]?
    Probably in allocated memory (via malloc), since it has no way of knowing how many command line parameters there will be, nor the length of each one.

  3. #3
    Registered User
    Join Date
    Sep 2004
    Posts
    719
    maybe you misunderstood where i was getting at with my question, or i misunderstood your answer...i'll rephrase

    'who' allocated the memory for the argument list? to me it seems like the arguments are not local to "this" program...
    i seem to have GCC 3.3.4
    But how do i start it?
    I dont have a menu for it or anything.

  4. #4
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    >> 'who' allocated the memory for the argument list?

    the system your program is running under.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  5. #5
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,673
    Between the OS and your program which begins at main(), there is a bit of software which takes whatever the OS provides and produces a consistent list of arguments which can be passed to main().

    This is called the "C runtime". You typically see an object file "crt.o" being linked with your code if you enable verbose mode when you compile a program.

    This is one of the many files which get linked into a program on my system.
    Code:
    $ nm /usr/lib/gcc-lib/i386-redhat-linux/3.2/../../../crt1.o
    00000000 D __data_start
    00000000 W data_start
             U _fini
    00000000 R _fp_hw
             U _init
    00000004 R _IO_stdin_used
             U __libc_start_main
             U main
    00000000 T _start
    _start is the real start of your program, and is the address the program loader jumps to when your program first lands in memory.
    __libc_start_main is an external symbol which is probably resolved by the libc standard library. I imagine it does startup things like initialising the seed for rand() say, and creating stdin, stdout, stderr.
    main is of course provided by you.

    So at some point, this code ends up doing (void main'ers - take note)
    Code:
    int result = main ( argc, argv );
    After your program has done what it needs to, the "CRT" tidies up and gets "result" back to the operating system.

  6. #6
    Registered User
    Join Date
    Sep 2004
    Posts
    719
    that makes a bit more sense now. thank you.

    straying from the topic a bit:
    solely for the sake of understanding, would
    int main(){return 0;} be the same as
    void main() { __asm mov eax, 0 }
    (given there is an eax register and pretending "mov eax, (constant) 0" is legal)
    i seem to have GCC 3.3.4
    But how do i start it?
    I dont have a menu for it or anything.

  7. #7
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,673
    Nobody said my processor was an X86

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    On an x86, with a compiler that doesn't, I don't know, zero out eax on a return from a void function, and the compiler further accepting the (by the standard forbidden) void return type on main, yes, that would be possible.

    But what is the point???
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  9. #9
    Magically delicious LuckY's Avatar
    Join Date
    Oct 2001
    Posts
    856
    On an x86 machine no special memory is allocated for command line arguments. There is a special "block" of data immediately before the segment where your programs data begins in memory called the PSP (Program Segment Prefix). This block is populated with numerous data, the last of which is called the command tail. This command tail is where arguments to a program are placed when it is executed.

  10. #10
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    >> solely for the sake of understanding, would

    it depends on your compiler, of course. mine produces:

    Code:
    push ebp
    mov ebp, esp
    xor eax, eax 
    pop ebp
    ret
    the output is the same whether I use int main() and return a value or void main() and return nothing, thus the latter is implicitly converted to the former (in accordance with the standard).
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    (in accordance with the standard)
    Where does the standard say that void main is acceptable, much less that it gets converted to an int main that always returns 0?
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #12
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    I didn't articulate my argument very well, did I?

    >> void main() { __asm mov eax, 0 }

    my point was that main() *must* return an int - and does so even if you try to declare it as void.
    Code:
    #include <cmath>
    #include <complex>
    bool euler_flip(bool value)
    {
        return std::pow
        (
            std::complex<float>(std::exp(1.0)), 
            std::complex<float>(0, 1) 
            * std::complex<float>(std::atan(1.0)
            *(1 << (value + 2)))
        ).real() < 0;
    }

  13. #13
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Oh, ok, got it.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #14
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,673
    > in memory called the PSP (Program Segment Prefix).
    That is only true of DOS .COM files.
    Things are very different in win32 executables - for example, you aren't limited to the piffling 128 bytes of command line arguments.

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    And it might yet again be different in ELF executables and a.out executables.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

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