dev-cpp-users

[Dev-C++] BC++, gcc and Win98SE shell

[<gi...@li...>]

Hello list,

here is one, funny, thing of which I have no explanation:

consider the following program:

/* echo.c */
#include <stdio.h>

int
main(int argc, char **argv)
{
   while (--argc)
     printf("%s ", *++argv);

   return 0;
}

I compiled it using:
GNU gcc 2.95 shipped with Dev-C++ (gcc -o echo_g.exe echo.c)
BC++ 5.5 of thge "Borland free command line tools" (bcc32 -eecho_b.exe 
echo.c).

Then I've "touched" the files "foo.c" and "bar.c" and tried the following:

   command            output
echo_g *.c           bar.c foo.c
echo_b *.c           *.c

All of this on Win98SE.
Is there somebody that can tell what is going on?
Is this bug(?) common to the shell of other Windows systems too?

TIA

--
gisan
gi...@li...

RE: [Dev-C++] BC++, gcc and Win98SE shell

[Ioannis V. <no...@ya...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of gi...@li...
> Sent: Sunday, February 24, 2002 5:03 PM
> To: dev...@so...
> Subject: [Dev-C++] BC++, gcc and Win98SE shell
> 
> 
> Hello list,
> 
> here is one, funny, thing of which I have no explanation:
> 
> consider the following program:
> 
> /* echo.c */
> #include <stdio.h>
> 
> int
> main(int argc, char **argv)
> {
>    while (--argc)

 This decreases the number reported, which has no effect.


>      printf("%s ", *++argv);

Here you printf *after* you increment, that is you lose the first
string.


Now something delicate. argc is *not* guaranteed to be one if you do not
pass any argument. It is guaranteed that if you pass an argument then it
will be non zero and argv[0] will be the name of the program itself. In
few words, if you do not pass any name it is not guaranteed that argv[0]
contains the name of the program. As the C++ standard says:


"An implementation shall not predefine the main function. This function
shall not be overloaded. It shall
have a return type of type int, but otherwise its type is
implementationdefined.
All implementations
shall allow both of the following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }
In the latter form argc shall be the number of arguments passed to the
program from the environment in
which the program is run. If argc is nonzero these arguments shall be
supplied in argv[0] through
argv[argc1]
as pointers to the initial characters of nullterminated
multibyte strings (NTMBSs)
(17.3.2.1.3.2) and argv[0] shall be the pointer to the initial character
of a NTMBS that represents the
name used to invoke the program or "". The value of argc shall be
nonnegative. The value of
argv[argc] shall be 0. [Note: it is recommended that any further
(optional) parameters be added after
argv. ]".



This is exactly the same for ANSI C89 and C99 too.



> 
>    return 0;
> }
> 
> I compiled it using:
> GNU gcc 2.95 shipped with Dev-C++ (gcc -o echo_g.exe echo.c)
> BC++ 5.5 of thge "Borland free command line tools" (bcc32 -eecho_b.exe
> echo.c).
> 
> Then I've "touched" the files "foo.c" and "bar.c" and tried 
> the following:
> 
>    command            output
> echo_g *.c           bar.c foo.c
> echo_b *.c           *.c
> 
> All of this on Win98SE.
> Is there somebody that can tell what is going on?
> Is this bug(?) common to the shell of other Windows systems too?

I do not understand what you did.



Ioannis
 
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys

RE: [Dev-C++] BC++, gcc and Win98SE shell

[<gi...@li...>]

Sorry for my previous post, it was not very clear.

Let me try again.

The test program is, this time, a little different:

/* echo.c */
#include <stdio.h>
int main(int argc, char *argv[])
{
    while (--argc > 0)
       printf("%s%s", *++argv, (argc > 1) ? " ": "");
    printf("\n");
    return 0;
}

IMHO the above is more or less equivalent to the program I posted before 
but I changed in the hope that Ioannis won't yell at me this time :-)

Anyway the program is not the point, it is just a mean to show that:
when I use a program compiled by gcc, it seems that the shell expands 
wildcards before invoking the program (as it should always be), instead 
when I compile the same program using BC++, the shell does not expand the 
wildcards.

To prove it, what I did was:
1. create a directory named c:\temp
2. used the program "touch" (a Borland tool) to create: c:\temp\foo.c and 
c:\temp\bar.c
3. switched to the directory c:\temp
4. issued the command: echo_g *.c

The ouput of the command was:

bar.c foo.c

This means that the shell expanded "*.c" into "bar.c foo.c", the two 
arguments were then echoed by the program "echo_g" (where the "_g" means 
compiled using gcc).

Instead if I use the version of echo compiled by BC++ (named "echo_b.exe"), 
that is, when step #4 becomes:

4. issued the command: echo_b *.c

The output is:

*.c

This means that the shell did not expand "*.c". Or, if you prefer, I have 
the same  ANSI C89 program give two different outputs, according to which 
compiler was used to build the executable. I have no explanation for this, 
other than there is some bug in the shell.

My questions are
1. Why is the Windows shell (or command.com, if you prefer) acting 
differently?
2. Is this happening on my Win98SE or is it happening on other versions of 
Windows too?


At 18:45 24/02/02 +0200, Ioannis Vranos wrote:
> > -----Original Message-----
> > From: dev...@li...
> > [mailto:dev...@li...] On Behalf
> > Of gi...@li...
> > Sent: Sunday, February 24, 2002 5:03 PM
> > To: dev...@so...
> > Subject: [Dev-C++] BC++, gcc and Win98SE shell
> >
> >
> > Hello list,
> >
> > here is one, funny, thing of which I have no explanation:
> >
> > consider the following program:
> >
> > /* echo.c */
> > #include <stdio.h>
> >
> > int
> > main(int argc, char **argv)
> > {
> >    while (--argc)
>
>  This decreases the number reported, which has no effect.
>
>
> >      printf("%s ", *++argv);
>
>Here you printf *after* you increment, that is you lose the first
>string.
>
>
>Now something delicate. argc is *not* guaranteed to be one if you do not
>pass any argument. It is guaranteed that if you pass an argument then it
>will be non zero and argv[0] will be the name of the program itself. In
>few words, if you do not pass any name it is not guaranteed that argv[0]
>contains the name of the program. As the C++ standard says:
>
>
>"An implementation shall not predefine the main function. This function
>shall not be overloaded. It shall
>have a return type of type int, but otherwise its type is
>implementationdefined.
>All implementations
>shall allow both of the following definitions of main:
>int main() { /* ... */ }
>and
>int main(int argc, char* argv[]) { /* ... */ }
>In the latter form argc shall be the number of arguments passed to the
>program from the environment in
>which the program is run. If argc is nonzero these arguments shall be
>supplied in argv[0] through
>argv[argc1]
>as pointers to the initial characters of nullterminated
>multibyte strings (NTMBSs)
>(17.3.2.1.3.2) and argv[0] shall be the pointer to the initial character
>of a NTMBS that represents the
>name used to invoke the program or "". The value of argc shall be
>nonnegative. The value of
>argv[argc] shall be 0. [Note: it is recommended that any further
>(optional) parameters be added after
>argv. ]".
>
>
>
>This is exactly the same for ANSI C89 and C99 too.
>
>
>
> >
> >    return 0;
> > }
> >
> > I compiled it using:
> > GNU gcc 2.95 shipped with Dev-C++ (gcc -o echo_g.exe echo.c)
> > BC++ 5.5 of thge "Borland free command line tools" (bcc32 -eecho_b.exe
> > echo.c).
> >
> > Then I've "touched" the files "foo.c" and "bar.c" and tried
> > the following:
> >
> >    command            output
> > echo_g *.c           bar.c foo.c
> > echo_b *.c           *.c
> >
> > All of this on Win98SE.
> > Is there somebody that can tell what is going on?
> > Is this bug(?) common to the shell of other Windows systems too?
>
>I do not understand what you did.
>
>
>
>Ioannis
>
>* Ioannis Vranos
>* Programming pages: http://www.noicys.d2g.com
>* Alternative URL: http://run.to/noicys
>

--
gisan
gi...@li...

RE: [Dev-C++] BC++, gcc and Win98SE shell

[Ioannis V. <no...@ya...>]

> -----Original Message-----
> From: dev...@li... 
> [mailto:dev...@li...] On Behalf 
> Of gi...@li...
> Sent: Monday, February 25, 2002 12:38 AM
> To: dev...@so...
> Subject: RE: [Dev-C++] BC++, gcc and Win98SE shell
> 
> 
> Sorry for my previous post, it was not very clear.
> 
> Let me try again.
> 
> The test program is, this time, a little different:
> 
> /* echo.c */
> #include <stdio.h>
> int main(int argc, char *argv[])
> {
>     while (--argc > 0)
>        printf("%s%s", *++argv, (argc > 1) ? " ": "");
>     printf("\n");
>     return 0;
> }
> 
> IMHO the above is more or less equivalent to the program I 
> posted before 
> but I changed in the hope that Ioannis won't yell at me this time :-)
> 
> Anyway the program is not the point, it is just a mean to 
> show that: when I use a program compiled by gcc, it seems 
> that the shell expands 
> wildcards before invoking the program (as it should always 
> be), instead 
> when I compile the same program using BC++, the shell does 
> not expand the 
> wildcards.
> 
> To prove it, what I did was:
> 1. create a directory named c:\temp
> 2. used the program "touch" (a Borland tool) to create: 
> c:\temp\foo.c and 
> c:\temp\bar.c
> 3. switched to the directory c:\temp
> 4. issued the command: echo_g *.c
> 
> The ouput of the command was:
> 
> bar.c foo.c
> 
> This means that the shell expanded "*.c" into "bar.c foo.c", the two 
> arguments were then echoed by the program "echo_g" (where the 
> "_g" means 
> compiled using gcc).
> 
> Instead if I use the version of echo compiled by BC++ (named 
> "echo_b.exe"), 
> that is, when step #4 becomes:
> 
> 4. issued the command: echo_b *.c
> 
> The output is:
> 
> *.c
> 
> This means that the shell did not expand "*.c". Or, if you 
> prefer, I have 
> the same  ANSI C89 program give two different outputs, 
> according to which 
> compiler was used to build the executable. I have no 
> explanation for this, 
> other than there is some bug in the shell.


This is compiler bug. **argv represents the passed arguments as a string
and i think that the behavior of BCC is the correct  (expected) here.
The standard requires the exact arguments to be represented as C-strings
in *argv[] and then if the programmer wishes he can execute system
commands like system("dir *.c");

The C  & C++ standards write:

"int main(int argc, char* argv[]) { /* ... */ }

In the latter form argc shall be the number of arguments passed to the
program from the environment in
which the program is run."



> 
> My questions are
> 1. Why is the Windows shell (or command.com, if you prefer) acting 
> differently?


I do not think it is the environment. I rather think is the use of the
environment from the produced exe (produced by the compiler).


> 2. Is this happening on my Win98SE or is it happening on 
> other versions of 
> Windows too?


It is happening in my win2k too and i use the cmd.exe .



Ioannis
 
* Ioannis Vranos
* Programming pages: http://www.noicys.d2g.com
* Alternative URL: http://run.to/noicys

Re: [Dev-C++] BC++, gcc and Win98SE shell

[Jason H. <jas...@bt...>]

One possible reason for this behaviour may be due to differences between the
Windows and Unix (i.e. Linux) environments. I'm uncertain of the actual
behaviours but your program implies that the shell of Windows doesn't have
direct support for wildcards, and that wildcard operation has to be built
into the programs themselves. In Unix on the other hand it may be that
wildcards are automatically expanded to their equivalents in the file
system. Because GCC is a port of a Unix compiler then the operation may have
been passed through to the windows version for compatibility, whereas BC++
is developed for windows directly.

From the C++ specification (from Ioannis message) there is no mention of any
default handling of wildcards, and it would be dependent upon the OS itself.

Another explanation may be a compiler feature that is turned on in GCC,
where it may handle the chore of dealing with wildcards for you. If true
there may be a way of disabling the feature. BC++ may not have this feature
or it may be turned off by default. I find this explanation unlikely though.
Try checking the documentations for both compilers.

Jason.

----- Original Message -----
From: <gi...@li...>
To: <dev...@so...>
Sent: Sunday, February 24, 2002 10:37 PM
Subject: RE: [Dev-C++] BC++, gcc and Win98SE shell


> Sorry for my previous post, it was not very clear.
>
> Let me try again.
>
> The test program is, this time, a little different:
>
> /* echo.c */
> #include <stdio.h>
> int main(int argc, char *argv[])
> {
>     while (--argc > 0)
>        printf("%s%s", *++argv, (argc > 1) ? " ": "");
>     printf("\n");
>     return 0;
> }
>
> IMHO the above is more or less equivalent to the program I posted before
> but I changed in the hope that Ioannis won't yell at me this time :-)
>
> Anyway the program is not the point, it is just a mean to show that:
> when I use a program compiled by gcc, it seems that the shell expands
> wildcards before invoking the program (as it should always be), instead
> when I compile the same program using BC++, the shell does not expand the
> wildcards.
>
> To prove it, what I did was:
> 1. create a directory named c:\temp
> 2. used the program "touch" (a Borland tool) to create: c:\temp\foo.c and
> c:\temp\bar.c
> 3. switched to the directory c:\temp
> 4. issued the command: echo_g *.c
>
> The ouput of the command was:
>
> bar.c foo.c
>
> This means that the shell expanded "*.c" into "bar.c foo.c", the two
> arguments were then echoed by the program "echo_g" (where the "_g" means
> compiled using gcc).
>
> Instead if I use the version of echo compiled by BC++ (named
"echo_b.exe"),
> that is, when step #4 becomes:
>
> 4. issued the command: echo_b *.c
>
> The output is:
>
> *.c
>
> This means that the shell did not expand "*.c". Or, if you prefer, I have
> the same  ANSI C89 program give two different outputs, according to which
> compiler was used to build the executable. I have no explanation for this,
> other than there is some bug in the shell.
>
> My questions are
> 1. Why is the Windows shell (or command.com, if you prefer) acting
> differently?
> 2. Is this happening on my Win98SE or is it happening on other versions of
> Windows too?
>
>
> At 18:45 24/02/02 +0200, Ioannis Vranos wrote:
> > > -----Original Message-----
> > > From: dev...@li...
> > > [mailto:dev...@li...] On Behalf
> > > Of gi...@li...
> > > Sent: Sunday, February 24, 2002 5:03 PM
> > > To: dev...@so...
> > > Subject: [Dev-C++] BC++, gcc and Win98SE shell
> > >
> > >
> > > Hello list,
> > >
> > > here is one, funny, thing of which I have no explanation:
> > >
> > > consider the following program:
> > >
> > > /* echo.c */
> > > #include <stdio.h>
> > >
> > > int
> > > main(int argc, char **argv)
> > > {
> > >    while (--argc)
> >
> >  This decreases the number reported, which has no effect.
> >
> >
> > >      printf("%s ", *++argv);
> >
> >Here you printf *after* you increment, that is you lose the first
> >string.
> >
> >
> >Now something delicate. argc is *not* guaranteed to be one if you do not
> >pass any argument. It is guaranteed that if you pass an argument then it
> >will be non zero and argv[0] will be the name of the program itself. In
> >few words, if you do not pass any name it is not guaranteed that argv[0]
> >contains the name of the program. As the C++ standard says:
> >
> >
> >"An implementation shall not predefine the main function. This function
> >shall not be overloaded. It shall
> >have a return type of type int, but otherwise its type is
> >implementationdefined.
> >All implementations
> >shall allow both of the following definitions of main:
> >int main() { /* ... */ }
> >and
> >int main(int argc, char* argv[]) { /* ... */ }
> >In the latter form argc shall be the number of arguments passed to the
> >program from the environment in
> >which the program is run. If argc is nonzero these arguments shall be
> >supplied in argv[0] through
> >argv[argc1]
> >as pointers to the initial characters of nullterminated
> >multibyte strings (NTMBSs)
> >(17.3.2.1.3.2) and argv[0] shall be the pointer to the initial character
> >of a NTMBS that represents the
> >name used to invoke the program or "". The value of argc shall be
> >nonnegative. The value of
> >argv[argc] shall be 0. [Note: it is recommended that any further
> >(optional) parameters be added after
> >argv. ]".
> >
> >
> >
> >This is exactly the same for ANSI C89 and C99 too.
> >
> >
> >
> > >
> > >    return 0;
> > > }
> > >
> > > I compiled it using:
> > > GNU gcc 2.95 shipped with Dev-C++ (gcc -o echo_g.exe echo.c)
> > > BC++ 5.5 of thge "Borland free command line tools" (bcc32 -eecho_b.exe
> > > echo.c).
> > >
> > > Then I've "touched" the files "foo.c" and "bar.c" and tried
> > > the following:
> > >
> > >    command            output
> > > echo_g *.c           bar.c foo.c
> > > echo_b *.c           *.c
> > >
> > > All of this on Win98SE.
> > > Is there somebody that can tell what is going on?
> > > Is this bug(?) common to the shell of other Windows systems too?
> >
> >I do not understand what you did.
> >
> >
> >
> >Ioannis
> >
> >* Ioannis Vranos
> >* Programming pages: http://www.noicys.d2g.com
> >* Alternative URL: http://run.to/noicys
> >
>
> --
> gisan
> gi...@li...
>
>
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users

Re: [Dev-C++] BC++, gcc and Win98SE shell

[jansb000 <jan...@wx...>]

The usage of wildcards in unix is normally handled by the shell. Hence,
calling a program like this: "prg *.txt" is translated to "prg 1.txt 2.txt
...". In DOS there is no such default handling of wildcards. Compiler
builders must make there own solution.

DJGPP and MINGW32 (DevC++) simulate the unix method, probably to maintain
platform independency.
For BCC you can get the arguments as-is, this it what we see here, or you
can link the file "wildargs.obj" in your project. That should give you the
same results as with DJGPP or MINGW32. (I found this in my old Turbo C++ 3.0
users guide).

----- Original Message ----- >
>    command            output
> echo_g *.c           bar.c foo.c
> echo_b *.c           *.c

Re: [Dev-C++] BC++, gcc and Win98SE shell

[<gi...@li...>]

Hi,

I tried adding "wildargs.obj" and it works.

Now, I have the same output, independent of which of the two compilers I 
use to generate the executable.

Thanks.

At 17:12 25/02/02 +0100, jansb000 wrote:
>The usage of wildcards in unix ...
>...
>For BCC you can get the arguments as-is, this it what we see here, or you
>can link the file "wildargs.obj" in your project. That should give you the
>same results as with DJGPP or MINGW32. (I found this in my old Turbo C++ 3.0
>users guide).

--
gisan
gi...@li...