Can u tell me the explanation reg this problem

[Sree]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?
main(int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++)
printf("%s",argv);
}


Explain a lil bit abt these command line arguments and how they are
actually read


What would be the output of the following program?
main()
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3));
}


Plzz also explain how???




Can u suggest any good books which i can get online for referring such
questions

 

[Andrew Poelstra]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?

I imagine that the answer would be right in front of you. Unless you
are unclear on the concept of 'output'.

main(int argc, char *argv[])

int main (int argc, char *argv)

{
int i;
for(i=0;i<argc;i++)
printf("%s",argv); return 0;
}

Explain a lil bit abt these command line arguments and how they are
actually read

'lil' and 'abt' are not words.

What would be the output of the following program?

Try it and see.

main() int main (void)
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3)); return 0;
}

near, far, and huge aren't C keywords. You should get syntax errors.

Plzz also explain how???

Can u suggest any good books which i can get online for referring such
questions

'Plzz', 'u', and lowercase 'i' are not words. You also used too many
question marks. One is enough.

 

[Eric Sosman]

Sree wrote On 06/05/06 13:43,:

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?
main(int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++)
printf("%s",argv);
}

On some systems, the output would be

myprog123

However, there are some nasty little errors in the program
that might cause other things to happen:

- It calls printf() without a function prototype visible.
Add `#include <stdio.h>' at the beginning.

- It does not end its output with a newline character.
On some systems this will cause the interactive prompt
to appear right after the output

myprog123tardis>

On other systems, the output might not appear at all.

- It fails to return an `int' value from the main()
function to indicate whether the program succeeded
or failed. On some systems, this may produce an
output like

myprog123
%RMS-F-BADFILE, file structure is corrupt

Explain a lil bit abt these command line arguments and how they are
actually read

"How" the command-line arguments are parsed, prepared,
and handed to the program depends on the system that reads
the command line. Different systems do it differently, and
may make various modifications of their own, replacing the
characters you type with others. For example, some Unix
systems will treat `myprog ~' as if you had actually typed
`myprog /home/sree'. Details of this kind are not part of
the C language, and should be taken up on a forum devoted
to the system you are using.

Eventually the program's main() function receives some
values that are somehow derived from the command line and/or
other parts of the environment. These are represented as a
sequence of strings, and the first argc elements of the argv[]
array point to the strings' initial characters. The first
string (if there are any strings; argc can be zero) is some
kind of representation of the program name, but just what it
looks like is once again up to the host system: it might be
"myprog" or "myprog.exe" or "SYS$DISK:[HOME.SREE]MYPROG.EXE;3"
or something even less understandable. On most systems the
remaining strings will be "1", "2", and "3", although the C
language cannot guarantee exactly what happens before main()
is called. Finally, it will always be true that argv[argc]
is NULL, that is, that the last "real" string pointer is
followed by a NULL pointer.

What would be the output of the following program?
main()
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3));
}

I don't know; it isn't C.

Plzz also explain how???




Can u suggest any good books which i can get online for referring such
questions

I don't know of any (that doesn't mean none exist, just
that I don't know of them). "The C Programming Language"
(second edition) by Kernighan & Ritchie is a highly recommended
hard-copy book.

 

[Keith Thompson]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?

I imagine that the answer would be right in front of you. Unless you
are unclear on the concept of 'output'.

main(int argc, char *argv[])

int main (int argc, char *argv)

I think you mean
int main(int argc, char *argv[])
or possibly the equivalent
int main(int argc, char **argv)

 

[Andrew Poelstra]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?

I imagine that the answer would be right in front of you. Unless you
are unclear on the concept of 'output'.

main(int argc, char *argv[])

int main (int argc, char *argv)

I think you mean
int main(int argc, char *argv[])
or possibly the equivalent
int main(int argc, char **argv)

Yes, thank you. The second * was lost in my slow SSH
connection.

 

[spibou]

The first
string (if there are any strings; argc can be zero) is some
kind of representation of the program name...

I was under the impression that the programme name will always be
passed as an argument so argc will be at least 1. Or is that just a
Unix
thing ?

 

[Ico]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?
main(int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++)
printf("%s",argv);
}


Explain a lil bit abt these command line arguments and how they are
actually read


What would be the output of the following program?
main()
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3));
}


Plzz also explain how???




Can u suggest any good books which i can get online for referring such
questions

K&R would give you all the answers you need. Another good investement
would be a book about the English language. You are used to fact that
your compiler complains if you use wrong syntax or wrong identifiers in
your program code, so you take care to write proper C. Is it that much
work to do a little bit of work to write proper English, without all the
abbreviations like u, plzzz, abt and lil ? These make you look childish,
and will not help you getting useful answers to your questions.

 

[Eric Sosman]

Eric Sosman wrote:




I was under the impression that the programme name will always be
passed as an argument so argc will be at least 1. Or is that just a
Unix
thing ?

In section 5.1.2.2.1 paragraph 2, the C Standard says
"the value of argc shall be nonnegative" (it doesn't say
"positive"), and it twice uses the phrase "if the value of
argc is greater than zero" in descriptions of the argv[]
values. The wording seems to imply the possibility that
argc might be zero in some environment that doesn't support
notions like "command line" or "program name."

The same paragraph says that if argv[0] is non-NULL it
shall point to a string that "represents the program name,"
but does not describe the form of the representation. It
also explicitly recognizes that no name might be available
even if other command-line arguments are present; in this
case, argv[0] points to an empty string "".

Other Standards that build atop the C Standard may
impose additional requirements, but I don't think I've run
across any that guarantee argv[0] will be "the" program
name. In the POSIX world, for example, argv[0] is whatever
was provided to the exec*() system call that launched the
program in the first place; this is only "conventionally"
the program name, and the convention is not enforced. (In
a few places, it is deliberately violated.)

Even when argv[0] is a program name, it doesn't follow
that you can use it to launch another copy of the program
via the system() function (or a system-specific facility).
The program "name" might turn out to be a shell alias that
isn't exported to sub-shells -- more generally, the "name"
may be "the" name only in a context that isn't available
inside the program.

The value of argv[0] is usually something that's useful
for "decorating" errors and status messages, but not "solid"
enough to rest your program's operation upon. A widely-used
hack installs a single executable file with several names,
where the program inspects argv[0] to decide how it should
behave; this sort of thing may have been justifiable in the
days of small disks and static libraries, but is hard to
defend today. Some programmers use argv[0] to find "the"
program's installation directory where configuration files
and suchlike are stored; this isn't terribly reliable (and
can be downright UNreliable on multi-user systems).

 

[CBFalconer]

If the program (myprog) is run from the command line as myprog 1 2 3 ,
What would be the output?
main(int argc, char *argv[])
{
int i;
for(i=0;i<argc;i++)
printf("%s",argv);
}

Explain a lil bit abt these command line arguments and how they are
actually read

lil is usually a girls nickname. Abt is meaningless to me.

What would be the output of the following program?
main()
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3));
}

It wouldn't compile on a C compiler. It would emit something like
"syntax error". Even the printf, taken in isolation, would cause
undefined behaviour.

Plzz also explain how???

Can u suggest any good books which i can get online for referring such
questions

Who is 'plzz'? Who is 'u'?

--
"Our enemies are innovative and resourceful, and so are we.
They never stop thinking about new ways to harm our country
and our people, and neither do we." -- G. W. Bush.
"The people can always be brought to the bidding of the
leaders. All you have to do is tell them they are being
attacked and denounce the pacifists for lack of patriotism
and exposing the country to danger. It works the same way
in any country." --Hermann Goering.

 

[Keith Thompson]

main()
{
char near * near *ptr1;
char near * far *ptr2;
char near * huge *ptr3;
printf("%d %d %d",sizeof(ptr1),sizeof(ptr2),sizeof(ptr3));
} [...]
Can u suggest any good books which i can get online for referring such
questions

K&R would give you all the answers you need.

[...]

K&R won't tell you anything about "near" and "far" pointers.

But that probably *is* all you need to know about "near" and "far"
pointers (unless you're actually programming for any of the few
remaining systems that still use them). They've never been standard,
and they're largely obsolete.

 

[spibou]

In the POSIX world, for example, argv[0] is whatever
was provided to the exec*() system call that launched the
program in the first place; this is only "conventionally"
the program name, and the convention is not enforced. (In
a few places, it is deliberately violated.)

Even when argv[0] is a program name, it doesn't follow
that you can use it to launch another copy of the program
via the system() function (or a system-specific facility).
The program "name" might turn out to be a shell alias that
isn't exported to sub-shells --

If argv[0] is what was provided to exec*() then it cannot be a shell
alias.
But I see your point about the correspondence between name and
executable
file being influenced by the environment.

 

[Thad Smith]

'Plzz', 'u', and lowercase 'i' are not words. You also used too many
question marks. One is enough.

Actually one is too many since there was no preceding question.

 

[Chris Torek]

In the POSIX world, for example, argv[0] is whatever
was provided to the exec*() system call ... [snippage]
The program "name" might turn out to be a shell alias that
isn't exported to sub-shells --

If argv[0] is what was provided to exec*() then it cannot be a shell
alias.

Objection, assumes facts not in evidence.

In fact -- although this is off-topic -- the execl() or (more
typical for shells) execv() call takes two separate argv[0]-like
arguments: one is the pathname of the file to exec (subject to the
usual kernel pathname interpretation), and the other is the string
to supply to the program (copied unchanged to the new memory image
resulting from loading the named file). A shell *could* choose to
supply the alias, without exporting it.

For instance:

execl("/bin/echo", "alias", "argv1", "argv2", (char *)NULL);
... if we reach this point, do something about the failure to exec ...

would run /bin/echo with argv[0] set to "alias", not "echo".
(Since echo ignores its argv[0], this will print "argv1 argv2\n"
as usual.)

But I see your point about the correspondence between name and
executable file being influenced by the environment.

In fact, one finds that different shells sometimes *do* do different
things with argv[0]. None happen to provide a shell-specific alias
(as far as I know) but "*can* not" (emphasis mine) is too strong
a claim.

 

[Wolfgang Riedel]

lil is usually a girls nickname. Abt is meaningless to me.

Abt: german word for abbot.
That one was easy.

Wolfgang