a struct parser

[Weiguang Shi]

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Thank you.
Wei

[Bill Pursell]

Weiguang Shi wrote:

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

I think it's called a compiler. I really don't mean that
sarcastically,
but I'm not sure you're explaining your question thoroughly. For
reading, it sounds like you want something like:

#include <stdio.h>
#define NUM_FOO 50

struct foo {
int a;
char b;
unsigned int c;
};

int
main(void)
{
struct foo f[NUM_FOO];

while ( fread (f, sizeof *f, NUM_FOO, stdin) == NUM_FOO) {
int i;
for (i=0; i< NUM_FOO; i++)
printf("a = %d, b = %c, c = %u\n",
f[i].a, f[i].b, f[i].c);
}
return ferror(stdin);
}

You'll need to be careful if your input stream was created
by a different compiler, which may have aligned the fields of the
structure differently.
~

[Weiguang Shi]

Thanks for the feedback and a program to put things in perspective.

What I want is to do manually only

struct foo {
int a;
char b;
unsigned int c;
};

And I want a command to ``create'' binary foo's out of this, too.

I'm just hopelessly lazy ;-)

Wei

[void * clvrmnky()]

Weiguang Shi wrote:

Thanks for the feedback and a program to put things in perspective.

What I want is to do manually only

struct foo {
int a;
char b;
unsigned int c;
};

And I want a command to ``create'' binary foo's out of this, too.

I'm just hopelessly lazy ;-)

Who are you talking to? Quote some context when replying.

[Ian Collins]

Weiguang Shi wrote:

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

You are looking for something to serialise your struct, which isn't
something built in to C. You will have to roll your own.

--
Ian Collins.

[Robert Gamble]

Weiguang Shi wrote:

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Since the exact representation of types in C is implementation defined,
as opposed some certain other languages, you cannot just write out the
binary representation and expect to be able to read it back in on
another machine (or even with another compiler). You can either use a
textual representaion as your storage medium, which isn't completely
portable either, or you can convert the data to a predefined binary
format that is not dependent on the actual machine representation of
the data.

Robert Gamble

[jacob navia]

Weiguang Shi a écrit :

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Thank you.
Wei

Hi Mr Wei.

I can give you that... for a price. It will read a structure definition
in c and output a read/write program for it.

How much are you ready to pay for it?

jacob

[Eric Sosman]

jacob navia wrote On 05/09/06 17:26,:

Weiguang Shi a écrit :

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Thank you.
Wei

Hi Mr Wei.

I can give you that... for a price. It will read a structure definition
in c and output a read/write program for it.

How much are you ready to pay for it?

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

--
Er*********@sun.com

[Richard Tobin]

In article <4c*************@individual.net>,
Ian Collins <ia******@hotmail.com> wrote:

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Unless someone else has already done so, which is what the OP was asking
about.

-- Richard

[websnarf]

Richard Tobin wrote:

Ian Collins <ia******@hotmail.com> wrote:

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Unless someone else has already done so, which is what the OP was asking
about.

No, in C you can't have a well defined way of serializing structs in
general.

The problem, is most clearly illustrated with any char * entry. If
some header parser/serializer sees that there is a char * field in a
struct, what should it assume that it means? Is that a pointer to one
character, or is it a pointer to a NUL terminated string? Is the
underlying buffer assumed to be of some certain length (which cannot
even be hinted at in the declaration, except by a comment or something
lame like that)?

In fact that the underlying buffer for the char * may be characterized
by another field in the struct (like it is for a bstring for example.)
I.e., some other field may in fact describe the length of the usable
buffer in which a NUL terminated string is placed -- this information
need not be stored in the serialized form, however, how would a
serializing tool know to do this?

And of course none of this speaks to how you are supposed to fill in a
struct which contains a union as a sub-field. Usually *which* entry of
the union is used is indicated by a state derivable from the other
fields (if its not just one of the fields itself.)

This is why things like CORBA, COM, and IDLs in general exist.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Haude Daniel]

In article <sl******************@nestow.cs.ualberta.ca>, Weiguang Shi wrote:

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

I've written a program that, if given a struct definition (in a simple, non-C
format) will create the corresponding C struct definition as well as functions
to parse and write textual representations of the values of the struct members
as key/value pairs. Essentially I wanted a 1:1 correspondence between a
configuration/paramater text file and a struct inside the program.

This is actually a pretty nifty code generator that I want to publish some
day. However, at the moment it is not in a publishable condition and I have
no time to work on it at the moment. Since I know that many fans of C code
generators are hanging out in this group I'll post a notice when it is
finished. Of course I don't have to mention that both the code generator and
the generated code are pure, unblemished ISO C90.

--Daniel

[Richard Tobin]

In article <11*********************@i40g2000cwc.googlegroups. com>,
<we******@gmail.com> wrote:

No, in C you can't have a well defined way of serializing structs in
general.

The problem, is most clearly illustrated with any char * entry. If
some header parser/serializer sees that there is a char * field in a
struct, what should it assume that it means? Is that a pointer to one
character, or is it a pointer to a NUL terminated string? Is the
underlying buffer assumed to be of some certain length (which cannot
even be hinted at in the declaration, except by a comment or something
lame like that)?

Obviously there can't be a completely general tool for generating
serializer and deserializers from struct declarations unaided. But
that doesn't mean that there can't be useful tools, even if you
consider some of the obvious annotation mechanisms "lame".

-- Richard

[Weiguang Shi]

In article <11*********************@i40g2000cwc.googlegroups. com>,
we******@gmail.com wrote:

No, in C you can't have a well defined way of serializing structs in
general.

The problem, is most clearly illustrated with any char * entry. If
some header parser/serializer sees that there is a char * field in a
struct, what should it assume that it means? Is that a pointer to one
character, or is it a pointer to a NUL terminated string? Is the
underlying buffer assumed to be of some certain length (which cannot
even be hinted at in the declaration, except by a comment or something
lame like that)?

I can accept some comments. Actually, it might be useful to hint to
the parser what option it should generate for each entry.

[Weiguang Shi]

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

Thanks. But how did you magically intercepted his email to me? Did you
get my reply to him, too?

Wei

[Weiguang Shi]

In article <sl********************@alpha40.physnet.uni-hamburg.de>,
Haude Daniel wrote:

I've written a program that, if given a struct definition (in a simple, non-C
format) will create the corresponding C struct definition as well as functions
to parse and write textual representations of the values of the struct members
as key/value pairs. Essentially I wanted a 1:1 correspondence between a
configuration/paramater text file and a struct inside the program. I think it makes sense to enforce rules by using a "spec" language.

This is actually a pretty nifty code generator that I want to publish some
day. However, at the moment it is not in a publishable condition and I have
no time to work on it at the moment. Since I know that many fans of C code
generators are hanging out in this group I'll post a notice when it is
finished. Of course I don't have to mention that both the code generator and
the generated code are pure, unblemished ISO C90.

--Daniel

When will the tool go public? Will you be willing to share the code
now?

Wei

[jacob navia]

Weiguang Shi a écrit :

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

Thanks. But how did you magically intercepted his email to me? Did you
get my reply to him, too?

Wei

I did a mistake and posted "answer" to the group instead of "answer to
the sender only". I retired (cancelled ) the message one second after
it appeared, but Mr Sosman, that is very busy following my messages
intercepted it, and immediately started a polemic, since he is not very
busy (or apparently has nothing better to do).

I think there is no point in going further with the polemic.

I had started an adaptation of the lcc-win32 compiler for generating
code that would write and read a structure in a compiler independent way
from/to disk.

A problem were the embedded pointers within the structures, and whether
to follow them or not. I vaguely remember talking in this group about
this, and that a first version that followed the inner pointers in a
recursive way was criticized here. I started modifying it, but then I
was engaged by other customers in other stuff and that stayed unfinished
till now.

So, when I saw Mr Wei's message I remembered that and tried to sell him
that development.

That is all.

[Walter Roberson]

In article <44***********************@news.wanadoo.fr>,
jacob navia <ja***@jacob.remcomp.fr> wrote:

I did a mistake and posted "answer" to the group instead of "answer to
the sender only". I retired (cancelled ) the message one second after
it appeared, but Mr Sosman, that is very busy following my messages
intercepted it, and immediately started a polemic, since he is not very
busy (or apparently has nothing better to do).

Many systems do not accept 'cancel' messages, or only accept
cancel messages digitally signed by a limited number of trusted
spam-fighting organizations.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Flash Gordon]

jacob navia wrote:

Weiguang Shi a écrit :

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.
Thanks. But how did you magically intercepted his email to me? Did you
get my reply to him, too?

Wei

I did a mistake and posted "answer" to the group instead of "answer to
the sender only". I retired (cancelled ) the message one second after
it appeared, but Mr Sosman, that is very busy following my messages
intercepted it,

I'm sure he is busy. I'm also sure that you know that cancels rarely
work because most servers ignore them. So it is not very surprising that
Eric saw your message. For the record, I also saw it and my system polls
for messages hourly.
and immediately started a polemic, since he is not very
busy (or apparently has nothing better to do).

I think there is no point in going further with the polemic.
<snip>
So, when I saw Mr Wei's message I remembered that and tried to sell him
that development.

That is all.

Eric's point was completely valid. Unless Weiguang is prepared to be
tied to the compiler and system of *your* choice he should specify that
it be implemented in standard C. As a SW developer you should have no
problem with specifications being complete, in fact you should encourage
this!
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

[Martin Ambuhl]

Weiguang Shi wrote:

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

Thanks. But how did you magically intercepted his email to me? Did you
get my reply to him, too?

No one intercepted an email, and it required no magic.
His message <44***********************@news.wanadoo.fr>
was posted to comp.lang.c at 09 May 2006 23:26:46 CEST.
It is openly available to all.

[Ben Pfaff]

dh****@alpha40.physnet.uni-hamburg.de (Haude Daniel) writes:

I've written a program that, if given a struct definition (in a
simple, non-C format) will create the corresponding C struct
definition as well as functions to parse and write textual
representations of the values of the struct members as
key/value pairs. Essentially I wanted a 1:1 correspondence
between a configuration/paramater text file and a struct inside
the program.

This sounds like an interface definition language. In what ways
is it superior to existing IDLs such as XDR, which is defined by
an RFC and for which exist multiple compatible implementations?
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[CBFalconer]

Martin Ambuhl wrote:

Weiguang Shi wrote:

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

Thanks. But how did you magically intercepted his email to me?
Did you get my reply to him, too?

No one intercepted an email, and it required no magic.
His message <44***********************@news.wanadoo.fr>
was posted to comp.lang.c at 09 May 2006 23:26:46 CEST.
It is openly available to all.

Most of us would strongly echo Eric Sosmans warning. M. Navia is
well known for using non-standard constructs and creating
non-portable systems. As Richard Heathfield has pointed out, he
has seriously damaged his reputation here.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.fr> writes:

Weiguang Shi a écrit :

In article <1147212523.945236@news1nwk>, Eric Sosman wrote:

Warning to Mr. Wei:

If you hire Mr. Navia, be sure to specify that the
implementation language (both of the tool itself and of
the code it generates) must be "ISO Standard C." Accept
no substitutes.

Thanks. But how did you magically intercepted his email to me? Did
you
get my reply to him, too?
Wei

I did a mistake and posted "answer" to the group instead of "answer to
the sender only". I retired (cancelled ) the message one second after
it appeared, but Mr Sosman, that is very busy following my messages
intercepted it, and immediately started a polemic, since he is not
very busy (or apparently has nothing better to do).

Cancels very frequently don't work. Your message appeared on the
newsgroup, with no indication that it wasn't intended to be public,
and therefore available for public comment. (And Mr. Sosman's point
was a valid one.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[qed]

Weiguang Shi wrote:

we******@gmail.com wrote:

No, in C you can't have a well defined way of serializing structs
in general.

The problem, is most clearly illustrated with any char * entry.
If some header parser/serializer sees that there is a char * field
in a struct, what should it assume that it means? Is that a
pointer to one character, or is it a pointer to a NUL terminated
string? Is the underlying buffer assumed to be of some certain
length (which cannot even be hinted at in the declaration, except
by a comment or something lame like that)?

I can accept some comments. Actually, it might be useful to hint to
the parser what option it should generate for each entry.

Well, ok, how would we do this? This is off the top of my head:

struct something1 {
int slen;
char last[1 /* @:len=$.slen */ ]; /* struct hack. */
};

struct something2 {
int qty;
typename * ptr /* @:len=$.qty */; /* variable length ptr. */
};

struct something3 {
typename * ptr /* @:len=1 */; /* Just a pointer. */
};

struct something4 {
char * ptr /* @:len=strlen($.ptr)+1 */; /* A C string. */
};

So presumably you would do a text substitution of $ with the current
structure variable name in you autogenerated (un)marshalling code. And
@:len would tell you the count of this field.

struct something5 {
enum kind { k_W1, k_W2 } which;
union {
typename1 field1;
typename2 field2;
} x /* @:union(field1:$$.which==k_W1)
@:union(field2:$$.which==k_W2) */ ;
};

So $$ would pop above the current structure (in this case a union) to
the containing structure, and you determine which of the union fields is
valid by looking at the which field in the structure above it. A little
annoying to parse it all out, but doable.

So for serializing a bstring (http://bstring.sf.net/) we would need
something like:

struct tagbstring {
int mlen /* @:unmarshall=$.slen+1 */;
int slen;
unsigned char * data /* @:len=slen+1 */;
};

So this extra field @:unmarshall gives an expression for overriding the
value that is generated when it is unpacked (because it is defined by
the memory size, which is instance dependent.)

It would be interesting to see if this could be made into something
truly general and thus make things like CORBA and COM obselete. Being
able to automarshall directly from a .h file would be extremely
valuable, IMHO. But as we can see just from these few examples, what
started as a simple idea (the @:len= ... idea) has needed some twisted
extensions (@:unmarshall, @union, and $$ macros) to make it general to
real world scenarios.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Flash Gordon]

qed wrote:

Weiguang Shi wrote:

we******@gmail.com wrote:

> No, in C you can't have a well defined way of serializing structs
> > in general.
>
> The problem, is most clearly illustrated with any char * entry.
> > If some header parser/serializer sees that there is a char * field
> > in a struct, what should it assume that it means? Is that a
> > pointer to one character, or is it a pointer to a NUL terminated
> > string? Is the underlying buffer assumed to be of some certain
> length (which cannot even be hinted at in the declaration, except
> > by a comment or something lame like that)?
I can accept some comments. Actually, it might be useful to hint to
the parser what option it should generate for each entry.

Well, ok, how would we do this? This is off the top of my head:

struct something1 {
int slen;
char last[1 /* @:len=$.slen */ ]; /* struct hack. */
};

struct something2 {
int qty;
typename * ptr /* @:len=$.qty */; /* variable length ptr. */
};

struct something3 {
typename * ptr /* @:len=1 */; /* Just a pointer. */
};

struct something4 {
char * ptr /* @:len=strlen($.ptr)+1 */; /* A C string. */
};

For a string I would be inclined to just have something telling the
parser it is a string.
So presumably you would do a text substitution of $ with the current
structure variable name in you autogenerated (un)marshalling code. And
@:len would tell you the count of this field.

struct something5 {
enum kind { k_W1, k_W2 } which;
union {
typename1 field1;
typename2 field2;
} x /* @:union(field1:$$.which==k_W1)
@:union(field2:$$.which==k_W2) */ ;
};

So $$ would pop above the current structure (in this case a union) to
the containing structure, and you determine which of the union fields is
valid by looking at the which field in the structure above it. A little
annoying to parse it all out, but doable.
Now you need a mechanism for dealing with void* pointers. For example, a
linked list library that uses a pointer to void to point to the data so
you can put anything you like there. One option of course is to just
have the parser report it as being unserialisable.

Also how are you going to deal with pointers to pointers etc.
So for serializing a bstring (http://bstring.sf.net/) we would need
something like:

struct tagbstring {
int mlen /* @:unmarshall=$.slen+1 */;
int slen;
unsigned char * data /* @:len=slen+1 */;
};

So this extra field @:unmarshall gives an expression for overriding the
value that is generated when it is unpacked (because it is defined by
the memory size, which is instance dependent.)

It would be interesting to see if this could be made into something
truly general and thus make things like CORBA and COM obselete. Being
able to automarshall directly from a .h file would be extremely
valuable, IMHO. But as we can see just from these few examples, what
started as a simple idea (the @:len= ... idea) has needed some twisted
extensions (@:unmarshall, @union, and $$ macros) to make it general to
real world scenarios.

I can certainly see use for it. So much so that I have something similar
(written some months back) for converting some data structures used as
internal representation of database records in to XML and back.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc

Inviato da X-Privat.Org - Registrazione gratuita http://www.x-privat.org/join.php

[Haude Daniel]

In article <87************@benpfaff.org>, Ben Pfaff wrote:

This sounds like an interface definition language. In what ways
is it superior to existing IDLs such as XDR, which is defined by
an RFC and for which exist multiple compatible implementations?

It is superior in several ways:

- It was fun to write
- I have never heard of XDR
- $ apt-cache search xdr
librpc-ocaml-dev - Ocaml Sun RPC libraries
xdrawchem - an open-source version of ChemDraw
$

--Daniel

[Haude Daniel]

In article <sl******************@nestow.cs.ualberta.ca>, Weiguang Shi wrote:

When will the tool go public?
When I have tested it some more and when I have finished the documentation.
Will you be willing to share the code now?

No, sorry. It is not self-explanatory and I don't like to give away unfinished,
undocumented and untested code. You might be better off by looking at the
stuff Ben Pfaff recommended which doesn't suffer from these shortcomings
(otherwise he probably wouldn't have recommended it).

--Daniel

[Ben Pfaff]

dh****@alpha40.physnet.uni-hamburg.de (Haude Daniel) writes:

In article <87************@benpfaff.org>, Ben Pfaff wrote:

This sounds like an interface definition language. In what ways
is it superior to existing IDLs such as XDR, which is defined by
an RFC and for which exist multiple compatible implementations?
It is superior in several ways:

- It was fun to write

Well, that's always worthwhile. It's always reasonable to write
code to figure out for yourself how it should be done.
- I have never heard of XDR
I'm not sure that "I didn't bother to look into the related work"
is a good reason to do something.
- $ apt-cache search xdr

It doesn't show up under apt-cache because it's built into glibc.
It's also built into the Linux kernel, for that matter, if you
compile in NFS support.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Rod Pemberton]

"Weiguang Shi" <wg***@nestow.cs.ualberta.ca> wrote in message
news:slrne61jbk.cmk.wg***@nestow.cs.ualberta.ca...

Hi,

Is there a tool that, given a struct definition, generates a function
that parses binary data of this struct and a command that can be used
to construct binary data according to user-specified values for the
fields of this struct?

Your question reminds me of a record editor for a database. I programmed
one of those a number of years ago in PL/1. I ended up using a number of
tools to do the job. The final output had a single line for each piece of
data in the structure which contained the name of the data, type of data,
offset from the start of the structure, etc. I used a flex grammar to parse
the PL/1 data structure into a clean format. I then used PL/1 program which
read the clean format and structure definition to output the size and
offsets of the data. This created a generic "map" for the record. This
generic map could then be loaded into the record editing program.

You should be able to do something similar in C with the help of a flex
grammar. I would start by looking sizeof() and offsetof().
Rod Pemberton

[Friedrich Dominicus]

CBFalconer <cb********@yahoo.com> writes:

Most of us would strongly echo Eric Sosmans warning. M. Navia is
well known for using non-standard constructs and creating
non-portable systems. As Richard Heathfield has pointed out, he
has seriously damaged his reputation here.

Oh, I didn't know that you are the speaker of comp.lang.c.

Nice to learn

Friedrich
--
Please remove just-for-news- to reply via e-mail.

[Keith Thompson]

Friedrich Dominicus <ju*****************@q-software-solutions.de> writes:

CBFalconer <cb********@yahoo.com> writes:

Most of us would strongly echo Eric Sosmans warning. M. Navia is
well known for using non-standard constructs and creating
non-portable systems. As Richard Heathfield has pointed out, he
has seriously damaged his reputation here.

Oh, I didn't know that you are the speaker of comp.lang.c.

Nice to learn

No, he's one of many speakers here, who is as entitled to his opinion
(which I happen to share) as anyone else.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.

[Herbert Rosenau]

On Sun, 14 May 2006 07:34:19 UTC, Friedrich Dominicus
<ju*****************@q-software-solutions.de> wrote:

CBFalconer <cb********@yahoo.com> writes:

Most of us would strongly echo Eric Sosmans warning. M. Navia is
well known for using non-standard constructs and creating
non-portable systems. As Richard Heathfield has pointed out, he
has seriously damaged his reputation here. Oh, I didn't know that you are the speaker of comp.lang.c.

No, he is not THE speaker of clc but one of the most respected
regulars.
Nice to learn

True, you can learn many thing from him. And yes, M. Navia has reduced
his reputation to less than zero already.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!

[Eric Sosman]

Herbert Rosenau wrote:

On Sun, 14 May 2006 07:34:19 UTC, Friedrich Dominicus
<ju*****************@q-software-solutions.de> wrote:

CBFalconer <cb********@yahoo.com> writes:

Most of us would strongly echo Eric Sosmans warning. M. Navia is
well known for using non-standard constructs and creating
non-portable systems. As Richard Heathfield has pointed out, he
has seriously damaged his reputation here.

Oh, I didn't know that you are the speaker of comp.lang.c.

No, he is not THE speaker of clc but one of the most respected
regulars.

Nice to learn

True, you can learn many thing from him. And yes, M. Navia has reduced
his reputation to less than zero already.

I don't think that's defensible. Mr. Navia is a hard
worker with considerable knowledge and a desire to help. His
failing ("the mote in thy neighbor's eye ...") is an inability
to distinguish C from non-C -- hence, my warning. I'm fairly
confident that Mr. Navia can write C if properly motivated.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Herbert Rosenau]

On Mon, 15 May 2006 12:43:39 UTC, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:

True, you can learn many thing from him. And yes, M. Navia has reduced
his reputation to less than zero already.

I don't think that's defensible. Mr. Navia is a hard
worker with considerable knowledge and a desire to help. His
failing ("the mote in thy neighbor's eye ...") is an inability
to distinguish C from non-C -- hence, my warning. I'm fairly
confident that Mr. Navia can write C if properly motivated.

I've seen enough from him here to never trust any bit of C he has
written in practice.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2 Deutsch ist da!