Determine the size of malloc

[Nick Keighley]

On 18 May 2008 at 21:40, Ian Collins wrote:

I suggest you check the group archives. One of the most severe critics
of CBF's ggets is Heathfield himself - is he a troll now?

I would also recommend the OP looks at Chuck's ggets().

If you insist on recommending clc-compliant ANSI-standard blah-di-blah,
rather than the solution provided by one's implementation [...]

but if you use the implementation provided one then you render the
system
unportable. Why would you want to do that?

<snip>

 

[Keith Thompson]

On 18 May 2008 at 21:40, Ian Collins wrote:
I suggest you check the group archives. One of the most severe critics
of CBF's ggets is Heathfield himself - is he a troll now?

I would also recommend the OP looks at Chuck's ggets().

If you insist on recommending clc-compliant ANSI-standard blah-di-blah,
rather than the solution provided by one's implementation [...]

but if you use the implementation provided one then you render the
system
unportable. Why would you want to do that?

<snip>

There are *sometimes* good reasons to use non-portable solutions. For
example, GNU getline() provides features that can't be provided in
portable standard C. (But none of those features, as far as I can
tell, are relevant to what the OP was asking.)

 

[Richard Tobin]

Can you name one that does?  So that I can avoid it.  I prefer
implementations that don't corrupt my data.

[/QUOTE]

I *think* DOS had a limit on the command line length.

Many operating systems impose a limit on the length of lines read from
the terminal, or at least the amount thety are willing to buffer
before the program reads it. That's not usually a problem: it's
normally a human typing it in, and they don't usually want such long
lines and can see the problem if it occurs. If I type an absurdly long
line in unix it eventually stops accepting characters, including
linefeed. It doesn't send a partial line with a linefeed added.

Imposing a limit on the length of lines read from files would be
much worse, especially if the system inserted a line break. Imagine
a computer-generated script that produced a very long command on one
line, which then gets truncated in the middle of one of the arguments:

very-long-deletion-command-that-ends-with-an-argument /home/richard/junk

I'm not going to be happy if it gets truncated and deletes
/home/richard instead of /home/richard/junk.

-- Richard

 

[Paul Hsieh]

Presumably you are referring to its apparent n^2 behaviour because of
its using a fixed increment when reallocating. With a good C library
implementation this will probably not be a problem, because realloc()
itself will use a better strategy, and most calls to it will be
no-ops.

Oh really? What strategy would you recommend that wouldn't cause most
people to balk at the idea that they cannot access all of memory? The
number one priority of a memory manager is to give access to as much
memory as possible to general C programs. If this is not the case,
then I have a hard time considering a given C compiler to be a true
system-level programming language.

It is the job of the base compiler to expose maximal functionality.
Performance should, to the greatest degree possible, be in the hands
of the programmer; the compiler should not try to out-smart the
developer. And the language design is *supposed* to (if its any good)
make sure the two things do not conflict.

 

[Harald van Dijk]

There are *sometimes* good reasons to use non-portable solutions. For
example, GNU getline() provides features that can't be provided in
portable standard C.

What does GNU getline do that can't be done in portable standard C? The
only thing I see is that it returns a non-standard type (it returns
ssize_t, which is a POSIX typedef for the signed type corresponding to
size_t), but I assume you're not talking about that. So what else is
there, that I am not seeing?

 

[Flash Gordon]

Keith Thompson wrote, On 19/05/08 17:38:

On 18 May 2008 at 21:40, Ian Collins wrote:
I suggest you check the group archives. One of the most severe critics
of CBF's ggets is Heathfield himself - is he a troll now?

I would also recommend the OP looks at Chuck's ggets().
If you insist on recommending clc-compliant ANSI-standard blah-di-blah,
rather than the solution provided by one's implementation [...]

but if you use the implementation provided one then you render the
system
unportable. Why would you want to do that?

<snip>

There are *sometimes* good reasons to use non-portable solutions. For
example, GNU getline() provides features that can't be provided in
portable standard C. (But none of those features, as far as I can
tell, are relevant to what the OP was asking.)

The only feature listed on the man page on the Linux notebook that
cannot be provided in standard C is setting errno to EINVAL if the
stream is not valid. Everything else specified by the man page here can
be implemented in standard C (i.e. resizing the buffer using realloc,
creating the buffer is *lineptr is null and updating the buffer size (to
which a pointer is provided), the pointer to the buffer (to which a
pointer is provided) and returning the number of characters read or -1
if a failure occurs).

 

[Paul Hsieh]

ggets is envisioned for primary use in interactive applications.

Oh. Does it do an isatty() call and reject anything that's piped in?

It will still function correctly when reading long lines from
files, but this is expected to be very rare. Most operators get
somewhat tired of typing after 250 to 500 input chars per line.

Yes, but I am unaware of any virus that tires from it. I have
webserver logs that definitely show the rather impressive typing
endurance of many incoming connecting agents. It seems that Apache
does not use a strategy similar to ggets(), otherwise my ISP would
probably be charging me for excessive CPU utilization.

 

[Paul Hsieh]

It would be absurd to rely on every program to individually prevent
this kind of attack.

Even if it costs almost nothing to do so?

http://www.pobox.com/~qed/userInput.html

[...] If your system is set up so that untrusted users
can send arbitrary data to programs not specially written to handle
it, you should make use of your operating system's facilities for
limiting process memory and cpu use.

Oh. So, you are saying C is a failure of a programming language that
cannot be relied upon to control the performance of its own
execution? Odd. I've spent much of my career demonstrating the exact
opposite.

Most OSes do not have a CPU utilization, or memory quota limiter.
I've also almost never seen an application that has any configuration
parameters with respect to these.

 

[Keith Thompson]

What does GNU getline do that can't be done in portable standard C? The
only thing I see is that it returns a non-standard type (it returns
ssize_t, which is a POSIX typedef for the signed type corresponding to
size_t), but I assume you're not talking about that. So what else is
there, that I am not seeing?

Sorry, I confused GNU getline() with GNU readline(), which offers some
sophisticated editing capabilities while reading the line.

 

[Antoninus Twink]

The only feature listed on the man page on the Linux notebook that
cannot be provided in standard C is setting errno to EINVAL if the
stream is not valid. Everything else specified by the man page here can
be implemented in standard C (i.e. resizing the buffer using realloc,
creating the buffer is *lineptr is null and updating the buffer size (to
which a pointer is provided), the pointer to the buffer (to which a
pointer is provided) and returning the number of characters read or -1
if a failure occurs).

Everything specified by strcpy can be implemented in standard C, but
most people prefer to use the version that's already sitting there in
the standard library. If your implementation provides a car, why not
jump in and drive off instead of stopping to rebuild the engine from
scrach first?

 

[Richard Tobin]

It would be absurd to rely on every program to individually prevent
this kind of attack.

[/QUOTE]

Even if it costs almost nothing to do so?

"This kind of problem" includes a lot more than just user input.
It includes, for example, the size of data structures built from
user input.

[...] If your system is set up so that untrusted users
can send arbitrary data to programs not specially written to handle
it, you should make use of your operating system's facilities for
limiting process memory and cpu use.

Oh. So, you are saying C is a failure of a programming language that
cannot be relied upon to control the performance of its own
execution?
No.

Most OSes do not have a CPU utilization, or memory quota limiter.

Get a better OS then. After all, isn't resource allocation one of
the canonical operating system functions?

I've also almost never seen an application that has any configuration
parameters with respect to these.

The configuration doesn't have be part of the application, it can be
done by whatever runs the application. In unix for example you can
use setrlimit() to set the limit, and then exec the program.

This has the advantage that the same program can be run with different
limits in different environments.

-- Richard

 

[Flash Gordon]

Antoninus Twink wrote, On 19/05/08 19:12:

Everything specified by strcpy can be implemented in standard C, but

and is provided by every conforming hosted implementation and quite a
few non-hosted implementations.

most people prefer to use the version that's already sitting there in
the standard library.

Well, we are talking here about a function which is non-standard and so
may well not be on all (or any) of the systems of interest.

If your implementation provides a car, why not
jump in and drive off instead of stopping to rebuild the engine from
scrach first?

Because it may well not be provided.

 

[Richard Tobin]

Presumably you are referring to its apparent n^2 behaviour because of
its using a fixed increment when reallocating. With a good C library
implementation this will probably not be a problem, because realloc()
itself will use a better strategy, and most calls to it will be
no-ops.

[/QUOTE]

Oh really? What strategy would you recommend that wouldn't cause most
people to balk at the idea that they cannot access all of memory? The
number one priority of a memory manager is to give access to as much
memory as possible to general C programs. If this is not the case,
then I have a hard time considering a given C compiler to be a true
system-level programming language.

In that case, I suggest you examine the operating systems you use.
You may well find that that you have unwittingly not been using a
"true system-level programming language".

-- Richard

 

[Paul Hsieh]

"This kind of problem" includes a lot more than just user input.
It includes, for example, the size of data structures built from
user input.

Yeah, that's why we take comp sci classes in school. So that we can
estimate the size of data structures relative to user input and
minimize them. The right answer is still to design your code
appropriately, not to use some OS dials to just cause your application
to become unresponsive or fail or something.

We could also ask the standards committee to make the std library more
helpful to us in this regard, but that's about effective as any other
kind of praying.

[...] If your system is set up so that untrusted users
can send arbitrary data to programs not specially written to handle
it, you should make use of your operating system's facilities for
limiting process memory and cpu use.

Oh. So, you are saying C is a failure of a programming language that
cannot be relied upon to control the performance of its own
execution?

No.

Well, then what is wrong with demanding that you write a C solution
that *DOES* take care of all that and more equally well on all
platforms with C compilers irrespective of OS behavior/features?

Get a better OS then. After all, isn't resource allocation one of
the canonical operating system functions?

Yes, but high performance reclamation and reuse is *NOT* a canonical
operation system function. What you are asking for is something that
can and should be delivered by good application design or the standard
library. What I demand from the OS, is that it deliver functionality
I request and absolutely nothing else. I always assume that any OS
call is at least as bad as writing to the disk.

The configuration doesn't have be part of the application, it can be
done by whatever runs the application. In unix for example you can
use setrlimit() to set the limit, and then exec the program.

Yeah, we got your point in the last post. *Some* OS has some kind of
application limitation control functions. Of course we don't know if
the iPhone OS, PalmOS or VxWorks has that or a similar call, now do
we? All because you are too lazy to implement a useful cautious,
conservative, yet powerful input mechanism even when the explanation
and source code is handed to you on a silver platter.

This has the advantage that the same program can be run with different
limits in different environments.

Right. The disadvantage is that its not portable and it will never be
portable.

 

[Paul Hsieh]

That's really an argument against C's lack of garbage collection.

for(i=0;i<100;i++)
{
objptr = createobject();
obj_foo(objptr);
killobject(objptr);

}

is pretty standard C idiom.

Indeed -- choosing good names like "create/destroy" or "alloc/free" or
"open/close" as part of the naming convention of anything that
allocates then deallocates resources is in fact a very standard C
idiom. That's a very fair and acceptable argument *against* including
strdup() into the C language standard library (stdupalloc or
strcpyalloc are obvious better naming choices.)

However, if you look closely I don't think that your complaint, nor
Richard's are incompatible.

 

[utilisateur de lcc-win32]

*Please* don't recommend this garbage to unsuspecting newbies who might
actually use it.

How exactly is it garbage? Even Jake Nav seems to think differently for
ggets() and fggets() have been part of lcc-win32's standard library
practically for ages.

Seeing as how lcc-win32 is closely watched and reviewed in this group,
if there really was a problem with ggets() somebody would have brought
it up by now? It seems to be widely used among lcc-win32 users.

 

[jacob navia]

utilisateur de lcc-win32 said:



I have done so on several occasions.


Are we talking about the same ggets()? I'm referring to Chuck Falconer's
function.

Chuck falconer 'ggets' is distributed with lcc-win.

 

[santosh]

Chuck falconer 'ggets' is distributed with lcc-win.

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

 

[Richard Tobin]

Chuck falconer 'ggets' is distributed with lcc-win.

[/QUOTE]

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

Just because something is "distributed with" something else doesn't
mean they have to have compatible licences. Gcc is distributed with
MacOS.

-- Richard

 

[santosh]

I suppose I'm overlooking something but won't there be license
incompatibility between Chuck's ggets and your lcc-win?

Just because something is "distributed with" something else doesn't
mean they have to have compatible licences. Gcc is distributed with
MacOS.[/QUOTE]

Okay. In which case I think jacob must distribute a copy of ggets
license along with his own license in the lcc-win distribution.

Strangely though I can't seem to find ggets anywhere in my lcc-win
installation. Perhaps jacob has modified the source file name?