ANNOUNCE ggets revised

Discussion in 'C Programming' started by CBFalconer, Jun 15, 2006.

  1. CBFalconer

    CBFalconer Guest

    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, Jun 15, 2006
    #1
    1. Advertising

  2. CBFalconer

    CBFalconer Guest

    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, Jun 15, 2006
    #2
    1. Advertising

  3. 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, Jun 15, 2006
    #3
  4. CBFalconer

    Michael Mair Guest

    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, Jun 15, 2006
    #4
  5. 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, Jun 15, 2006
    #5
  6. CBFalconer

    Michael Mair Guest

    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.
    Michael Mair, Jun 15, 2006
    #6
  7. CBFalconer

    CBFalconer Guest

    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
    CBFalconer, Jun 15, 2006
    #7
  8. CBFalconer

    CBFalconer Guest

    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
    CBFalconer, Jun 15, 2006
    #8
  9. 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) <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, Jun 15, 2006
    #9
  10. 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
    Frank Silvermann, Jun 15, 2006
    #10
  11. CBFalconer

    Old Wolf Guest

    Michael Mair wrote:
    >
    > 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.


    It doesn't use stdin, it contains a macro with stdin in it.
    And you can forward-declare FILE on its own.

    >As this would mean
    > some uglification, e.g.
    > # ifdef __cplusplus
    > # include <cstdio>
    > extern "C" {
    > # else
    > # include <stdio.h>
    > # endif


    #include <stdio.h> is correct C++ code.

    > I can understand that the appropriate headers are not
    > included (ignoring the problem of knowing the appropriate
    > header for different C++ implementations).


    Well, the C++ standard library has a function that does
    the same as what ggets does. So I guess that ggets
    would only be used by C++ programmers who do not
    want to use the C++ standard library for some reason.
    Old Wolf, Jun 16, 2006
    #11
  12. CBFalconer

    Michael Mair Guest

    Old Wolf schrieb:
    > Michael Mair wrote:
    >
    >>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.

    >
    >
    > It doesn't use stdin, it contains a macro with stdin in it.


    True, thus the "uses".
    As soon as you just want to have, for example,

    #include <stdlib.h>
    #include "ggets.h"
    #include "foo.h"

    int main (void)
    {
    char *s = 0;
    if (!ggets(&s)) {
    foo *bar;
    if (bar = calculateFoo(s)) {
    outputFoo(bar);
    freeFoo(bar);
    }
    }
    free(s);
    return 0;
    }
    you need to #include <stdio.h> even though you do not
    obviously "need" it for using ggets(). This is ugly and
    a "header defect" like this may not pass code review in
    some companies.


    > And you can forward-declare FILE on its own.


    How can you do so in standard C?
    "FILE [...] is an object type capable of recording all the information
    needed to control a stream, including its file position indicator,
    a pointer to its associated buffer (if any), an error indicator that
    records whether a read/write error has occurred, and an end-of-file
    indicator that records whether the end of the file has been reached".
    If the type were guaranteed to be a typedef for "struct _FILE_T", I'd
    agree with you.

    >>As this would mean
    >>some uglification, e.g.
    >> # ifdef __cplusplus
    >> # include <cstdio>
    >> extern "C" {
    >> # else
    >> # include <stdio.h>
    >> # endif

    >
    > #include <stdio.h> is correct C++ code.


    .... and deprecated. Why risk having to change all include
    directives for "stdio" for a new compiler (version)?


    >>I can understand that the appropriate headers are not
    >>included (ignoring the problem of knowing the appropriate
    >>header for different C++ implementations).

    >
    > Well, the C++ standard library has a function that does
    > the same as what ggets does. So I guess that ggets
    > would only be used by C++ programmers who do not
    > want to use the C++ standard library for some reason.


    This is a very reasonable guess. Sometimes, people have
    "good" reasons to do more or less unreasonable things,
    though.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Jun 16, 2006
    #12
  13. CBFalconer

    Michael Mair Guest

    CBFalconer schrieb:
    > 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.


    I am aware of this; the ugliness in my opinion consists of
    a header not bringing in everything necessary to use it.
    The include problem is one reason why I still accept it as
    is; another reason is that you usually need to explicitly
    construct a situation where you use fggets()/ggets()
    without having included <stdio.h>. The dependence between
    the respective include directives still is not overly
    joyous even if rules like "standard headers before library
    headers before user headers" automatically fix the problem.
    YMMV.


    Cheers
    Michael
    --
    E-Mail: Mine is an /at/ gmx /dot/ de address.
    Michael Mair, Jun 16, 2006
    #13
  14. CBFalconer

    CBFalconer Guest

    Michael Mair wrote:
    > CBFalconer schrieb:
    >

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

    >
    > I am aware of this; the ugliness in my opinion consists of
    > a header not bringing in everything necessary to use it.
    > The include problem is one reason why I still accept it as
    > is; another reason is that you usually need to explicitly
    > construct a situation where you use fggets()/ggets()
    > without having included <stdio.h>. The dependence between
    > the respective include directives still is not overly
    > joyous even if rules like "standard headers before library
    > headers before user headers" automatically fix the problem.


    I disagree that stdio.h is needed to use ggets. The only thing
    that might cause trouble is the definition of EOF in the return
    value, but detection of a negative value suffices there. So the
    using program need only include things that it itself needs. If it
    needs the value of EOF, or an output routine, it must include
    stdio.h for its own purposes.

    The following should function anywhere:

    #include <stdlib.h> /* for free */
    #include "ggets.h" /* for ggets */

    int main(void) {
    char *line;

    while (0 == ggets(&line) free(line);
    return 0;
    }

    although there may be a difficulty with the value of 'stdin', which
    is hidden in the ggets macro.

    --
    "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
    CBFalconer, Jun 16, 2006
    #14
  15. CBFalconer wrote:
    > 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.

    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 } . 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?
    Frank Silvermann, Jun 16, 2006
    #15
  16. CBFalconer

    CBFalconer Guest

    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.

    > 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
    CBFalconer, Jun 16, 2006
    #16
  17. CBFalconer <> writes:
    [...]
    > I disagree that stdio.h is needed to use ggets. The only thing
    > that might cause trouble is the definition of EOF in the return
    > value, but detection of a negative value suffices there. So the
    > using program need only include things that it itself needs. If it
    > needs the value of EOF, or an output routine, it must include
    > stdio.h for its own purposes.
    >
    > The following should function anywhere:
    >
    > #include <stdlib.h> /* for free */
    > #include "ggets.h" /* for ggets */
    >
    > int main(void) {
    > char *line;
    >
    > while (0 == ggets(&line) free(line);
    > return 0;
    > }
    >
    > although there may be a difficulty with the value of 'stdin', which
    > is hidden in the ggets macro.


    I'm not sure what you mean by "although there may be a difficulty".
    With a "#include <stdio.h>", there's no problem with the *value* of
    stdin, because it's an undeclared identifier. Likewise for FILE.

    The expansion of #include "ggets.h" refers to the identifier FILE; the
    expansion of ggets(&line) refers to the identifer stdin. How exactly
    do you expect the compiler to resolve these identifiers without a
    "#include <stdio.h>"?

    (You also have a missing right parenthesis, corrected below).

    % cat tmp.c
    #include <stdlib.h> /* for free */
    #include "ggets.h" /* for ggets */

    int main(void) {
    char *line;

    while (0 == ggets(&line)) free(line);
    return 0;
    }
    % gcc -c tmp.c
    In file included from tmp.c:2:
    ggets.h:37: error: syntax error before 'FILE'
    tmp.c: In function 'main':
    tmp.c:7: error: 'stdin' undeclared (first use in this function)
    tmp.c:7: error: (Each undeclared identifier is reported only once
    tmp.c:7: error: for each function it appears in.)

    Adding a "#include <stdio.h>" to the top of tmp.c corrects the
    problem, but the #include <stdio.h>" should be in "ggets.h".

    --
    Keith Thompson (The_Other_Keith) <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, Jun 16, 2006
    #17
  18. 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.

    >> 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
    Frank Silvermann, Jun 16, 2006
    #18
  19. CBFalconer

    Randy Howard Guest

    Frank Silvermann wrote
    (in article <4493043d$0$30716$>):

    > 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
    Randy Howard, Jun 16, 2006
    #19
  20. 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.

    --
    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)
    Richard Heathfield, Jun 16, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. fidlee

    about ggets()

    fidlee, Dec 26, 2005, in forum: C Programming
    Replies:
    11
    Views:
    1,396
    fidlee
    Dec 28, 2005
  2. Andreas Otto
    Replies:
    0
    Views:
    276
    Andreas Otto
    Sep 25, 2009
  3. Andreas Otto
    Replies:
    0
    Views:
    328
    Andreas Otto
    Sep 25, 2009
  4. Andreas Otto
    Replies:
    0
    Views:
    334
    Andreas Otto
    Sep 25, 2009
  5. Andreas Otto
    Replies:
    34
    Views:
    1,012
    Dave Searles
    Oct 7, 2009
Loading...

Share This Page