The lcc-win string library

[jacob navia]

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

o features counted strings, that eliminates buffer overflows
o It has a syntax very similar to the old functions
(Strcat vs strcat, etc)
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

The source code for the whole library can be found in the
normal distribution of lcc-win.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Antoninus Twink]

On 3 Nov 2008 at 16:09, jacob navia wrote:

The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!

Is it released under the same license as the lcc-win compiler, or
something more permissive?

[Stephen Sprunk]

jacob navia wrote:

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.

IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler, rather than
trying to convince people that your extensions are or should be part of
C. There is a reason these features were _not_ backported from C++ to C
as many other "improvements" have been.

S

[jacob navia]

Antoninus Twink wrote:

On 3 Nov 2008 at 16:09, jacob navia wrote:

>The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!

Is it released under the same license as the lcc-win compiler, or
something more permissive?

It is public domain, no strings attached to the string library :-)

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Stephen Sprunk wrote:

jacob navia wrote:

>Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.

IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler, rather than
trying to convince people that your extensions are or should be part of
C. There is a reason these features were _not_ backported from C++ to C
as many other "improvements" have been.

S

There is a central difference.

C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.

I think C is a great language, that can evolve as all languages evolve
without becoming something else.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

jacob navia <ja***@nospam.comwrites:

Antoninus Twink wrote:

>On 3 Nov 2008 at 16:09, jacob navia wrote:

>>The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!
Is it released under the same license as the lcc-win compiler, or
something more permissive?

It is public domain, no strings attached to the string library :-)

Can it be used with any compiler other than lcc-win? If not, then,
though I applaud your decision to place it in the public domain, it
seems to me that, for most purposes, it's *effectively* under the same
restrictions as lcc-win.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[lawrence.jones]

jacob navia <ja***@nospam.comwrote:

>
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

I would expect Strlen to be quite a bit faster, too. :-)

Does it include I/O functions like sprintf, too?
--
Larry Jones

Whatever it is, it's driving me crazy! -- Calvin

[CBFalconer]

Keith Thompson wrote:

jacob navia <ja***@nospam.comwrites:

>Antoninus Twink wrote:

>>jacob navia wrote:

The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!
Is it released under the same license as the lcc-win compiler, or
something more permissive?

It is public domain, no strings attached to the string library :-)

Can it be used with any compiler other than lcc-win? If not, then,
though I applaud your decision to place it in the public domain, it
seems to me that, for most purposes, it's *effectively* under the
same restrictions as lcc-win.

I think you are over-criticizing here. If not compatible with
other systems, the PD source makes revision for compatibility quite
feasible. And Jacob has made the right overall classification with
"context of the lcc-win experimental compiler"

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Stephen Sprunk wrote:

jacob navia wrote:

>Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are
not C.

IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler,
rather than trying to convince people that your extensions are or
should be part of C. There is a reason these features were _not_
backported from C++ to C as many other "improvements" have been.

Note the "context of the lcc-win experimental compiler" phrase,
which adequately describes it. It is admittedly not a C compiler,
but can probably be revised into one at some future time. I would
really settle for this adequate description, rather than beating on
Jacob unnecessarily.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[jacob navia]

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

>o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

I would expect Strlen to be quite a bit faster, too. :-)

Does it include I/O functions like sprintf, too?

Well, not now. You have cast a String into a char *.

The overloaded cast operator will give back a pointer
to the actual contents of a String as a char *.

This is suboptimal, and I will hack the printf functions
later to accept some new marker for those strings, like
"%{S}"

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>jacob navia <ja***@nospam.comwrites:

>>Antoninus Twink wrote:
jacob navia wrote:

The source code for the whole library can be found in the normal
distribution of lcc-win.

Interesting!
Is it released under the same license as the lcc-win compiler, or
something more permissive?

It is public domain, no strings attached to the string library :-)

Can it be used with any compiler other than lcc-win? If not, then,
though I applaud your decision to place it in the public domain, it
seems to me that, for most purposes, it's *effectively* under the
same restrictions as lcc-win.

I think you are over-criticizing here. If not compatible with
other systems, the PD source makes revision for compatibility quite
feasible. And Jacob has made the right overall classification with
"context of the lcc-win experimental compiler"

Note the phrase "for most purposes". In any case, my comments were
meant more as an observation than a criticism; he was under no
obligation to place the code in the public domain in the first place,
and his decision to do so was generous.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris M. Thomasson]

"jacob navia" <ja***@nospam.comwrote in message
news:ge**********@aioe.org...

Stephen Sprunk wrote:

>jacob navia wrote:

>>Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.

IMHO, you would be better served simply adding the few remaining features
that are required to make lcc-win32 a C++ compiler, rather than trying to
convince people that your extensions are or should be part of C. There
is a reason these features were _not_ backported from C++ to C as many
other "improvements" have been.

S

There is a central difference.

C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.

I think C is a great language, that can evolve as all languages evolve
without becoming something else.

If one wants to create some OO API's in C, well, they most certainly can;
here is a simple example:
http://groups.google.com/group/comp....02fd4047cbbe1c
That is a very simple example of _minimalist_ implementation of abstract
interfaces in C. AFAICT, its pretty clean as well. I find this technique
works very well for plug-in frameworks... IMHO, C is extremely flexible
as-is.

[s0suk3]

On Nov 3, 6:07*pm, jacob navia <ja***@nospam.comwrote:

la************@siemens.com wrote:

jacob navia <ja***@nospam.comwrote:

o It could be faster for some operations like (precisely)
* *Strcat since there is no need to search for the terminating
* *zero.

I would expect Strlen to be quite a bit faster, too. *:-)

Does it include I/O functions like sprintf, too?

Well, not now. You have cast a String into a char *.

The overloaded cast operator will give back a pointer
to the actual contents of a String as a char *.

This is suboptimal, and I will hack the printf functions
later to accept some new marker for those strings, like
"%{S}"

I think that having an easy way to convert from the string type to a
null-terminated C-style string should be enough (and the cast fulfills
this purpose).

Maybe what Lawrence meant was if there were sprintf-like functions
that wrote to a StringA or a StringW, which eliminates the problem of
overflow (with, e.g., sprintf()) or truncation (with, e.g.,
snprintf()). For example, in a simple string library I once wrote,
there was a function like:

int StringAssignFormat(String str, const char *format, ...);

The function automatically allocated the space needed for the result
and then called vsnprintf() to do the formatting. CoreFundation's
(Apple) CFString has a similar functions, such as:
http://developer.apple.com/documenta...4-CH201-F11101

Sebastian

[Ian Collins]

jacob navia wrote:

Stephen Sprunk wrote:

>>
C does not have operator or function overloading. Quit spamming
comp.lang.c with advertisements for compiler features that are not C.

IMHO, you would be better served simply adding the few remaining
features that are required to make lcc-win32 a C++ compiler, rather
than trying to convince people that your extensions are or should be
part of C. There is a reason these features were _not_ backported
from C++ to C as many other "improvements" have been.

S

There is a central difference.

C is not object oriented, and the complexity and bloat that are
associated with that make it a much simpler language.

C++ doesn't have to be OO either.

A recent quote from James Kanze on c.l.c++:

"I believe it was Robert Martin that first pointed it out, but
the complexity is always there; it's inherit in the application.
In the case of C++, that complexity manifests itself in the
language; in the case of C, in the code we have to write to
solve the problem. Which means that in the case of C++, we have
to master it once, for all applications; in the case of C, we
have to master it for each application."

--
Ian Collins

[Richard Heathfield]

jacob navia said:

Within the context of the lcc-win experimental compiler
a complete str_ing library is available that uses operator
overloading and overloaded functions to present a new type
of string library in C, that

o features counted strings, that eliminates buffer overflows
o It has a syntax very similar to the old functions
(Strcat vs strcat, etc)
o It could be faster for some operations like (precisely)
Strcat since there is no need to search for the terminating
zero.

The source code for the whole library can be found in the
normal distribution of lcc-win.

The "normal distribution of lcc-win" would appear to be a Win32 executable
file. Presumably the intent is that only Win32 users should be able to
take part in this experiment - and even then, only if they are prepared to
trust an arbitrary program to execute on their system.

I qualify on the first count (because there's a Win32 machine kicking
around the place here somewhere, I'm sure), but not the second.

From the description you give, however, it seems that what you've done is
(a) implemented your own string library, which is fine, we've all done
that, and (b) rendered it non-portable by making it rely on implementation
extensions. In other words, people using your library to any great extent
are, by so doing, locking themselves in to your implementation.

Presumably this is not accidental.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Antoninus Twink]

On 3 Nov 2008 at 23:01, CBFalconer wrote:

Note the "context of the lcc-win experimental compiler" phrase, which
adequately describes it. It is admittedly not a C compiler, but can
probably be revised into one at some future time. I would really
settle for this adequate description, rather than beating on Jacob
unnecessarily.

You really have issues Falconer.

It's the oldest trick in the book: "*I* am not a bully - no, *I* would
never be like those other people who beat up on Jacob". And at the very
same moment you're sliding the knife into his back with your ridiculous
"not a C compiler" nonsense.

CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

[Antoninus Twink]

On 4 Nov 2008 at 5:40, Richard Heathfield wrote:

The "normal distribution of lcc-win" would appear to be a Win32
executable file. Presumably the intent is that only Win32 users should
be able to take part in this experiment - and even then, only if they
are prepared to trust an arbitrary program to execute on their system.

What, haven't you heard of Wine then Heathfield?

[Keith Thompson]

Antoninus Twink <no****@nospam.invalidwrites:
[...]

CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

I'm quoting this just in case anyone still thought Antoninus Twink was
anything more than a waste of bandwidth. Publicly wishing for
someone's death is despicable, and this is not the first time he's
done it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Antoninus Twink]

On 4 Nov 2008 at 19:43, Keith Thompson wrote:

Antoninus Twink <no****@nospam.invalidwrites:

>CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

I'm quoting this just in case anyone still thought Antoninus Twink was
anything more than a waste of bandwidth. Publicly wishing for
someone's death is despicable, and this is not the first time he's
done it.

You're the pedant Keith - read the words and you'll find I didn't wish
for CBF's death, I just pointed out that Usenet will be a better place
when it happens.

You can't deny that CBF's old age has spilled over into senility, and
this is partly responsible for his grumpiness, his inability to
comprehend what he reads, his poor attention span, etc., all of which
make his "contributions" to this group nothing more than sources of
frustration for everyone - even those who take his side in the group's
"topicality" politics, Heathfield being a prime example.

[lawrence.jones]

s0****@gmail.com wrote:

>
I think that having an easy way to convert from the string type to a
null-terminated C-style string should be enough (and the cast fulfills
this purpose).

That's OK for printf arguments, but not for the sprintf result or scanf
arguments since it subverts the "no buffer overflows" the string type is
supposed to provide.
--
Larry Jones

What this games needs are negotiated settlements. -- Calvin

[CBFalconer]

s0****@gmail.com wrote:

jacob navia <ja***@nospam.comwrote:

.... snip ...

>

>This is suboptimal, and I will hack the printf functions later
to accept some new marker for those strings, like "%{S}"

I think that having an easy way to convert from the string type
to a null-terminated C-style string should be enough (and the
cast fulfills this purpose).

There is a major problem here. There is no such thing as a "string
type" in C. There is only a data format for use in a char array.
This consists of characters, extended and terminated by a '\0'
char. That char marks the end of the active string.

No cast will so alter the char array, and there is no guarantee
that there is even room to append the '\0' termination marker.
Remember that, in accurate C, a cast is usually an error. The
prime exception is variadic parameters.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Keith Thompson wrote:

Antoninus Twink <no****@nospam.invalidwrites:

[...]

>CBF - 84 years old, and hopefully any day now Usenet will have
the blessed relief of the end of his presence on earth.

I'm quoting this just in case anyone still thought Antoninus
Twink was anything more than a waste of bandwidth. Publicly
wishing for someone's death is despicable, and this is not the
first time he's done it.

Not only that, but his faulty facts make it obvious that his
statements are purely the product of his faulty imagination.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

s0****@gmail.com wrote:

>jacob navia <ja***@nospam.comwrote:

... snip ...

>>

>>This is suboptimal, and I will hack the printf functions later
to accept some new marker for those strings, like "%{S}"

I think that having an easy way to convert from the string type
to a null-terminated C-style string should be enough (and the
cast fulfills this purpose).

There is a major problem here. There is no such thing as a "string
type" in C. There is only a data format for use in a char array.
This consists of characters, extended and terminated by a '\0'
char. That char marks the end of the active string.

I think you've missed (or are deliberately ignoring) the context.
jacob announced a string library; a "string" here is presumably some
type specific to the package, not a "string" in the sense defined in
the C standard. I.e., it's something that represents or contains a
sequence of characters. <OT>C++'s std::string is an example of
this.</OT>

No cast will so alter the char array, and there is no guarantee
that there is even room to append the '\0' termination marker.
Remember that, in accurate C, a cast is usually an error. The
prime exception is variadic parameters.

Sure, but lcc-win, on which this string library depends, supports
operator overloading. Apparently the cast operator is overloaded so
that (char*)s invokes a function that returns a char* value that
points to a valid C string, given that s is an object of the "string"
type provided by the library.

Complain that this is off-topic if you like, but pretending,
deliberately or otherwise, that jacob means the same thing the
standard does when he talks about a "string library" is not helpful.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Antoninus Twink wrote:

On 4 Nov 2008 at 5:40, Richard Heathfield wrote:

>The "normal distribution of lcc-win" would appear to be a Win32
executable file. Presumably the intent is that only Win32 users should
be able to take part in this experiment - and even then, only if they
are prepared to trust an arbitrary program to execute on their system.

What, haven't you heard of Wine then Heathfield?

Then, a compiler is an arbitrary program that executes in your
computer... For instance a thing called 'gcc.exe' starts suspicius
other programs called 'cc1.exe' and what have you :-)

At least, lcc.exe doesn't start any other program behind
your back. The preprocessor is integrated, together
with the assembler.
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

la************@siemens.com wrote:

s0****@gmail.com wrote:

>I think that having an easy way to convert from the string type to a
null-terminated C-style string should be enough (and the cast fulfills
this purpose).

That's OK for printf arguments, but not for the sprintf result or scanf
arguments since it subverts the "no buffer overflows" the string type is
supposed to provide.

Yes, that is an issue. I have to provide
Sprintf, that would return a newly allocated string.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Antoninus Twink wrote:

CBF - 84 years old, and hopefully any day now Usenet will have the
blessed relief of the end of his presence on earth.

Please, that was too much.

We will all die, sooner or later. Even if Chuck doesn't like me,
I do respect him and do not wish him any harm.

Let's keep cool Antoninus.

Thanks.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yahoo.comwrites:

>s0****@gmail.com wrote:

>>jacob navia <ja***@nospam.comwrote:

... snip ...

>>>
This is suboptimal, and I will hack the printf functions later
to accept some new marker for those strings, like "%{S}"

I think that having an easy way to convert from the string type
to a null-terminated C-style string should be enough (and the
cast fulfills this purpose).

There is a major problem here. There is no such thing as a
"string type" in C. There is only a data format for use in a
char array. This consists of characters, extended and terminated
by a '\0' char. That char marks the end of the active string.

I think you've missed (or are deliberately ignoring) the context.
jacob announced a string library; a "string" here is presumably
some type specific to the package, not a "string" in the sense
defined in the C standard. I.e., it's something that represents
or contains a sequence of characters. <OT>C++'s std::string is
an example of this.</OT>

Missed. I only looked at the message I quoted, I specifically did
NOT look back to investigate the general subject of the thread.
This only emphasizes that such non-topical discussion do not belong
here, especially when the comp.compilers.lcc group is available for
on-topic discussion.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Keith Thompson wrote:

>CBFalconer <cb********@yahoo.comwrites:

>>s0****@gmail.com wrote:
jacob navia <ja***@nospam.comwrote:

... snip ...

This is suboptimal, and I will hack the printf functions later
to accept some new marker for those strings, like "%{S}"

I think that having an easy way to convert from the string type
to a null-terminated C-style string should be enough (and the
cast fulfills this purpose).

There is a major problem here. There is no such thing as a
"string type" in C. There is only a data format for use in a
char array. This consists of characters, extended and terminated
by a '\0' char. That char marks the end of the active string.

I think you've missed (or are deliberately ignoring) the context.
jacob announced a string library; a "string" here is presumably
some type specific to the package, not a "string" in the sense
defined in the C standard. I.e., it's something that represents
or contains a sequence of characters. <OT>C++'s std::string is
an example of this.</OT>

Missed. I only looked at the message I quoted, I specifically did
NOT look back to investigate the general subject of the thread.
This only emphasizes that such non-topical discussion do not belong
here, especially when the comp.compilers.lcc group is available for
on-topic discussion.

The fact that jacob was talking about converting "from the string type
o a null-terminated C-style string", plus the subject header "The
lcc-win string library", should have been more than enough of a clue,
don't you think? All that information was in the message you quoted.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

CBFalconer said:

<snip>

I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest you revise it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

jacob navia said:

Antoninus Twink wrote:

>On 4 Nov 2008 at 5:40, Richard Heathfield wrote:

>>The "normal distribution of lcc-win" would appear to be a Win32
executable file. Presumably the intent is that only Win32 users should
be able to take part in this experiment - and even then, only if they
are prepared to trust an arbitrary program to execute on their system.

What, haven't you heard of Wine then Heathfield?

Then, a compiler is an arbitrary program that executes in your
computer... For instance a thing called 'gcc.exe' starts suspicius
other programs called 'cc1.exe' and what have you :-)

$ find / -name gcc.exe
$

So much for that.

More to the point, not only are gcc's sources available (so that, at least
in principle, I can inspect the sources to convince myself that there is
no harmful code therein), but also gcc has a sufficiently large user base
that, if it did contain harmful code, the news would be out by now.
Furthermore, I know - from many discussions in this group - your contempt
for correctness, so I have no confidence that your code will do what you
claim.

At least, lcc.exe doesn't start any other program behind
your back. The preprocessor is integrated, together
with the assembler.

How utterly irrelevant.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

<snip>

>I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest you
revise it.

No, it doesn't. It may embarrass the writer of the replied to item.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Richard Heathfield wrote:

jacob navia said:

.... snip ...

>

>At least, lcc.exe doesn't start any other program behind your
back. The preprocessor is integrated, together with the
assembler.

How utterly irrelevant.

Not really. It indicates the extent of intertwining and thus
(probably) unnecessary complication, and thus the (likely) presence
of associated undetected bugs.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Richard Heathfield wrote:

>jacob navia said:

... snip ...

>>

>>At least, lcc.exe doesn't start any other program behind your
back. The preprocessor is integrated, together with the
assembler.

How utterly irrelevant.

Not really. It indicates the extent of intertwining and thus
(probably) unnecessary complication, and thus the (likely) presence
of associated undetected bugs.

It's utterly irrelevant to the point being discussed. Since you
apparently haven't bothered to read anything but the most recent
followup, I'm not sure how you can determine whether it's relevant or not.

Here's the context. The lcc-win string library has been released to
the public domain, but apparently it's only available as part of the
lcc-win distribution. The installer is a Windows executable, which
means that people who either don't have Windows (or, yes, Wine under
Linux) or who don't choose to trust the executable are going to have
difficulty obtaining the sources.

Unless, of course, jacob or someone else makes them available in some
other form. The library still won't work with anything other than
lcc-win, but at least people could study it if they were so inclined.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Harter]

On Wed, 05 Nov 2008 10:54:52 -0500, CBFalconer
<cb********@yahoo.comwrote:

>Richard Heathfield wrote:

>CBFalconer said:

<snip>

>>I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest you
revise it.

No, it doesn't. It may embarrass the writer of the replied to item.

You're quie right; these sort of gaffes don't embarrass you.
They should, but they don't.
Richard Harter, cr*@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

<snip>

>>I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest you
revise it.

No, it doesn't. It may embarrass the writer of the replied to item.

How does your ignorance of context embarrass anyone but you?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Phil Carmody]

Richard Heathfield <rj*@see.sig.invalidwrites:

jacob navia said:

>Antoninus Twink wrote:

>>On 4 Nov 2008 at 5:40, Richard Heathfield wrote:
The "normal distribution of lcc-win" would appear to be a Win32
executable file. Presumably the intent is that only Win32 users should
be able to take part in this experiment - and even then, only if they
are prepared to trust an arbitrary program to execute on their system.

What, haven't you heard of Wine then Heathfield?

Then, a compiler is an arbitrary program that executes in your
computer... For instance a thing called 'gcc.exe' starts suspicius
other programs called 'cc1.exe' and what have you :-)

$ find / -name gcc.exe
$

So much for that.

More to the point, not only are gcc's sources available (so that, at least
in principle, I can inspect the sources to convince myself that there is
no harmful code therein)

You appear to be overlooking Thompson's ACM Turing award presentation.

However, I'm guessing that you trust the source you get your
GCC from, and you don't trust the source that you might get
an lcc-win from, and therefore you trust GCC and not lcc-win.

Phil
--
We must respect the other fellow's religion, but only in the sense and to the
extent that we respect his theory that his wife is beautiful and his children
smart. -- Henry Louis Mencken (1880-1956), American editor and critic

[Richard Heathfield]

Phil Carmody said:

Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>More to the point, not only are gcc's sources available (so that, at
least in principle, I can inspect the sources to convince myself that
there is no harmful code therein)

You appear to be overlooking Thompson's ACM Turing award presentation.

That's a fair point.

However, I'm guessing that you trust the source you get your
GCC from, and you don't trust the source that you might get
an lcc-win from, and therefore you trust GCC and not lcc-win.

And that's another.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Richard Heathfield wrote:

>>CBFalconer said:

<snip>

I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest
you revise it.

No, it doesn't. It may embarrass the writer of the replied to
item.

How does your ignorance of context embarrass anyone but you?

When the original author is too ignorant to realize that Usenet
does not guarantee any deliveries, and that all messages should
stand by themselves, he (or she) only embarrass themselves by
failing to effectively quote. Similarly failure to adequately
snip. Note that such ignorance is not usually fatal, and can be
corrected by heeded advice.

<http://www.catb.org/~esr/faqs/smart-questions.html>
<http://www.caliburn.nl/topposting.html>
<http://www.netmeister.org/news/learn2quote.html>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

Richard Heathfield wrote:

>CBFalconer said:

>>Richard Heathfield wrote:
CBFalconer said:

<snip>

I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest
you revise it.

No, it doesn't. It may embarrass the writer of the replied to
item.

How does your ignorance of context embarrass anyone but you?

When the original author is too ignorant to realize that Usenet
does not guarantee any deliveries, and that all messages should
stand by themselves, he (or she) only embarrass themselves by
failing to effectively quote. Similarly failure to adequately
snip. Note that such ignorance is not usually fatal, and can be
corrected by heeded advice.

Chuck, there was more than enough information *in the article you
replied to* to make it perfectly obvious that jacob wasn't talking
about "strings" as defined by C99 7.1.1p1, and you replied as if that
were the only thing he could possibly have meant.

Here's the context that you quoted yourself:

| s0****@gmail.com wrote:
| jacob navia <ja***@nospam.comwrote:
| >
| ... snip ...
| >
| >This is suboptimal, and I will hack the printf functions later
| >to accept some new marker for those strings, like "%{S}"
| >
| I think that having an easy way to convert from the string type
| to a null-terminated C-style string should be enough (and the
| cast fulfills this purpose).

Just what did you think converting from "the string type" to "a
null-terminated C-style string" meant, in an article with the subject
"The lcc-win string library"?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

>>Richard Heathfield wrote:
CBFalconer said:

<snip>

I only looked at the message I quoted,

That's a poor strategy that often embarrasses you. I suggest
you revise it.

No, it doesn't. It may embarrass the writer of the replied to
item.

How does your ignorance of context embarrass anyone but you?

When the original author is too ignorant to realize that Usenet
does not guarantee any deliveries, and that all messages should
stand by themselves,

The best repliers make a trade-off between the risk of delivery failure
(which is real but slight) and the stupidity of quoting the entire
conversation to date. Most people get the right balance, by quoting enough
of the previous article to give context to their reply, without quoting
the whole darn thing. You give such people two choices:

- accommodate you by changing their posting behaviour so as to quote every
line of every article they reply to, every time (thus massively increasing
the amount of time taken to download and read their articles, which is
most unfair on those people still on dial-up, as well as being downright
idiotic); or
- recognise that Chuck's being an idiot *again*, and laugh at, shrug at,
or weep for you, as befits their character.

he (or she) only embarrass themselves by
failing to effectively quote.

The quoting was effective. As Keith has pointed out, everything you needed
for a less stupid reply was right there in the article to which you
replied. What's more, the excuse of delivery failure is a thin one. Yes,
it's possible and it happens, just like the postal service sometimes fails
to deliver important letters. But, just like the postal service's failure
to deliver, a Usenet article delivery failure is actually quite rare, and
to rely on it as an excuse for being dense is itself far from bright.

Similarly failure to adequately snip.

Ha! So you try to get them both ways: if they dare to snip properly, you
misunderstand them AND blame them when your misunderstanding is exposed,
and if they fail to snip properly, you jump on them for a netiquette
violation. Furrfu, Chuck - you need to wake up, smell some coffee, and get
a grip on reality.

Note that such ignorance is not usually fatal, and can be
corrected by heeded advice.

Your advice is impossible to heed (which is just as well).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Tobin]

In article <49***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>How does your ignorance of context embarrass anyone but you?

>When the original author is too ignorant to realize that Usenet
does not guarantee any deliveries, and that all messages should
stand by themselves, he (or she) only embarrass themselves by
failing to effectively quote.

And yet it's only *you* who regularly posts absurd articles because
of failing to consider the context. If everyone else can deal with
it, why can't you?

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[CBFalconer]

Keith Thompson wrote:

>

.... snip ...

>
Chuck, there was more than enough information *in the article you
replied to* to make it perfectly obvious that jacob wasn't talking
about "strings" as defined by C99 7.1.1p1, and you replied as if
that were the only thing he could possibly have meant.

Here's the context that you quoted yourself:

.... snip ...

| >
| I think that having an easy way to convert from the string
| type to a null-terminated C-style string should be enough (and
| the cast fulfills this purpose).

Just what did you think converting from "the string type" to "a
null-terminated C-style string" meant, in an article with the
subject "The lcc-win string library"?

Well, I guess I probably went off too fast. The idea of casting
strings set me off.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[Richard Heathfield]

CBFalconer said:

Keith Thompson wrote:

>>

<snip>

>>
Just what did you think converting from "the string type" to "a
null-terminated C-style string" meant, in an article with the
subject "The lcc-win string library"?

Well, I guess I probably went off too fast.

FINALLY!

The idea of casting strings set me off.

In future, it would be a good idea to read before posting. And, on
occasions where you fail to do that, it would be a good idea to treat
responses from people whose opinion you respect (presumably you *do*
respect Keith Thompson's opinion, for example?) a good deal more seriously
than you managed on this occasion.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999