Memory allocation problem with Gawk 3.1.2

Brink019 at gmx.net Brink019 at gmx.net
Fri Jun 13 06:36:54 PDT 2003


> [13.06.2003] Matthew Burgess <-- :
> > pchllck at nexgo.de (Erika Pacholleck) wrote:
> > > 
> > > First I am not sure whether the # in front is correct, but as this
> > > appears also earlier in the file and is not part of the patch, I
> > > guess it might be ok.
> > 
> > The # is a preprocessor directive.  i.e. before compilation then the
> > preprocessor acts on the file to slightly alter the code.  The easiest
> > example to see this working is the #include <someheaderfile.h>
> > instructions.  When the preprocessor sees this it basically inserts all
> > of the contents of <someheaderfile.h> into the source file where the
> > #include statement is.
> > 
> > Hope this helps clarify things a bit.
> 
> Oh yes, it indead does, thanks a lot Matthew.
> I have seen all these #include and #if(n)def ones and they were clear.
> After your explanation it is quite clear. Learned another "quicky on
> the way". :)
> 
> I usually read the patches and try to understand what's going on there
> and for something looking a bit strange to my no-programmer-eye I'd
> rather mention my doubts than blindly trust and spread "it will do the
> right thing" if I did not yet test it.
> 

just a hint of mine: i use to take a look at the preprocessor output. ->
that is the ("real") code, which is going to be assembled.
if you do: "gcc ...... somefile.c" then the preproc. output be "cpp ......
somefile.c > cppoutput.c"
"......." means any gcc-directives, flags, ...
"somefile.c" means the source-code
"cppoutput.c" means the output from preprocessor

Brink ;)

-- 
+++ GMX - Mail, Messaging & more  http://www.gmx.net +++
Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list