Re: libclc: clc_getopt (a bit long, 155 lines)

Discussion in 'C Programming' started by Michel Bardiaux, Jul 15, 2003.

  1. Bjørn Augestad wrote:
    > Hello, everyone.
    >

    [snip]

    >
    > extern char *optarg;
    > extern int optind;
    > extern int opterr;
    > extern int optopt;


    (1) The whole thing should use a uniform namespace - clc_ for all extern
    variables and functions.

    (2) Because the BSD original did not care about reentrancy, does not
    mean more modern implementations should do the same. DEATH TO GLOBAL
    VARIABLES! The 4 should be in a struct clc_getopt_context.

    [snip]

    > if(opterr && *ostr != ':')
    > fprintf(stderr, "illegal option -- %c\n", optopt);


    I profoundly dislike a library that talks without being asked to;
    printouts should be optional (one more field in the context). And I
    dislike a library that imposes its input/output system. The printout
    should be by a user-supplied printf-like method (one more field in the
    context). Which means the header should define a detailed set of error
    codes.

    To summarize: this may be spotless ISO-C; but as a design, it
    perpetuates the problems of past implementations. Is the rest of libclc
    in the same style?

    --
    Michel Bardiaux
    Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
    Tel : +32 2 790.29.41
    Michel Bardiaux, Jul 15, 2003
    #1
    1. Advertising

  2. Re: libclc: clc_getopt

    Michel Bardiaux wrote:

    > Bjørn Augestad wrote:
    >
    >> Hello, everyone.
    >>

    > [snip]
    >
    >>
    >> extern char *optarg;
    >> extern int optind;
    >> extern int opterr;
    >> extern int optopt;

    >
    >
    > (1) The whole thing should use a uniform namespace - clc_ for all extern
    > variables and functions.


    We all seemed to agree on that, so that's already been fixed.


    >
    > (2) Because the BSD original did not care about reentrancy, does not
    > mean more modern implementations should do the same. DEATH TO GLOBAL
    > VARIABLES! The 4 should be in a struct clc_getopt_context.


    I agree that globals normally aren't a good thing. Parsing arguments to
    main() is normally not an area where reentrancy is needed though.

    Backward compatibility, at least on a conceptual level, has been an
    issue here. clc_getopt() is a port of the BSD getopt() function, with as
    few changes as possible. I'm pretty sure that a better version can be
    designed and implemented, the nice thing with (clc_)getopt() is that it
    covers most needs for most users. It'd be nice to have GNU's long option
    names though.

    >
    > [snip]
    >
    >> if(opterr && *ostr != ':')
    >> fprintf(stderr, "illegal option -- %c\n", optopt);

    >
    >
    > I profoundly dislike a library that talks without being asked to;
    > printouts should be optional (one more field in the context). And I
    > dislike a library that imposes its input/output system.

    The printout
    > should be by a user-supplied printf-like method (one more field in the
    > context). Which means the header should define a detailed set of error
    > codes.
    >
    > To summarize: this may be spotless ISO-C; but as a design, it
    > perpetuates the problems of past implementations. Is the rest of libclc
    > in the same style?


    Depends on what you mean. It is spotless ISO-C, of course. Is it
    anything particular you dislike with past implementations? I'm not quite
    sure what you mean here, so it's hard to give you a good answer.

    We had multiple, very long discussions about general design guidelines,
    error handling and other issues way back in february & march. The
    general consensus was that the principles and concepts of the standard
    library works well and that we shouldn't rock the boat too much. Libclc
    is intended to become an extension of the standard library, not a
    replacement.

    libclc therefore does not introduce any revolutionary new concepts in C
    programming and users should feel quite familiar with it from day one.
    The best thing is probably to check it out for yourself, but keep in
    mind that this version 0.1.5. libclc still has a long way to go.

    Regards,
    Bjørn

    --
    boa

    libclc home: http://libclc.sourceforge.net
    =?ISO-8859-1?Q?Bj=F8rn_Augestad?=, Jul 15, 2003
    #2
    1. Advertising

  3. Michel Bardiaux

    Chris Torek Guest

    In article <>
    Michel Bardiaux <> writes:
    >(2) Because the BSD original did not care about reentrancy ...


    While there were plenty of silly things originating at Berkeley,
    I must point out that the getopt interface, including the four
    global variables, came not from "BSD" but rather from the folks
    at AT&T's Unix System Group (USG).

    The practice has since been enshrined in numerous standards,
    making it difficult to remove.

    >> if(opterr && *ostr != ':')
    >> fprintf(stderr, "illegal option -- %c\n", optopt);

    >
    >I profoundly dislike a library that talks without being asked to;
    >printouts should be optional (one more field in the context).


    This is what "opterr" -- yet another global variable brought to to
    you by USG -- is about. If you clear it, the routine does not
    produce diagnostics. This "feature" was not documented, but various
    freely-distributed programs that had been written for USG Unix
    depended on it, so we had to include it too.
    --
    In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Jul 16, 2003
    #3
    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. James Antill
    Replies:
    2
    Views:
    365
    Randy Howard
    Jul 21, 2003
  2. Hallvard B Furuseth
    Replies:
    6
    Views:
    428
    Peter Nilsson
    Jul 22, 2003
  3. Tak-Shing Chan
    Replies:
    1
    Views:
    330
    =?ISO-8859-1?Q?Bj=F8rn_Augestad?=
    Jul 22, 2003
  4. The Jetman
    Replies:
    0
    Views:
    312
    The Jetman
    Oct 31, 2003
  5. mdh

    P 155 k&r section 7.3

    mdh, Sep 6, 2008, in forum: C Programming
    Replies:
    35
    Views:
    949
    CBFalconer
    Sep 8, 2008
Loading...

Share This Page