ANNOUNCE ggets revised
CBFalconer
the requirements on the standard library. The external action is
totally unchanged, so there is no real need for anyone to upgrade.
Available at:
<http://cbfalconer.home.att.net/download/>
--
Chuck F (cbfal...@yahoo.com) (cbfal...@maineline.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!
CBFalconer
>
> I have modified my ggets utility, to simplify the code and reduce
> the requirements on the standard library. The external action is
> totally unchanged, so there is no real need for anyone to upgrade.
> Available at:
>
> <http://cbfalconer.home.att.net/download/>
I hate to admit it, but I released something with a memory leak.
Fixed. The zip file dated 2006-06-15 has the fix, and is now the
only one found on the above link.
Frank Silvermann
> CBFalconer wrote:
>> I have modified my ggets utility, to simplify the code and reduce
>> the requirements on the standard library. The external action is
>> totally unchanged, so there is no real need for anyone to upgrade.
>> Available at:
>>
>> <http://cbfalconer.home.att.net/download/>
>
> I hate to admit it, but I released something with a memory leak.
> Fixed. The zip file dated 2006-06-15 has the fix, and is now the
> only one found on the above link.
>
one but my question goes to the header:
#ifndef ggets_h_
# define ggets_h_
# ifdef __cplusplus
extern "C" {
# endif
int fggets(char* *ln, FILE *f);
#define ggets(ln) fggets(ln, stdin)
# ifdef __cplusplus
}
# endif
#endif
/* END ggets.h */
What is happening with the ifdefs here? They would seem to be building
a statement:
extern "C" { int ... #define ...}
? frank
Michael Mair
> CBFalconer wrote:
<snip>
> my question goes to the header:
> #ifndef ggets_h_
> # define ggets_h_
>
> # ifdef __cplusplus
> extern "C" {
> # endif
>
> int fggets(char* *ln, FILE *f);
>
> #define ggets(ln) fggets(ln, stdin)
>
> # ifdef __cplusplus
> }
> # endif
> #endif
> /* END ggets.h */
> What is happening with the ifdefs here? They would seem to be building
> a statement:
> extern "C" { int ... #define ...}
Yep.
You can assume that every sufficiently new C implementation does
not #define __cplusplus [*] whereas a C++ implementation usually
does.
So the C version of the code just gives you a header with
include guards in which a prototype of fggets() and a macro
definition for ggets() are provided.
The C++ version does essentially the same but marks fggets()
as function stemming from C code (this information is
necessary for linking).
[*] C99 explicitly forbids the implementation to predefine
__cplusplus in any standard library header (6.10.8#5); even
compilers not complying to this standard usually do not
#define __cplusplus.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.
CBFalconer
> CBFalconer wrote:
>> CBFalconer wrote:
>>
>>> I have modified my ggets utility, to simplify the code and reduce
>>> the requirements on the standard library. The external action is
>>> totally unchanged, so there is no real need for anyone to upgrade.
>>> Available at:
>>>
>>> <http://cbfalconer.home.att.net/download/>
>>
>> I hate to admit it, but I released something with a memory leak.
>> Fixed. The zip file dated 2006-06-15 has the fix, and is now the
>> only one found on the above link.
>
> Did the memory leak exist five minutes ago? I think I got the
> revised one but my question goes to the header:
>From the time on your article, you got the revised. The ggets.c
source has a comment about fixing the leak, to double check.
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html
Frank Silvermann
> Frank Silvermann wrote:
>> CBFalconer wrote:
>>> CBFalconer wrote:
>>>
>>>> I have modified my ggets utility, to simplify the code and reduce
>>>> the requirements on the standard library. The external action is
>>>> totally unchanged, so there is no real need for anyone to upgrade.
>>>> Available at:
>>>>
>>>> <http://cbfalconer.home.att.net/download/>
>>> I hate to admit it, but I released something with a memory leak.
>>> Fixed. The zip file dated 2006-06-15 has the fix, and is now the
>>> only one found on the above link.
>> Did the memory leak exist five minutes ago? I think I got the
>> revised one but my question goes to the header:
>
>>From the time on your article, you got the revised. The ggets.c
> source has a comment about fixing the leak, to double check.
saying "becoming impatient while my news server pulls the moths out of
the vacuum tubes" I do have the revised version. You put:
int fggets(char* *ln, FILE *f);
#define ggets(ln) fggets(ln, stdin)
in the header in such a manner that if some condition were true, then
any 'tja' within was going to get enclosed by extern "C" { tja } . In
the implementation file you have:
#define INITSIZE 112 /* power of 2 minus 16, helps malloc */
#define DELTASIZE (INITSIZE + 16)
as the only instructions to the preprocessor, except the inclusion of
the header. When is it a good idea to have the preprocessor do the one
as opposed to the other, given that you want to write an ISO C module
that the other guys can access reliably? frank
------
Did Heathfield miss the starting gun?
CBFalconer
>
... snip ...
>
> This reply relies on what I can do off-line, which is a nice way of
> saying "becoming impatient while my news server pulls the moths out
> of the vacuum tubes" I do have the revised version. You put:
>
> int fggets(char* *ln, FILE *f);
>
> #define ggets(ln) fggets(ln, stdin)
>
> in the header in such a manner that if some condition were true,
> then any 'tja' within was going to get enclosed by extern "C" { tja }.
I have no idea what you mean by 'tja'. The wrapping in
extern "C" {
}
only occurs when used in a c++ compiler, and prevents the linkage
names being mauled. It does not happen when compiling ggets.o,
because ggets is a C module.
> In the implementation file you have:
>
> #define INITSIZE 112 /* power of 2 minus 16, helps malloc */
> #define DELTASIZE (INITSIZE + 16)
>
> as the only instructions to the preprocessor, except the inclusion of
> the header. When is it a good idea to have the preprocessor do the one
> as opposed to the other, given that you want to write an ISO C module
> that the other guys can access reliably? frank
Why would those go in the header? The headers ONLY purpose is to
export what is needed to link ggets into other modules. No other
module need know anything about those values, they are used only in
the ggets implementation. The preprocessor and the header files
have no special relationship.
--
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Frank Silvermann
> Frank Silvermann wrote:
>> This reply relies on what I can do off-line, which is a nice way of
>> saying "becoming impatient while my news server pulls the moths out
>> of the vacuum tubes" I do have the revised version. You put:
>>
>> int fggets(char* *ln, FILE *f);
>>
>> #define ggets(ln) fggets(ln, stdin)
>>
>> in the header in such a manner that if some condition were true,
>> then any 'tja' within was going to get enclosed by extern "C" { tja }.
>
> I have no idea what you mean by 'tja'. The wrapping in
> extern "C" {
> }
> only occurs when used in a c++ compiler, and prevents the linkage
> names being mauled. It does not happen when compiling ggets.o,
> because ggets is a C module.
believe that '.o' is a typo or an intermediate file during
compiling-linking.
>> In the implementation file you have:
>>
>> #define INITSIZE 112 /* power of 2 minus 16, helps malloc */
>> #define DELTASIZE (INITSIZE + 16)
>>
>> as the only instructions to the preprocessor, except the inclusion of
>> the header. When is it a good idea to have the preprocessor do the one
>> as opposed to the other, given that you want to write an ISO C module
>> that the other guys can access reliably? frank
>
> Why would those go in the header? The headers ONLY purpose is to
> export what is needed to link ggets into other modules. No other
> module need know anything about those values, they are used only in
> the ggets implementation. The preprocessor and the header files
> have no special relationship.
This last statement is a little shocking, but given the above-stated
purpose of a header and when you think about for a bit, quite true. frank
Randy Howard
(in article <4493043d$0$30716$ec3e...@news.usenetmonster.com>):
> CBFalconer wrote:
>> Frank Silvermann wrote:
>> .... snip ...
>>> This reply relies on what I can do off-line, which is a nice way of
>>> saying "becoming impatient while my news server pulls the moths out
>>> of the vacuum tubes" I do have the revised version. You put:
>>>
>>> int fggets(char* *ln, FILE *f);
>>>
>>> #define ggets(ln) fggets(ln, stdin)
>>>
>>> in the header in such a manner that if some condition were true,
>>> then any 'tja' within was going to get enclosed by extern "C" { tja }.
>>
>> I have no idea what you mean by 'tja'. The wrapping in
>> extern "C" {
>> }
>> only occurs when used in a c++ compiler, and prevents the linkage
>> names being mauled. It does not happen when compiling ggets.o,
>> because ggets is a C module.
> There exists no ggets.o file in whatever I unzipped. One is left to
> believe that '.o' is a typo or an intermediate file during
> compiling-linking.
You are new to the C language, aren't you?
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Richard Heathfield
> Frank Silvermann wrote
>> There exists no ggets.o file in whatever I unzipped. One is left to
>> believe that '.o' is a typo or an intermediate file during
>> compiling-linking.
>
> You are new to the C language, aren't you?
That's allowed. From what I've seen so far of Mr Silvermann, I have the
impression that he's fairly new to C but far from dense.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Arthur J. O'Dwyer
On Fri, 16 Jun 2006, Randy Howard wrote:
> Frank Silvermann wrote...
>> CBFalconer wrote:
>>> Frank Silvermann wrote:
>>>>
>>>> int fggets(char* *ln, FILE *f);
>>>>
>>>> #define ggets(ln) fggets(ln, stdin)
>>>>
>>>> in the header in such a manner that if some condition were true,
>>>> then any 'tja' within was going to get enclosed by extern "C" { tja }.
>>>
>>> I have no idea what you mean by 'tja'. The wrapping in
>>> extern "C" {
>>> }
>>> only occurs when used in a c++ compiler, and prevents the linkage
>>> names being mauled. It does not happen when compiling ggets.o,
>>> because ggets is a C module.
>>
>> There exists no ggets.o file in whatever I unzipped. One is left to
>> believe that '.o' is a typo or an intermediate file during
>> compiling-linking.
>
> You are new to the C language, aren't you?
FWIW, many MS-DOS (and Windows?) compilers use ".obj" instead of
".o" for object files. So that comment just says that Frank is new
to the /Unix/ world. (His later comments about header files do make
me think he hasn't done a lot of C programming, too. I'm just being
pedantic here.)
-Arthur
Randy Howard
(in article <DP-dnf9gKYRWhg7Z...@bt.com>):
> Randy Howard said:
>
>> Frank Silvermann wrote
>>> There exists no ggets.o file in whatever I unzipped. One is left to
>>> believe that '.o' is a typo or an intermediate file during
>>> compiling-linking.
>>
>> You are new to the C language, aren't you?
>
> That's allowed. From what I've seen so far of Mr Silvermann, I have the
> impression that he's fairly new to C but far from dense.
Fair enough, but not knowing what a .o file is sort of makes
debating how to best link to C++ code, header file layout, etc.
somewhat pointless.
Randy Howard
(in article
<Pine.LNX.4.60-041....@unix42.andrew.cmu.edu>):
A fair point, I forgot about Windows and funky compilers. I try
to forget it at every opportunity.
Still, I find it difficult to imagine a lot of C programming
background and no exposure to .o before whatsoever. *shrug*
CBFalconer
> CBFalconer wrote:
>
>>
>> I have no idea what you mean by 'tja'. The wrapping in
>> extern "C" {
>> }
>> only occurs when used in a c++ compiler, and prevents the linkage
>> names being mauled. It does not happen when compiling ggets.o,
>> because ggets is a C module.
>
> There exists no ggets.o file in whatever I unzipped. One is left to
> believe that '.o' is a typo or an intermediate file during
> compiling-linking.
The .o file (or possibly .obj on some systems, or even something
else) is the result of compiling the .c file to system dependant
object code, which can then be linked into whatever other programs
you like without recompiling ggets. It is relocatable linkable
object code.
Al Balmer
<randy...@FOOverizonBAR.net> wrote:
>Frank Silvermann wrote
>(in article <4493043d$0$30716$ec3e...@news.usenetmonster.com>):
>
>> CBFalconer wrote:
>>> Frank Silvermann wrote:
>>> .... snip ...
>>>> This reply relies on what I can do off-line, which is a nice way of
>>>> saying "becoming impatient while my news server pulls the moths out
>>>> of the vacuum tubes" I do have the revised version. You put:
>>>>
>>>> int fggets(char* *ln, FILE *f);
>>>>
>>>> #define ggets(ln) fggets(ln, stdin)
>>>>
>>>> in the header in such a manner that if some condition were true,
>>>> then any 'tja' within was going to get enclosed by extern "C" { tja }.
>>>
>>> I have no idea what you mean by 'tja'. The wrapping in
>>> extern "C" {
>>> }
>>> only occurs when used in a c++ compiler, and prevents the linkage
>>> names being mauled. It does not happen when compiling ggets.o,
>>> because ggets is a C module.
>> There exists no ggets.o file in whatever I unzipped. One is left to
>> believe that '.o' is a typo or an intermediate file during
>> compiling-linking.
>
>You are new to the C language, aren't you?
The less than precise language doesn't help. One doesn't (or at least
I don't) usually speak of "compiling" an object file, and I would have
said ggets.c is a C module, not ggets.
--
Al Balmer
Sun City, AZ
Richard Bos
> Richard Heathfield wrote
> (in article <DP-dnf9gKYRWhg7Z...@bt.com>):
>
> > Randy Howard said:
> >
> >> Frank Silvermann wrote
> >>> There exists no ggets.o file in whatever I unzipped. One is left to
> >>> believe that '.o' is a typo or an intermediate file during
> >>> compiling-linking.
> >>
> >> You are new to the C language, aren't you?
> >
> > That's allowed. From what I've seen so far of Mr Silvermann, I have the
> > impression that he's fairly new to C but far from dense.
>
> Fair enough, but not knowing what a .o file is sort of makes
> debating how to best link to C++ code, header file layout, etc.
> somewhat pointless.
Not all the world's a VAX^Tgcc compiler.
Richard