linked-list entirely in macros

[Guest]

I have an implementation of linked lists coded entirely in macros, using
GNU C extensions __typeof__() and statement expressions. The flexibility
of this is that it allows creating your own node types and linking them
into a list very easily, without having to define type matched functions.
Type matching is done by making sure the anchor and node types do match.

This implementation creates a full circle doubly linked list in which the
last node links in the forward direction back to the first node, and also
first to last in the reverse direction. The anchor consists of a single
pointer to the first node.

To create a linked list, the program defines a struct with one of the macros
as a member, which creates 2 members to serve as the links. The struct type
(without struct keyword) is given as the argument on this macro. The program
creates an anchor as simply an lvalue of type pointer to the node struct and
initializes it with one of the macros. The lvalue is passed to the macros
directly. If the program has a pointer to the anchor, it would dereference
that pointer in the macro argument expression.

Here is the latest. The tarball includes a couple of test programs which
do only very simple tests for now.

The tarball:
http://phil.ipal.org/pre-release/list-0.0.5.tar.bz2

Direct browsing:
http://phil.ipal.org/pre-release/list-0.0.5/

Licensing is currently GPL. I plan to switch to BSD and/or MIT or other
similar unencumbered licensing when it is in final release.

 

[Mug]

I have an implementation of linked lists coded entirely in macros, using
GNU C extensions __typeof__() and  statement expressions.  The flexibility
of this is that it allows creating your own node types and linking them
into a list very easily, without having to define type matched functions.
Type matching is done by making sure the anchor and node types do match.

This implementation creates a full circle doubly linked list in which the
last node links in the forward direction back to the first node, and also
first to last in the reverse direction.  The anchor consists of a single
pointer to the first node.

To create a linked list, the program defines a struct with one of the macros
as a member, which creates 2 members to serve as the links.  The struct type
(without struct keyword) is given as the argument on this macro.  The program
creates an anchor as simply an lvalue of type pointer to the node struct and
initializes it with one of the macros.  The lvalue is passed to the macros
directly.  If the program has a pointer to the anchor, it would dereference
that pointer in the macro argument expression.

Here is the latest.  The tarball includes a couple of test programs which
do only very simple tests for now.

The tarball:
   http://phil.ipal.org/pre-release/list-0.0.5.tar.bz2

Direct browsing:
   http://phil.ipal.org/pre-release/list-0.0.5/

Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
similar unencumbered licensing when it is in final release.

--

hello, it's very kind of your part to supply those convenient tool,
well i don't
know if you know it,the similar linked list macros have already been
implemented
since longtime. i have some applications use those stuffs ,you just
need to do #include<sys/queue.h>.
you can take a look at : http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/queue.h?rev=1.30
best regard
Mug

 

[Guest]

| On Jul 20, 9:40 pm, (e-mail address removed) wrote:
|> I have an implementation of linked lists coded entirely in macros, using
|> GNU C extensions __typeof__() and  statement expressions.  The flexibility
|> of this is that it allows creating your own node types and linking them
|> into a list very easily, without having to define type matched functions.
|> Type matching is done by making sure the anchor and node types do match.
|>
|> This implementation creates a full circle doubly linked list in which the
|> last node links in the forward direction back to the first node, and also
|> first to last in the reverse direction.  The anchor consists of a single
|> pointer to the first node.
|>
|> To create a linked list, the program defines a struct with one of the macros
|> as a member, which creates 2 members to serve as the links.  The struct type
|> (without struct keyword) is given as the argument on this macro.  The program
|> creates an anchor as simply an lvalue of type pointer to the node struct and
|> initializes it with one of the macros.  The lvalue is passed to the macros
|> directly.  If the program has a pointer to the anchor, it would dereference
|> that pointer in the macro argument expression.
|>
|> Here is the latest.  The tarball includes a couple of test programs which
|> do only very simple tests for now.
|>
|> The tarball:
|>    http://phil.ipal.org/pre-release/list-0.0.5.tar.bz2
|>
|> Direct browsing:
|>    http://phil.ipal.org/pre-release/list-0.0.5/
|>
|> Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
|> similar unencumbered licensing when it is in final release.
|>
|> --
|> -----------------------------------------------------------------------------
|> | Phil Howard KA9WGN       |http://linuxhomepage.com/     http://ham.org/|
|> | (first name) at ipal.net |http://phil.ipal.org/ http://ka9wgn.ham.org/|
|> -----------------------------------------------------------------------------
|
| hello, it's very kind of your part to supply those convenient tool,
| well i don't
| know if you know it,the similar linked list macros have already been
| implemented
| since longtime. i have some applications use those stuffs ,you just
| need to do #include<sys/queue.h>.
| you can take a look at : http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/queue.h?rev=1.30

Never heard of it before. Never seen it used in any code. All code by
others I've seen with linekd lists usually implemented something based on
custom functions. I have seen a library that is function based but was
very hard to use. This looks more complicated to deal with that mine
since it defines the struct instead of letting the calling program do it.
It also does (void*) casts in ways that defeat type checking. I'll stick
with my implementation.

 

[Guest]

| hello, it's very kind of your part to supply those convenient tool,
| well i don't
| know if you know it,the similar linked list macros have already been
| implemented
| since longtime. i have some applications use those stuffs ,you just
| need to do #include<sys/queue.h>.
| you can take a look at : http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/sys/queue.h?rev=1.30

Also, that implementation involves multiple evaluation of arguments.
That's a big show stopper for me. Even if I had known of them before,
I would still write my own to fix that glaring defect.

 

[Nick Keighley]

Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
similar unencumbered licensing when it is in final release.

just curious, why did you GPL it if your intent was to later release
it under BSD
(or similar)?

 

[Guest]

| On 20 July, 22:40, (e-mail address removed) wrote:
|
|> Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
|> similar unencumbered licensing when it is in final release.
|
| just curious, why did you GPL it if your intent was to later release
| it under BSD
| (or similar)?

I use GPL for alpha releases because this is when I want ideas for fixes to
come as feedback, and for the release itself to be limited in deployment.

Once it is "good enough" where I don't strive to get feedback on it, then I
consider that "release quality" and the BSD/MIT class licensing would apply.

Where the code might go that won't be providing feedback, I want it to wait
for the good stuff.

 

[Tom St Denis]

| On 20 July, 22:40, (e-mail address removed) wrote:
|
|> Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
|> similar unencumbered licensing when it is in final release.
|
| just curious, why did you GPL it if your intent was to later release
| it under BSD
| (or similar)?

I use GPL for alpha releases because this is when I want ideas for fixes to
come as feedback, and for the release itself to be limited in deployment.

Once it is "good enough" where I don't strive to get feedback on it, then I
consider that "release quality" and the BSD/MIT class licensing would apply.

Nothing in the GPL says that improvements have to make their way back
to you directly. If I take your code and use it inhouse and improve
it, I am absolutely not bound to distribute it to anyone, least of all
you.

If you want improvements to come back your way you're going to have to
say so in your license document.

Tom

 

[Lew Pitcher]

Nothing in the GPL says that improvements have to make their way back
to you directly. If I take your code and use it inhouse and improve
it, I am absolutely not bound to distribute it to anyone, least of all
you.

If you want improvements to come back your way you're going to have to
say so in your license document.

Indeed. But the OP will have to address more than that.

The copyright to any improvements so contributed would normally be held by
the contributer rather than the OP. This means that, if the OP accepts
those improvements, then he is obliged (at least, morally) to obtain the
contributer's agreement on any licence change for the contributed code.

In other words, unless the OP spells out in his original licence that
a) code changes should be returned to the OP, and
b) the copyright on the changes must be assigned to the OP
or something similar


--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[pdpi]

Indeed. But the OP will have to address more than that.

The copyright to any improvements so contributed would normally be held by
the contributer rather than the OP. This means that, if the OP accepts
those improvements, then he is obliged (at least, morally) to obtain the
contributer's agreement on any licence change for the contributed code.

In other words, unless the OP spells out in his original licence that
a) code changes should be returned to the OP, and
b) the copyright on the changes must be assigned to the OP
or something similar

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576http://pitcher.digitalfreehold.ca/  | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

To spell it out: Once you accept GPL contributions, you can't re-
license as BSD unless you get permission from the copyright holder.

 

[Guest]

| Indeed. But the OP will have to address more than that.
|
| The copyright to any improvements so contributed would normally be held by
| the contributer rather than the OP. This means that, if the OP accepts
| those improvements, then he is obliged (at least, morally) to obtain the
| contributer's agreement on any licence change for the contributed code.
|
| In other words, unless the OP spells out in his original licence that
| a) code changes should be returned to the OP, and
| b) the copyright on the changes must be assigned to the OP
| or something similar

Good point. I will reconsider. Suggest a license? Anything cleaner than
BSD or MIT?

 

[Nick Keighley]

Nothing in the GPL says that improvements have to make their way back
to you directly.  If I take your code and use it inhouse and improve
it, I am absolutely not bound to distribute it to anyone, least of all
you.

In fact, as I understand it, if I make an improvement to the code
and distribute it my only obligation is to make my source (and the
original
source) available to whoever I distibute it to. No obligation to the
original author.

 

[Guest]

|> On Jul 21, 11:25 am, (e-mail address removed) wrote:
|>
|> > | On 20 July, 22:40, (e-mail address removed) wrote:
|> > |
|> > |> Licensing is currently GPL.  I plan to switch to BSD and/or MIT or other
|> > |> similar unencumbered licensing when it is in final release.
|> > |
|> > | just curious, why did you GPL it if your intent was to later release
|> > | it under BSD
|> > | (or similar)?
|>
|> > I use GPL for alpha releases because this is when I want ideas for fixes to
|> > come as feedback, and for the release itself to be limited in deployment.
|>
|> > Once it is "good enough" where I don't strive to get feedback on it, then I
|> > consider that "release quality" and the BSD/MIT class licensing would apply.
|>
|> Nothing in the GPL says that improvements have to make their way back
|> to you directly.  If I take your code and use it inhouse and improve
|> it, I am absolutely not bound to distribute it to anyone, least of all
|> you.
|
| In fact, as I understand it, if I make an improvement to the code
| and distribute it my only obligation is to make my source (and the
| original
| source) available to whoever I distibute it to. No obligation to the
| original author.

Most people do make the code available public. They would likely do so if
they make the binary public. It's an encouragement. But you are right,
the obligation is limited as you say. I might like to change that, but it
might also backfire, so I will avoid.

 

[Guest]

| In article <[email protected]>, (e-mail address removed)
| wrote:
|> I use GPL for alpha releases because this is when I want ideas for fixes to
|> come as feedback, and for the release itself to be limited in deployment.
|>
|> Once it is "good enough" where I don't strive to get feedback on it, then I
|> consider that "release quality" and the BSD/MIT class licensing would apply.
|>
|> Where the code might go that won't be providing feedback, I want it to wait
|> for the good stuff.
|
| There's a problem here. You release the alpha under GPL. People who see
| that alpha and contribute code back are likely to contribute their code
| back under GPL--and then you can't relicense it under BSD without
| getting their explicit permission. You can only release under BSD the
| parts that you own the copyright on, not the parts that others have
| contributed back.

Right. That was pointed out earlier. So I will change the licensing.
The question I'm still trying to resolve is which one to go with. For
libraries and programming aid code, it will be one of the permissive
licenses, like BSD or MIT. I still haven't decided between those or one
of the others.

 

[Hamiral]

(e-mail address removed) a écrit :

Right. That was pointed out earlier. So I will change the licensing.
The question I'm still trying to resolve is which one to go with. For
libraries and programming aid code, it will be one of the permissive
licenses, like BSD or MIT. I still haven't decided between those or one
of the others.

What's wrong with GPL ? Or, maybe better suited, LGPL ?

Ham

 

[Keith Thompson]

On Fri, 24 Jul 2009 00:36:10 -0700 Tim Smith
| In article <[email protected]>, (e-mail address removed)
| wrote:
|> I use GPL for alpha releases because this is when I want ideas
|> for fixes to come as feedback, and for the release itself to be
|> limited in deployment.
|>
|> Once it is "good enough" where I don't strive to get feedback on
|> it, then I consider that "release quality" and the BSD/MIT class
|> licensing would apply.
|>
|> Where the code might go that won't be providing feedback, I want
|> it to wait for the good stuff.
|
| There's a problem here. You release the alpha under GPL. People who see
| that alpha and contribute code back are likely to contribute their code
| back under GPL--and then you can't relicense it under BSD without
| getting their explicit permission. You can only release under BSD the
| parts that you own the copyright on, not the parts that others have
| contributed back.

Right. That was pointed out earlier. So I will change the licensing.
The question I'm still trying to resolve is which one to go with. For
libraries and programming aid code, it will be one of the permissive
licenses, like BSD or MIT. I still haven't decided between those or one
of the others.

misc.int-property seems like a much better place to ask about that.

 

[Guest]

| (e-mail address removed) a écrit :
|> Right. That was pointed out earlier. So I will change the licensing.
|> The question I'm still trying to resolve is which one to go with. For
|> libraries and programming aid code, it will be one of the permissive
|> licenses, like BSD or MIT. I still haven't decided between those or one
|> of the others.
|>
|
| What's wrong with GPL ? Or, maybe better suited, LGPL ?

For the final version of my libraries, I do not care to encumber them with
a requirement that anything combined with them, whether it be a main program
that just links, or customization, be released in source form. I do not see
the LGPL as adequately permissive. I don't even care about the requirement
to be credited in any derived binary product, although I do want my notices
to remain present in any source code that is distributed, modified or not.
Even BSD seems to be more restrictive than I'd like (my my reading of it, it
requires this credit in all circumstances).

 

[Guest]

| (e-mail address removed) writes:
|> On Fri, 24 Jul 2009 00:36:10 -0700 Tim Smith
|> | In article <[email protected]>, (e-mail address removed)
|> | wrote:
|> |> I use GPL for alpha releases because this is when I want ideas
|> |> for fixes to come as feedback, and for the release itself to be
|> |> limited in deployment.
|> |>
|> |> Once it is "good enough" where I don't strive to get feedback on
|> |> it, then I consider that "release quality" and the BSD/MIT class
|> |> licensing would apply.
|> |>
|> |> Where the code might go that won't be providing feedback, I want
|> |> it to wait for the good stuff.
|> |
|> | There's a problem here. You release the alpha under GPL. People who see
|> | that alpha and contribute code back are likely to contribute their code
|> | back under GPL--and then you can't relicense it under BSD without
|> | getting their explicit permission. You can only release under BSD the
|> | parts that you own the copyright on, not the parts that others have
|> | contributed back.
|>
|> Right. That was pointed out earlier. So I will change the licensing.
|> The question I'm still trying to resolve is which one to go with. For
|> libraries and programming aid code, it will be one of the permissive
|> licenses, like BSD or MIT. I still haven't decided between those or one
|> of the others.
|
| misc.int-property seems like a much better place to ask about that.

I'd rather draw on the experiences of programmers, since this is more about
choosing a major existing license, instead of designing my own.

 

[Keith Thompson]

| (e-mail address removed) writes: [...]
|> Right. That was pointed out earlier. So I will change the licensing.
|> The question I'm still trying to resolve is which one to go with. For
|> libraries and programming aid code, it will be one of the permissive
|> licenses, like BSD or MIT. I still haven't decided between those or one
|> of the others.
|
| misc.int-property seems like a much better place to ask about that.

I'd rather draw on the experiences of programmers, since this is more about
choosing a major existing license, instead of designing my own.

Is there any particular reason to discuss it with C programmers?

comp.programming, or perhaps comp.misc, is a closer fit than comp.lang.c.

 

[Guest]

| (e-mail address removed) writes:
|> | (e-mail address removed) writes:
| [...]
|> |> Right. That was pointed out earlier. So I will change the licensing.
|> |> The question I'm still trying to resolve is which one to go with. For
|> |> libraries and programming aid code, it will be one of the permissive
|> |> licenses, like BSD or MIT. I still haven't decided between those or one
|> |> of the others.
|> |
|> | misc.int-property seems like a much better place to ask about that.
|>
|> I'd rather draw on the experiences of programmers, since this is more about
|> choosing a major existing license, instead of designing my own.
|
| Is there any particular reason to discuss it with C programmers?
|
| comp.programming, or perhaps comp.misc, is a closer fit than comp.lang.c.

The issue is now moot. I made a decision to use the OpenBSD license that
is based on the ISC license which is based on the BSD license. This is for
libraries and similar programming components.

 

[Hamiral]

(e-mail address removed) a écrit :

| (e-mail address removed) a écrit :
|> Right. That was pointed out earlier. So I will change the licensing.
|> The question I'm still trying to resolve is which one to go with. For
|> libraries and programming aid code, it will be one of the permissive
|> licenses, like BSD or MIT. I still haven't decided between those or one
|> of the others.
|>
|
| What's wrong with GPL ? Or, maybe better suited, LGPL ?

For the final version of my libraries, I do not care to encumber them with
a requirement that anything combined with them, whether it be a main program
that just links, or customization, be released in source form. I do not see
the LGPL as adequately permissive. I don't even care about the requirement
to be credited in any derived binary product, although I do want my notices
to remain present in any source code that is distributed, modified or not.
Even BSD seems to be more restrictive than I'd like (my my reading of it, it
requires this credit in all circumstances).

You're too kind
So why don't you write your own license ? As I understand you, it could
be something as simple as "This author grants the permission to anybody
to do anything with this piece of code, including but not limiting to
copying, modifying, distributing, getting patternity, etc."
I don't see why you spend so much energy in trying to find a license
that would fit your needs when you want to completely give your work away.

Ham