libclc-developers — Communication between developers of libclc

[Libclc-developers] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[Libclc-developers] _register_frame_info

[Jyothi <jyo...@ap...>]

Hi,
I am getting this error , Is it because there is a problem in a library  =
code / there is a problem in a gcc compiler ?

Can anyone help in identifying this,
Thanks.
~~~~~~

    ^      _     =20
    | \/ () | |-| | .
(_//
=20

[Libclc-developers] newbie to ANSI C

[Jyothi <jyo...@ap...>]

 Hello,
I was just looking into how much time the strstr() function is taking .=20
I am using PentiumIII( i686) on Linux 2.2, glibc-2.2  ,=20
Is  this  data available somewhere ?=20

 What if  strstr()'s implementation be changed  in case of the following =
scenario,  =20
1. When it  uses strchr()=20
2. When it  uses  strncmp()  =20
3. When it  is not dependent on any of these C-functions ?
Are there any Algorithms  the ANSI C standard says to use while =
implementing strstr().

Any help is welcome.

~~~~~~

    ^      _     =20
    | \/ () | |-| | .
(_//
=20

[Libclc-developers] Test...

[Randy H. <ran...@me...>]

Sorry, but the lists management page says I'm already subscribed, but I
haven't got any email in months to this address.  Anybody home?



Randy Howard
ran...@me...
 

[Libclc-developers] libclc: New function for the string module?

[<bo...@me...>]

Hello.

Below is the source code for a function I needed at work today. Since it 
is pretty general, it might be a candidate for the clc_string module?

The function is a case insensitive version of strstr(), with one 
exception: I didn't have the stomach to let the function return a char* 
like strstr() does. ;-)

Please suggest a new name for the function, I'm only semi happy about 
the current clc_strcasestr(), but couldn't come up with anything better.

Bjørn



/* $Id: $ */
/*
  * Copyright(c) 2003, B. Augestad, bo...@me...
  * COPYING RESTRICTIONS APPLY, see COPYING file.
  */

#include <ctype.h>
#include <string.h>
#include "clc_assert.h"
#include "clc_string.h"

const char* clc_strcasestr(const char *haystack, const char *needle)
{
     size_t cb1, cb2;
     const char *start, *stop, *org_needle = needle;
     int c1, c2;

     clc_assert_not_null(clc_strcasestr, haystack);
     clc_assert_not_null(clc_strcasestr, needle);

     cb1 = strlen(haystack);
     cb2 = strlen(needle);

     /* The standard says that empty needles, "", returns haystack. */
     if(cb2 == 0)
         return haystack;

     /* No point in finding needles bigger than haystack */
     if(cb2 > cb1)
         return NULL;

     /* Compute the last starting point of a possible match */
     start = haystack;
     stop = start + cb1 - cb2;

     /* Now compare strings */
     while(start <= stop) {
         needle = org_needle;
         haystack = start;
         for (;; haystack++, needle++) {
             c1 = tolower((int)*haystack);
             c2 = tolower((int)*needle);

             /* If end of needle */
             if (c2 == '\0')
                 return start;
             else if(c1 != c2)
                 break;
         }

         start++;
     }

     return NULL;
}

#ifdef CLC_STRCASESTR_TEST

int main(void)
{
     const char *s;

     /* Legal variants */
     s = clc_strcasestr("A", "A");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AAA", "A");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AAA", "a");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AAB", "B");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AAB", "b");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AABcdEfGhIj123", "bcdefg");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AAA", "");
     clc_assert(main, s != NULL);

     s = clc_strcasestr("AA1AA2AA3", "AA2");
     clc_assert(main, s != NULL);

     /* Illegal variants */
     s = clc_strcasestr("AAA", "x");
     clc_assert(main, s == NULL);

     s = clc_strcasestr("AAA", "AAAAAA");
     clc_assert(main, s == NULL);

     return 0;
}
#endif

[Libclc-developers] libclc: clc_string module done!

[<bo...@me...>]

Hello, everyone.

I'm proud to announce that the string module in libclc is done and ready 
for download!

This is a major achievement, not so much because of all the high quality 
string functions now available, but just as much because we have been 
able to create the procedures and the framework for the library. We even 
have documentation, install programs, tools, man pages and more. ;-) The 
fact that this framework is in place means that it is now so much easier 
to add new functionality to the library.

Thanks to everyone who's been contributing so far!

The library is available from http://sourceforge.net/projects/libclc
or more directly from this link: 
http://sourceforge.net/project/showfiles.php?group_id=74527&release_id=161919

We're pretty sure that the code is *perfect*, but let us know if you 
find a bug or some slow code.

Download and enjoy! :-)

-- 
boa

libclc home: http://libclc.sourceforge.net

[Libclc-developers] Re: An ANSI C build system?

[Jan E. <je...@li...>]

[...]
>Here's an idea for yet another way of building libclc. Please comment.
[...]

A cross-"breed" (Win <-> Linux et al) program, like ZDoom (heh)
uses MSVC project files and Makefiles (probably configure in future).
That is all I would need.

>What do you think? Will it work on "all" platforms?

-- 
- Jan Engelhardt

[Libclc-developers] An ANSI C build system?

[<bo...@me...>]

We cannot seem to settle on one way of building libclc on the users 
machine; some like autoconf/automake, some hate it. Others would prefer 
just a simple Makefile, but we don't even know if make is present. Both 
autoconf and Makefiles would probably be unknown concepts to many 
Windows users, who's probably more used to Projects and workspaces.

Here's an idea for yet another way of building libclc. Please comment.

First of all, we cannot assume much about the machine which will be 
used. One thing we probably can assume is that there is a C compiler 
present. ;-)

The idea is that we write a program in ANSI C and distribute it with 
libclc. That program, called clcmake, is first compiled and then 
executed by the user.

Phase one, compilation: Bjorn Reese has documented in an excellent way 
the different macros defined when compiling on different OS'es using 
different compilers. That documentation is available at 
http://predef.sourceforge.net/. The source code of clcmake uses these 
macros to detect OS and compiler.

Phase two, execution: Now clcmake knows the operating system as well as 
the compiler in use. This knowledge combined with a small text-based 
database should be sufficient to compile libclc. The database would be 
read by clcmake and contain info about the platforms, compilers, 
archivers. system() will be used to compile the source code.

So the build instructions for libclc can then be:
1. Compile and link clcmake.c (cc -o clcmake clcmake.c)
2. run clcmake

That should be simple enough for everyone, shouldn't it? The concept can 
be extended to handling installation of libclc as well.

What do you think? Will it work on "all" platforms?

Most importantly, do you *like* it? If you don't, please let me know so 
that we don't waste lots of time on something that won't be used.

TIA for all comments/questions/ideas.

-- 
boa

libclc home: http://libclc.sourceforge.net

Re: [Libclc-developers] Suggested documentation format

[<bo...@me...>]

Hallvard B Furuseth wrote:
> Bjørn Augestad writes:
> 
[snip]

> 
> 
> Then attribute names in the documentation will all start with 'clc_',
> because of namespace issues.  That's not good.  And we'd also have to
> start all parameter names in the .c files with 'clc_', so that parameter
> names in clc_assert_arg() would match those in the documentation.


We can preprocess the headers when we build the documentation. A simple 
sed command can remove the clc_ prefix on argument names. That also 
solves the clc_assert problem. Not the best solution, I agree.


> 
> 
>>I'm currently using Doxygen a lot at work these days and will
>>hopefully learn the finer details about Doxygen within the next month or
>>so. This means that I can provide a good template later. The template I
>>use at work right now is approximately this:
> 
> 
> Thanks.
> 
> 
>>In addition to this I use a file section which in our case could be a
>>module description. I will in some cases use grouping as well, which
>>probably is the most confusing concept from clc_bitset.dox. The syntax
>>for grouping is not the best, IMHO.
> 
> 
> Nor is the navigation possibilities in the resulting files, unless you
> can generate an index over which functions are documented in which
> files, and a one-line file description for each file which the index
> page describes.  At least that's my impression from the documentation
> generated by bitset.dox.

Have a look at http://www.metasystems.no/metalib/. This site is 
generated by Doxygen. It is rather old and has lots of bugs, I never get 
around to finish it. :-( Still it illustrates that Doxygen does generate 
what you're missing (if I understood you correctly).

> 
> 
>>This untested example has a lot of structure, but is fairly easy to use, 
>>IMHO.  I vote for something like the example above. ;-)
> 
> 
> Well, you know my vote:-)

Yep. ;-)

[snip]


> 
> 
>>We don't have to use Doxygen, but IMO we need a structured format for 
>>the documentation and tools to convert the  doc to the proper output 
>>formats (html, man, latex, Windows help, RTF, others?).
> 
> 
> Yes that's nice.  My program can only generate html, man and text.
> I could probably add latex, but I'd have to learn it first.
> 
> Other formats: Plaintext and PostScript.  Groff can generate both from
> the manpages.

Well, Doxygen creates latex *plus* a Makefile which generates lots of 
other formats, including pdf, dvi and ps. ;-)

Of course, if you have a working program which provides us with what we 
need, I have no objection to using that instead of Doxygen. I just think 
that it might be better to use an existing program instead of inventing 
yet another toolset, if that's what we have to do.


-- 
boa

libclc home: http://libclc.sourceforge.net

Re: [Libclc-developers] Suggested documentation format

[Hallvard B F. <h.b...@us...>]

I wrote:
>Bj=F8rn Augestad writes:
>> It's usually written in the header file. Those files tend to look a bit=
=20
>> odd, esp. if we write a lot of documentation. ;-)
>
> Then attribute names in the documentation will all start with 'clc_',

Sorry, I mean argument names.  I've been talking too much LDAP lately.

--=20
Hallvard

Re: [Libclc-developers] Suggested documentation format

[Hallvard B F. <h.b...@us...>]

Bj=F8rn Augestad writes:
>Hallvard B Furuseth wrote:
>>Bj=F8rn Augestad writes:
> [I snipped a lot here, hope that's OK]

Snipping is good.

>> I don't know Doxygen, but
>> - I think clc_bitset.dox's formatting looks more complex and free-style
>>   than contributors should need to deal with.  Maybe it helps if you
>>   don't have to stuff the documentation in a C file.
>=20
> It's usually written in the header file. Those files tend to look a bit=20
> odd, esp. if we write a lot of documentation. ;-)

Then attribute names in the documentation will all start with 'clc_',
because of namespace issues.  That's not good.  And we'd also have to
start all parameter names in the .c files with 'clc_', so that parameter
names in clc_assert_arg() would match those in the documentation.

> I'm currently using Doxygen a lot at work these days and will
> hopefully learn the finer details about Doxygen within the next month or
> so. This means that I can provide a good template later. The template I
> use at work right now is approximately this:

Thanks.

> In addition to this I use a file section which in our case could be a
> module description. I will in some cases use grouping as well, which
> probably is the most confusing concept from clc_bitset.dox. The syntax
> for grouping is not the best, IMHO.

Nor is the navigation possibilities in the resulting files, unless you
can generate an index over which functions are documented in which
files, and a one-line file description for each file which the index
page describes.  At least that's my impression from the documentation
generated by bitset.dox.

> This untested example has a lot of structure, but is fairly easy to use,=
=20
> IMHO.  I vote for something like the example above. ;-)

Well, you know my vote:-) It's all very nice to have the documentation
together with the source, but it has its small troubles, and I also like
better control over what the documentation will look like.  Also it gets
more verbose:  One can't include a single section like
    RETURN VALUE
        These functions return the dest parameter.
Instead this gets repeated for each function description.

> We don't have to use Doxygen, but IMO we need a structured format for=20
> the documentation and tools to convert the  doc to the proper output=20
> formats (html, man, latex, Windows help, RTF, others?).

Yes that's nice.  My program can only generate html, man and text.
I could probably add latex, but I'd have to learn it first.

Other formats: Plaintext and PostScript.  Groff can generate both from
the manpages.

--=20
Hallvard

Re: [Libclc-developers] Suggested documentation format

[<bo...@me...>]

Hallvard B Furuseth wrote:
> Bjørn Augestad writes:
[I snipped a lot here, hope that's OK]

> 
> 
>>If Doxygen does what we need and is widely used, well documented and
>>mature, do we need our own format and toolset?
> 
> 
> I don't know Doxygen, but
> - I think clc_bitset.dox's formatting looks more complex and free-style
>   than contributors should need to deal with.  Maybe it helps if you
>   don't have to stuff the documentation in a C file.

It's usually written in the header file. Those files tend to look a bit 
odd, esp. if we write a lot of documentation. ;-)

> - I like to have an idea what the documentation I write will look like,
>   but I'm not sure how to tell from the input documentation how the
>   output documentation will be structured.  Maybe recommending a subset
>   of Doxygen's features and providing a template can fix that?

[snip]

I'm currently using Doxygen a lot at work these days and will
hopefully learn the finer details about Doxygen within the next month or
so. This means that I can provide a good template later. The template I
use at work right now is approximately this:

/**
  * @brief One line description
  *
  * The long description goes here and can span multiple lines.
  *
  * @par Example
  * @code
  *    Example C code goes here
  * @endcode
  *
  * @param  Describe parameters if applicable
  * @return Describe what the function returns
  * @see    Add references if applicable
  * @author Who wrote it.
  */
char* clc_strdup(const char* src);

In addition to this I use a file section which in our case could be a
module description. I will in some cases use grouping as well, which
probably is the most confusing concept from clc_bitset.dox. The syntax
for grouping is not the best, IMHO.

A real world example, borrowed from clc_string, is:
/**
  * @brief copy limited string and return pointer to end
  *
  * clc_strendcpy() copies the string src to dst, truncates it if
  * the length is >= end, and null-terminates it.
  * Nothing is done if dst >= end.
  *
  * @param  dst Destination string
  * @param  src Source string
  * @param  end You tell me ;-)
  *
  * @return clc_strendcpy() returns a pointer to the terminating null
  * character in dst, or to end (i.e. one past the null) if the string
  * was truncated. It return dst if dst >= end.
  *
  * @par Example
  * @code
  *     char buf[80], *end = buf + sizeof(buf);
  *     char *dst = clc_strendcpy(buf, str1, end);
  *     dst = clc_strendcpy(dst, str2, end);
  *     if (dst >= end)
  *         warning("string was truncated");
  * @endcode
  *
  * @see clc, strcpy, strncpy, clc_strlcpy, clc_stpcpy
  *
  * @author Howard Chu
  */
char *clc_strendcpy(
     char *dst,
     const char *CLC_RESTRICT src,
     const char *end);

This untested example has a lot of structure, but is fairly easy to use, 
IMHO.  I vote for something like the example above. ;-)

We don't have to use Doxygen, but IMO we need a structured format for 
the documentation and tools to convert the  doc to the proper output 
formats (html, man, latex, Windows help, RTF, others?).

It's almost time do decide on this issue, since it is blocking lots of 
other things like the release of the clc_string module and a proper 
introduction to Regis' clc_bitset.

Opinions very much wanted. :-)


-- 
boa

libclc home: http://libclc.sourceforge.net

Re: [Libclc-developers] -std=c99 vs. -ansi

[Hallvard B F. <h.b...@us...>]

Bj=F8rn Augestad writes:
> We should probably have both a /builds/gcc/c89 and c99 version, as we=20
> need to test c99 specific stuff like CLC_RESTRICT.

Good point.  Though it's probably easier to have just one Makefile
which people can edit or copy, with this near the top:

# Uncomment one of these: ISO C89 or ISO C99.
STD =3D -ansi
# STD =3D -std=3Dc99

Then,

CFLAGS =3D $(STD) -pedantic -Wall ...

--=20
Hallvard

Re: [Libclc-developers] -std=c99 vs. -ansi

[<bo...@me...>]

Hallvard B Furuseth wrote:
> builds/gcc/Makefile compiles with gcc -std=c99.  I think -ansi is
> better:  More people have support for it, and it will catch more
> unportable code because C89 is generally more restrictive than C99.
> Though there are a few C89 things which C99 disallows too.
> 

We should probably have both a /builds/gcc/c89 and c99 version, as we 
need to test c99 specific stuff like CLC_RESTRICT.

-- 
boa

libclc home: http://libclc.sourceforge.net

[Libclc-developers] -std=c99 vs. -ansi

[Hallvard B F. <h.b...@us...>]

builds/gcc/Makefile compiles with gcc -std=c99.  I think -ansi is
better:  More people have support for it, and it will catch more
unportable code because C89 is generally more restrictive than C99.
Though there are a few C89 things which C99 disallows too.

-- 
Hallvard

[Libclc-developers] test code

[Hallvard B F. <h.b...@us...>]

Some *.c files in CVS have the code
    #ifdef CLC_TEST
    int main() { test code...; }
    #endif
This does not work if a.c requires b.c and both have this code, since we
get duplicate main().  Also it means that the code must be compiled
twice: Once with CLC_TEST to test it, once without to build the library.

I think we instead should have a file test.c in each module directory
which tests the various functions in that module.

Furthermore, so that we can run the test code from 'make test', test.c
should not take user input and should not require the user to read the
output.  Instead it should just do some hard-coded tests and do
exit(EXIT_SUCCESS) without printing anything at success, and print an
error message to stderr and do exit(EXIT_FAILURE) if a test fails.

Or if that's too simplistic, it could take input from test.inp and write
output to test.log, and 'make test' could compare test.log with a
preexisting test.out.  But I think that can wait until we find we
actually need it.

Comments?

-- 
Hallvard

Re: [Libclc-developers] Suggested documentation format

[Hallvard B F. <h.b...@us...>]

Bj=F8rn Augestad writes:

[I'm moving the bottom paragraph to the top, since this answer
got rather longer than I intended.  Sorry about that.]

> BTW, there seems to be a lot of confusion about doxygen. We don't have
> to tag everything and we don't have to write the documentation in the
> source/header files. Doxygen will process any file we ask it to
> process.  ;-)

That sounds better than clc_bitset.dox.  Maybe you can make an example
of an input file which documents a few functions, is as simple as
possible, and puts all the documentation in just one output file, like I
suggest below?  Unless, of course, you disagree that this is desirable.

> Your suggestion give me the impression that you have done this before.=20

Not really.  I have just struggled with poor user-written documentation
and ended up with some firm opinions about and how _not_ to do it, and
by implication how to do it: *Keep the format as simple as possible*.
As few format strings and special characters as possible.  Simple and
fairly rigid structure - the simpler the better.  (The doxygen variant
of that would be to use only a subset of Doxygen, and maybe write a
program which warns about deviations from this format.)  Have a program
most contributors can run which will generate a result they can inspect
and give warnings about things they did wrong.  A simple template to
fill in.  Etc.  I'm sometimes undecided about just what 'simple' means,
though: e.g. is it 'simpler' that my format says that an all-uppercase
one-line paragraph is a section header than it is to require a '@section
<section-name>' command?

Incidentally, I think some details about src/bitset/clc_bitset.dox are a
fine example of how _not_ to do it, though perhaps you were
demonstrating doxygen features rather than making nice documentation:
group__clc__bitset__card.html uses different formats for the
documentation of different functions (i.e. with/without Parameters and
Returns: sections).  A more rigid doc format would make it harder to
make that mistake.  And it splits the info in too many .html files
(maybe that can be changed?), when one single file documenting Bitset
would be more convenient.
BTW, one bug: The documentation lacks '#include <clc_bitset.h>'.

> If so, have you previously evaluated tools and formats like Doxygen
> and DocBook?

No.  I just started loosely with Pod format and reduced it further.
About Doxygen, I've looked at clc_bitset.dox and its output and didn't
like either, that's about all.  I've already covered the input format.
For the output format, personally I prefer documentation which is
structured more like manpages than the output from clc_bitset.dox.  For
example, describing many functions' parameters in one lump, and return
values (and error codes) in one lump each.  Maybe that can be fixed, if
Bertrand agrees.

> My personal experience is that Doxygen will give us most or everything
> of what we need, but I have no experience with neither SGML nor
> DocBook.

SGML is not a single format; it's the DTD you use which matters.  I
don't know DocBook.  It's SGML/XML, though.  So I vote against them:
SGML is not something the contributor should have to write, nor should
he have to download and install SGML or DocBook software in order to be
able write documentation.

> If Doxygen does what we need and is widely used, well documented and
> mature, do we need our own format and toolset?

I don't know Doxygen, but
- I think clc_bitset.dox's formatting looks more complex and free-style
  than contributors should need to deal with.  Maybe it helps if you
  don't have to stuff the documentation in a C file.
- I like to have an idea what the documentation I write will look like,
  but I'm not sure how to tell from the input documentation how the
  output documentation will be structured.  Maybe recommending a subset
  of Doxygen's features and providing a template can fix that?
- It won't give most contributors a look at the documentation they have
  produced since most won't download it.  Unless you mean for the
  documentation manager to translate all user-contributed documentation
  to Doxygen format.  I tried to think of a format that users can
  contribute (and verify) directly, and which will be as easy as
  possible for the doc manager to fix up if they blow it.

BTW, perhaps I should mention that 'my' format will need one addition
in user files: '@entry <function-name> - <one-line description>' for
each function in files that describe several functions.  And an
'@index' command in clc.* which displays the @entries and NAMEs.

--=20
Hallvard

Re: [Libclc-developers] Suggested documentation format

[<bo...@me...>]

Hallvard B Furuseth wrote:
> Here is a suggestion for a file format for documentation.
> Contributors should write this, though maybe the documentation
> manager(s) will clean the file up a little, and it will be used to
> generate the other formats. If accepted, I'll write a Perl program to
> process it.  The overall documentation structure reflects Unix man
> pages, as in <http://libclc.sourceforge.net/documentation-policy.txt>.
> I've also added an initial NAME section.  (Bertrand, are you there?:-)
> 
> Comments welcome.

No comments, just a question or two.

Your suggestion give me the impression that you have done this before. 
If so, have you previously evaluated tools and formats like Doxygen and 
DocBook?

My personal experience is that Doxygen will give us most or everything 
of what we need, but I have no experience with neither SGML nor DocBook. 
If Doxygen does what we need and is widely used, well documented and 
mature, do we need our own format and toolset?

BTW, there seems to be a lot of confusion about doxygen. We don't have 
to tag everything and we don't have to write the documentation in the 
source/header files. Doxygen will process any file we ask it to process. 
;-)

Bjørn

Re: [Libclc-developers] cvs/work_in_progress/stl/clc_list.c

[regis <re...@in...>]

regis wrote:
> 
> I found the code below in clc_list.c  the cvs repository:
> 
> <code>
> 
> struct clc_list_tag {
>         struct clc_list_tag *next, *prev;
>         void* data;
> };
> 
> clc_list clc_list_new(void)
> {
>         clc_list lst;
> 
>         lst = calloc(1, sizeof *lst);
>         return lst;
> }
> 
> </code>


[...]

Just before leaving my office, 
a general remark about the design of the list.

confusing a list with a list-node 
and defining a list as a pointer to a leading dummy list-node
is dangerous and prevents any evolution:
that means that a list has no other knowledge than a list-node.

For example, what happens the list has later to maintain its
cardinality so that it can be queried in constant time instead
of linear time? We can't do it.

Generally, it is a bad idea to use the same structures
for containers and their container-cells, 
even if they are mathematically defined as recursive objects
For the same reason, a tree should not be confused with
its root or a dummy node pointing to its root.

clc_list and clc_listnode should be distinct structs.

-- 
Regis

[Libclc-developers] cvs/work_in_progress/stl/clc_list.c

[regis <re...@in...>]

I found the code below in clc_list.c  the cvs repository:

<code>

struct clc_list_tag {
        struct clc_list_tag *next, *prev;
        void* data;
};

clc_list clc_list_new(void)
{
        clc_list lst;

        lst = calloc(1, sizeof *lst);
        return lst;
}

</code>

It is erroneous because though calloc zeroes all the reserved bytes,
it does not mean that the pointers next, prev and data will be NULL:
The representation of a null pointer is not necessarily the
pattern with all bits to zero.
The correct way to init the fields is

clc_list clc_list_new(void)
{
        clc_list lst;

        lst = malloc(sizeof *lst);
        if (! lst) return NULL;
        lst->data= NULL;
        lst->next= lst->prev= NULL; 
        return lst;
}


(I can't be contacted till monday...)

-- 
Regis

Re: [Libclc-developers] Re: clc_ultostr doc change

[Jan E. <je...@li...>]

>Whatever it is, the point is that it is a real mess
>and that one should not go into that direction
>for libclc.
Now that we know...

-- 
- Jan Engelhardt

Re: [Libclc-developers] Re: clc_ultostr doc change

[regis <re...@in...>]

Jan Engelhardt wrote:
> 
> >> > >> >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html
> >> > >> The only thing I am worried about is a prefix for Ncurses.
> >> > >beuarhhhhh....
> >> > Or what was it about, then?
> >> it is unreadable and inconsistent.
> >> mvaddchstr(): 'move' shrinked to 'mv'
> >correction: for the latter,
> >I'm not even able to gues what 'mv' stands for.
> 
> eh, for /bin/mv? which probably moves.

Whatever it is, the point is that it is a real mess 
and that one should not go into that direction
for libclc.

[Libclc-developers] Re: clc_ultostr doc change

[Jan E. <je...@li...>]

>> > >> >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html
>> > >> The only thing I am worried about is a prefix for Ncurses.
>> > >beuarhhhhh....
>> > Or what was it about, then?
>> it is unreadable and inconsistent.
>> mvaddchstr(): 'move' shrinked to 'mv'
>correction: for the latter,
>I'm not even able to gues what 'mv' stands for.

eh, for /bin/mv? which probably moves.


- Jan Engelhardt

[Libclc-developers] lib*clc*

[Hallvard B F. <h.b...@us...>]

If this discussion doesn't move to comp.lang.c soon, libclc is not going
to be the comp.lang.c librarly.

Incidentally, I'm planning to remove clc_ultostr() from the string
module, since the only opinion expressed about ot on comp.lang.c is that
I should.  See message ID <b6bqgt$fq2$1...@su...>.  I know
someone has said differently on this list, but as I said that doesn't
count.  Though of course that may be because they don't care enough
either way to voice an 'official' opinion in favor of it, so maybe it's
all right.

-- 
Hallvard

Re: [Libclc-developers] Re: clc_ultostr doc change

[regis <re...@in...>]

regis wrote:
> 
> Jan Engelhardt wrote:
> >
> > >> >With good naming conventions, you only scan the prototype in the docs
> > >> >to find what you want
> > >> >With bad ones, you must also read the full description.
> > >> >Have a look at the libncurse documentation to see what I mean.
> > >> >You really want "this" ?
> > >> >http://www.linuxbase.org/spec/refspecs/LSB_1.2.0/gLSB/libncurses.html
> > >>
> > >> The only thing I am worried about is a prefix for Ncurses.
> > >
> > >beuarhhhhh....
> >
> > Or what was it about, then?
> >
> > - Jan Engelhardt
> 
> it is unreadable and inconsistent.
> Exemples:
> 
> addchstr(): no underscore, start with the verb
> attr_get(): noun prefix + one underscore, end with the verb.
> tgetflag(): no underscore, the verb is in the middle.
> has_ic(): verb prefix +  one underscore
> move(): verb written in full
> mvaddchstr(): 'move' shrinked to 'mv'

correction: for the latter,
I'm not even able to gues what 'mv' stands for.