«

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/>

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

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.

--
Chuck F () ()
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

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:
#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

Frank Silvermann schrieb:
> 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.

Michael Mair wrote:
> Frank Silvermann schrieb:
>> 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.
I'm looking for an explicit answer to something I'm assuming,
given that posting non standard stuff in clc would be a first for the
OP. Is everything in that header ISO C, 2006-06-15 ? gruss, frank

Frank Silvermann schrieb:
> Michael Mair wrote:
>
>> Frank Silvermann schrieb:
>>
>>> 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.
>
> I'm looking for an explicit answer to something I'm assuming,
> given that posting non standard stuff in clc would be a first for the
> OP. Is everything in that header ISO C, 2006-06-15 ? gruss, frank

It definitely is valid as C90 or C99 + TC1 + TC2 code and
everything in between, with the stipulation for pre-C99
implementations that they must not define __cplusplus as
macro identifier.
If you have a pre-C99 implementation that does define
__cplusplus, then you will get a diagnostic ("compiler
error") from it.
Of course, if you yourself invade the implementation
"namespace" and #define __cplusplus, you face the same
problem.

As an aside: The only thing open to debate from a C point
of view is the question whether the header should contain
#include <stdio.h>
or not since it "uses" FILE and stdin. As this would mean
some uglification, e.g.
# ifdef __cplusplus
# include <cstdio>
extern "C" {
# else
# include <stdio.h>
# endif
I can understand that the appropriate headers are not
included (ignoring the problem of knowing the appropriate
header for different C++ implementations).


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

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.

--
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

Michael Mair wrote:
>
.... snip ...
>
> As an aside: The only thing open to debate from a C point
> of view is the question whether the header should contain
> #include <stdio.h>
> or not since it "uses" FILE and stdin. As this would mean
> some uglification, e.g.
> # ifdef __cplusplus
> # include <cstdio>
> extern "C" {
> # else
> # include <stdio.h>
> # endif
> I can understand that the appropriate headers are not
> included (ignoring the problem of knowing the appropriate
> header for different C++ implementations).

The header is not intended to enable compilation of ggets via a C++
compiler, but only the linkage to its code module from a C++
program.

--
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

Michael Mair <> writes:
[...]
> It definitely is valid as C90 or C99 + TC1 + TC2 code and
> everything in between, with the stipulation for pre-C99
> implementations that they must not define __cplusplus as
> macro identifier.
> If you have a pre-C99 implementation that does define
> __cplusplus, then you will get a diagnostic ("compiler
> error") from it.
[...]

Unless the implementation happens to support extern "C" as an
extension. I seriously doubt that any pre-C99 C implementations
define __cplusplus; if any did, they'd probably be trying to act like
C++ implementations, and would probably support extern "C".

Practically speaking, it's vanishingly unlikely to be a problem.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson wrote:
> Michael Mair <> writes:
> [...]
>> It definitely is valid as C90 or C99 + TC1 + TC2 code and
>> everything in between, with the stipulation for pre-C99
>> implementations that they must not define __cplusplus as
>> macro identifier.
>> If you have a pre-C99 implementation that does define
>> __cplusplus, then you will get a diagnostic ("compiler
>> error") from it.
> [...]
>
> Unless the implementation happens to support extern "C" as an
> extension. I seriously doubt that any pre-C99 C implementations
> define __cplusplus; if any did, they'd probably be trying to act like
> C++ implementations, and would probably support extern "C".
>
> Practically speaking, it's vanishingly unlikely to be a problem.
>
I've got a version from around '94 from the Evil Empire, and I believe
it ifdefs around the __cplusplus. The opportunity I see in this code
posting to have the languages talk to each other with less grief. For
me, I've been operating at the never_the_twain_shall_meet_below_the_OS
status for a while. I see a way to get results in the manner of Charles
Petzold without Appwizard removing my ability to debug. That's got too
sharp a tone to it on a day when Bill Gates announces he's gonna step
down. That's a tough day for a programmer. frank