From: Maxwell Lol on
frank <frank(a)example.invalid> writes:

>>> gcc -dM -E - < /dev/null
> It certainly does. Can we talk about the hyphen in the middle that
> doesn't seem to do anything?
> --



gcc normally taks a source code file, like prog.c, as an argument.

The use of a hyphen where a program normally takes a filename as an argument,
often means use STDIN instead of a filename.

And since STDIN is now /dev/null (or the empty file), gcc reads no
source code at all.

So then it does as the rest of the arguments suggest - print out
preprocessor flags that arer ALWAYS defined.

In this case, it's a good idea to execute the command and see what happens.


In this case, it prints out a bunch of preprocessor variables that are
always defined based on your version of gcc, and the system
architecture.


For example

#define linux 1
#define __WCHAR_TYPE__ int
#define __SIZEOF_FLOAT__ 4
#define __INT_MAX__ 2147483647
#define __amd64__ 1

Which says I'm on a linux system, AMD CPU, wide characters are type
"int", maximum size of an integer, etc.

Based on these values, a C program can better define data structures,
and macros.
From: Stephane CHAZELAS on
2010-01-24, 22:26(-07), frank:
> Hello newsgroup,
>
> I'm relatively new to linux and have yet to put it through its paces
> properly, but I keep pecking away at it. I'm looking for a precise
> description of what's going on here:
>
> gcc -dM -E - < /dev/null
>
> Let me bust up the question a bit:
> gcc : invokes compiler
> -dM : show all the macros from preprocessing
> -E : stop after preprocessor
> - : no idea what a hyphen is doing here
> < : redirecting
> /dev/null/ : the bitbucket why would any macro be defined here?
[...]

As already been said, "-" is a way to say "use stdin" and <
/dev/null makes stdin /dev/null.

Now one may wonder why we didn't use

gcc -dM -E /dev/null

The thing is, with that syntax, gcc doesn't know which language
the file is written in as it has no extension. "-" has no
extension either but for some reason, gcc seems to assume "c".

So you need:

gcc -dM -E -x c /dev/null

I would tend to prefer that latter syntax, as you make it clear
which language you want to know pre-defined macros for. Rather
than relying on the undocumented (well, at least I couldn't find
the documentation) fact that C is assumed for "-".

--
St�phane
From: David W. Hodgins on
On Mon, 25 Jan 2010 03:13:52 -0500, frank <frank(a)example.invalid> wrote:

> It certainly does. Can we talk about the hyphen in the middle that
> doesn't seem to do anything?

For many programs, using a hyphen where a filename is expected tells
the program to use stdin or stdout (depending on whether the filename
is an input, or output file), rather then using a disk file.

The redirect of stdin to come from /dev/null, has the same affect
that pressing the enter key, to provide an empty input, would
have.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
From: Ben Bacarisse on
"David W. Hodgins" <dwhodgins(a)nomail.afraid.org> writes:

> On Mon, 25 Jan 2010 03:13:52 -0500, frank <frank(a)example.invalid> wrote:
>
>> It certainly does. Can we talk about the hyphen in the middle that
>> doesn't seem to do anything?
>
> For many programs, using a hyphen where a filename is expected tells
> the program to use stdin or stdout (depending on whether the filename
> is an input, or output file), rather then using a disk file.
>
> The redirect of stdin to come from /dev/null, has the same affect
> that pressing the enter key, to provide an empty input, would
> have.

More like the effect of typing ^D (Control-D) -- if the tty interprets
^D as an EOF request, that is.

--
Ben.
From: Keith Thompson on
frank <frank(a)example.invalid> writes:
> Seebs wrote:
[...]
>> However, there are *predefined* macros that gcc defines, before it
>> encounters anything, so invoking gcc this way on an empty file (/dev/null
>> is empty on read) produces a list of precisely those values that were
>> defined before it had read any input.
>
> Ok, cool. Is it for ordinary mortals to know the files that gcc uses
> to obtain these macros or is it underneath the hood? I've been
> reading gccint today, and the information I'm asking for is probably
> in there, but I've got a lot of reading to do there if I'm to get
> something useful out of it.

gcc is free software, so "ordinary mortals" are free to look at
anything they like. But this particular detail is probably "under
the hood" in the sense that you don't need to now about it to do
useful work, and if you do happen to know about it there's probably
no real benefit in depending on the information.

In any case, it sounds like you're assuming that gcc obtains the
definitions for these macros by reading some hidden "whatever.h"
file containing a bunch of #include directives. As far as I know,
that's not the case; I think gcc does it internally.

--
Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"