Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > ANNOUNCE ggets revised

Reply
Thread Tools

ANNOUNCE ggets revised

 
 
CBFalconer
Guest
Posts: n/a
 
      06-15-2006
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 ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!


 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      06-15-2006
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 ((E-Mail Removed)) ((E-Mail Removed))
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE maineline address!

 
Reply With Quote
 
 
 
 
Frank Silvermann
Guest
Posts: n/a
 
      06-15-2006
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
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      06-15-2006
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.
 
Reply With Quote
 
Frank Silvermann
Guest
Posts: n/a
 
      06-15-2006
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
 
Reply With Quote
 
Michael Mair
Guest
Posts: n/a
 
      06-15-2006
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.
 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-15-2006
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


 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      06-15-2006
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


 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      06-15-2006
Michael Mair <(E-Mail Removed)> 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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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.
 
Reply With Quote
 
Frank Silvermann
Guest
Posts: n/a
 
      06-15-2006
Keith Thompson wrote:
> Michael Mair <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
ANNOUNCE libmsgque 3.5, ANNOUNCE (P)rogramming (L)anguage (M)icro(K)ernel 1.0 Andreas Otto C++ 0 09-25-2009 03:19 PM
ANNOUNCE libmsgque 3.5, ANNOUNCE (P)rogramming (L)anguage (M)icro(K)ernel 1.0 Andreas Otto C Programming 0 09-25-2009 03:16 PM
ANNOUNCE libmsgque 3.5, ANNOUNCE (P)rogramming (L)anguage (M)icro(K)ernel 1.0 Andreas Otto Python 0 09-25-2009 03:14 PM
about ggets() fidlee C Programming 11 12-28-2005 12:05 PM
How do I announce this? (Revised) vbmark Computer Support 22 08-12-2005 12:21 AM



Advertisments