Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: libclc: clc_getopt (a bit long, 155 lines)

Reply
Thread Tools

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

 
 
Michel Bardiaux
Guest
Posts: n/a
 
      07-15-2003
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

 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Bj=F8rn_Augestad?=
Guest
Posts: n/a
 
      07-15-2003
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

 
Reply With Quote
 
 
 
 
Chris Torek
Guest
Posts: n/a
 
      07-16-2003
In article <(E-Mail Removed)>
Michel Bardiaux <(E-Mail Removed)> 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.
 
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
Mitsubishi demo 155" OLED Display Mary Hanna NZ Computing 0 10-11-2009 08:14 AM
P 155 k&r section 7.3 mdh C Programming 35 09-08-2008 08:55 PM
Red Hat Ent. WS x64 $155; P3 1GHz $33 at Geeks Randy Windows 64bit 0 01-02-2006 01:01 AM
Sennheiser PC 155 USB @ BoxGods Silverstrand Front Page News 2 06-26-2005 07:13 AM
WIN32ALL-155 thru 159 Crash On Install The Jetman Python 0 10-31-2003 12:57 AM



Advertisments