On the development of C

[CBFalconer]

The resulting pointer may not be properly aligned for all types so
it is not a plug-in replacement for malloc and may cause undefined
behaviour if it is used as one.

True. Of course, I am not really recommending implementing it, and
I see no cure for that problem that is truly portable. How to make
a universally acceptable pointer is known to the implementation,
but not to the user.

 

[user923005]

Phil Carmody said:



Bug report...

For those that don't get the joke:

entomology
1766, from Fr. entomologie (1764), coined from Gk. entomon "insect" +
logia "study of." Entomon is neut. of entomos "having a notch or cut
(at the waist)," so called by Aristotle in reference to the segmented
division of insect bodies, from en- "in" + temnein "to cut." Compare
insect.

etymology
1398, from Gk. etymologia, from etymon "true sense" (neut. of etymos
"true," related to eteos "true") + logos "word." In classical times,
of meanings; later, of histories. Latinized by Cicero as veriloquium.

 

[user923005]

Richard Bos wrote:

...


I can't see any way of interpreting that as a true statement.
Ignorance is a lack of knowledge, malice is ill will; I don't see any
way for a lack of knowledge to somehow transmute into ill-will. Lack
of knowledge can cause ill-will, and vice versa, but that doesn't seem
to be what you're saying, and it certainly doesn't fit the context.

He is speaking of intentional ignorance (refusing to learn).

 

[Dik T. Winter]

> Dik T. Winter wrote: ....

> > In what way do you disagree with what I wrote (except that it is not
> > formulated too well)?

>
> What you wrote is true: Restricting a program's privileges
> restricts the amount of damage it can do. My point is that the
> potential damage remains non-zero[*] and can in fact be very great.
> The argument that gets() is "safe enough as long as a privileged
> program doesn't use it" is bogus.

In my opinion it is not, but I think we will remain disagreeing.

 

[Kojak]

Le Thu, 12 Mar 2009 23:05:02 +0000,
Richard Heathfield a écrit :

Phil Carmody said:

Bug report...

While reading, I was wondering if entomology has a different
meaning from my language. You'd answered. Thank you.

I guess he meant etymology.

 

[Richard Bos]

Richard Bos wrote:
...

I can't see any way of interpreting that as a true statement.
Ignorance is a lack of knowledge, malice is ill will; I don't see any
way for a lack of knowledge to somehow transmute into ill-will. Lack
of knowledge can cause ill-will, and vice versa, but that doesn't seem
to be what you're saying, and it certainly doesn't fit the context.

Let me, in quoting a more native and venerable author, phrase it a bit
more clearly, then:

Ignorance, when it is voluntary, is criminal; and he may properly be
charged with evil who refused to learn how he might prevent it.

-- Samuel Johnson, The History of Rasselas,
Prince of Abissinia, chapter XXIX

Richard

 

[Phil Carmody]

I'll take that on. Let us assume the unlimited input data has been
captured in 'badfile.txt'.

If we do that, we fail, so we don't do that. If you're going to
make unwarranted assumptions to make it easier, why not just
assume the maximum line length is 80 characters?

Phil

 

[CBFalconer]

If we do that, we fail, so we don't do that. If you're going to
make unwarranted assumptions to make it easier, why not just
assume the maximum line length is 80 characters?

How can you say that? Are you denying that we can capture the
'bad' input in a textfile?

 

[Chris M. Thomasson]

MPFR can be accomodated with the GC. The gc is an incredibly powerful
solution for really BIG numbers like lcc-win's bignums that can contain an
unlimited number of 32 bit integers.

You just create objects and leave the hard work of freeing them to the
GC!

Just defer cleaning up the very nasty mess your program makes to the good
ol' reliable Mommy; GC is "convenient" indeed.


If you lack the skills to put away your toys, well, IMVHO, your not allowed
to take any out of the box!


LOL!





Anyway, I am jesting of course because GC _is_ a convenient tool indeed! I
like the fact that your compiler provides it as an option. BTW, can you
think of an algorithm which requires GC? I can think of a class of them that
"kind-of" requires it in a sense, but not totally...

 

[Phil Carmody]

How can you say that? Are you denying that we can capture the
'bad' input in a textfile?

Given that I've worked on systems that only stream data and
don't even have a filesystem in which to store said text
file - yes. Don't get confused by the typename.

Phil

 

[Richard Bos]

The statement from Phil being disputed is whether it's *possible* to write
code that calls gets() and doesn't introduce a buffer overrun.

A call to gets() is defined in terms of the stdin stream, not a terminal
device, so if stdin is associated with a regular file, that's an edge
case worth considering. There have been no objections in this thread to
considering edge cases, and it's customary on this newsgroup to be
thorough in considering edge cases. In past discussions of gets(),
it's been common to talk about environments in which you have control
of the data fed to gets(). All I've done is narrow that environment
down to the program itself.

Aha, but you've missed another edge case yourself, and rather an
important one. Who guarantees - _without_ using OS control functions
outside the purview of the Standard - that the file you've written isn't
changed behind your back? You're guaranteed* that objects inside your
program don't change unless you change them yourself, or they're
volatile. You are given no such guarantee about files.

Richard

* In the sense that, this guarantee _can_ be broken, but then the
implementation is no longer conforming, which is the most any Standard
not backed by law can state

 

[Richard Bos]

Let's say the return from such a function is NULL for a value not part of
any malloc memory, such as addresses of static and frame data.

The gets() implementation which gets a non-NULL value from alloc_size can
then test against the limit (I had in mind the address of the end of the
allocated block), and prevent buffer overflows.

If it gets a NULL value, then it can work as before. So gets() would be safe
only when used with allocated memory.

So instead of a function which is simply unsafe and of which sane people
need say no more than "don't use it", you want to replace it by a
function which _may_ be safe under _some_ circumstances, but which is
guaranteed to trick newbies into using it as if it were safe with every
input? And you think this is _safer_?

*Brrrrr*

Richard

 

[Richard Bos]

I think you will find that the implementation of ggets()

And I think _you_ will find that nobody likes a spammer, regardless of
whether that spammer is called jacob navia, EventHelix, or CBFalconer.

Richard

 

[Richard Tobin]

A call to gets() is defined in terms of the stdin stream, not a terminal
device, so if stdin is associated with a regular file, that's an edge
case worth considering. There have been no objections in this thread to
considering edge cases, and it's customary on this newsgroup to be
thorough in considering edge cases. In past discussions of gets(),
it's been common to talk about environments in which you have control
of the data fed to gets(). All I've done is narrow that environment
down to the program itself.

[/QUOTE]

Aha, but you've missed another edge case yourself, and rather an
important one. Who guarantees - _without_ using OS control functions
outside the purview of the Standard - that the file you've written isn't
changed behind your back? You're guaranteed* that objects inside your
program don't change unless you change them yourself, or they're
volatile. You are given no such guarantee about files.

Who guarantees that someone won't run a debugger on your program and
change the value of a variable, so that *any* code becomes unsafe?
Any assessment of safe and unsafe depends on the environment in which
the code is run.

-- Richard

 

[Keith Thompson]

To be a spammer, you have to be posting unsolicited commercial
material.

[...]

<OT>
In my opinion, any reasonable definition of "spam" is independent of
whether the material is commercial. There are widely accepted
definitions of what the term "spam" means in the context of Usenet;
google "Breidbart index".

There are certainly levels of repeated posting of the same material
(commercial or not) that are inappropriate without qualifying as
"spam". In my opinion, CBF's recommendations of his own software do
not approach such levels.
</OT>

 

[CBFalconer]

.... snip ...

Aha, but you've missed another edge case yourself, and rather an
important one. Who guarantees - _without_ using OS control
functions outside the purview of the Standard - that the file
you've written isn't changed behind your back? You're guaranteed*
that objects inside your program don't change unless you change
them yourself, or they're volatile. You are given no such
guarantee about files.

Most systems will guarantee that access if you open the file for
read/write, and don't close it. You can rewind it. Assuming the
file is rewindable.

 

[CBFalconer]

And I think _you_ will find that nobody likes a spammer,
regardless of whether that spammer is called jacob navia,
EventHelix, or CBFalconer.

I don't know if this is you or a nymshifter, but it is pure
trolling. For the benefit of all, ggets is written in purely
standard C, has no known bugs, and is released to the public
domain.

 

[Kaz Kylheku]

I don't know if this is you or a nymshifter, but it is pure
trolling. For the benefit of all, ggets is written in purely
standard C, has no known bugs, and is released to the public
domain.

No bugs known to /you/. I just played spot-the-error and found one coding bug
and several design issues, one of which is that this function has an interface
which is a bad idea regardless of how it is implemented.

 

[Tony]

I don't think you can make truly generic C data structures and
algorithms in C the same as C++ because C lacks templates.

You can get most of the functionality of C++ templates via the C
preprocessor.

Tony

 

[user923005]

You can get most of the functionality of C++ templates via the C
preprocessor.

Indeed, I used that trick in "C Unleashed" in chapter 13.
By defining a data type, a new sort routine specific to that data type
is created (types with _P2_ in their name are 'pointer to' types):

ALLSORT.H ( 56): #if defined(E_TYPE_UNSIGNED_INT)
ALLSORT.H ( 58): #elif defined(E_TYPE_SIGNED_INT)
ALLSORT.H ( 60): #elif defined(E_TYPE_UNSIGNED_LONG)
ALLSORT.H ( 62): #elif defined(E_TYPE_SIGNED_LONG)
ALLSORT.H ( 64): #elif defined(E_TYPE_UNSIGNED_CHAR)
ALLSORT.H ( 66): #elif defined(E_TYPE_SIGNED_CHAR)
ALLSORT.H ( 68): #elif defined(E_TYPE_UNSIGNED_LONG_LONG)
ALLSORT.H ( 70): #elif defined(E_TYPE_SIGNED_LONG_LONG)
ALLSORT.H ( 72): #elif defined(E_TYPE_FLOAT)
ALLSORT.H ( 74): #elif defined(E_TYPE_DOUBLE)
ALLSORT.H ( 76): #elif defined(E_TYPE_LONG_DOUBLE)
ALLSORT.H ( 78): #elif defined(E_TYPE_P2_UNSIGNED_INT)
ALLSORT.H ( 80): #elif defined(E_TYPE_P2_SIGNED_INT)
ALLSORT.H ( 82): #elif defined(E_TYPE_P2_UNSIGNED_LONG)
ALLSORT.H ( 84): #elif defined(E_TYPE_P2_SIGNED_LONG)
ALLSORT.H ( 86): #elif defined(E_TYPE_P2_UNSIGNED_CHAR)
ALLSORT.H ( 88): #elif defined(E_TYPE_P2_SIGNED_CHAR)
ALLSORT.H ( 90): #elif defined(E_TYPE_P2_UNSIGNED_LONG_LONG)
ALLSORT.H ( 92): #elif defined(E_TYPE_P2_SIGNED_LONG_LONG)
ALLSORT.H ( 94): #elif defined(E_TYPE_P2_FLOAT)
ALLSORT.H ( 96): #elif defined(E_TYPE_P2_DOUBLE)
ALLSORT.H ( 98): #elif defined(E_TYPE_P2_LONG_DOUBLE)
ALLSORT.H ( 100): #elif defined(E_TYPE_STRING)
ALLSORT.H ( 102): #elif defined(E_TYPE_COLLATED_STRING)
ALLSORT.H ( 107): #endif /* defined(E_TYPE_... */

However, it is a very poor substitute for templates.