twitter: comp.lang.c - 25 new messages in 10 topics

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

==============================================================================
TOPIC: defining after execution
http://groups.google.com/group/comp.lang.c/t/cf09c5fc559d6a56?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 10:36 am
From: Tim Rentsch

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> frank <frank@example.invalid> writes:
>>Has it always been legal C that you can define (I hope I got that verb
>>correct) targetName so? What happens if this snippet is executed serially?
>
> Yes.
>
>>correct) targetName so? What happens if this snippet is executed serially?
>
> In C, one can not execute snippets at all, only statements.

If you read section 6.12 of the latest draft (N1425), you
will see that C1X allows execution of snippets in
addition to statements.

==============================================================================
TOPIC: Variable argument list passed to another function. Where to put va_end?
http://groups.google.com/group/comp.lang.c/t/dc3211bfac343fb0?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 10:40 am
From: Tim Rentsch

Kaz Kylheku <kkylheku@gmail.com> writes:

> On 2010-02-02, DSF <notavalid@address.here> wrote:
>> Hello,
>>
>> While working on a couple of functions that take a variable argument
>> list, I discovered they were almost completely identical, except for
>> one line of code. What a great situation for splitting off the common
>> code to a common function.
>>
>> Now I know that va_start must be in the function that receives the
>> variable number of arguments, but must va_end be there as well?
>
> The 1999 ISO C standard says, in section 7.15.1, that ``Each invocation of the
> va_start or va_copy macros shall be matched by a corresponding invocation of
> the va_end macro in the same function.''
>
> Moreover ``The va_end macro facilitates a normal return from the function ...''.
>
> If you have va_start in a function, you can't make a tail call to the common
> function, since you haven't used va_end to facilitate a normal return.

That's true. But it's easy enough to put the tail call one
function down, and everything's copacetic. As a general
rule functions that use va_start/va_end should be written
as simple wrappers, calling an inner function that does
the real work.

==============================================================================
TOPIC: Warning to newbies
http://groups.google.com/group/comp.lang.c/t/9597fd702985dff4?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 4 2010 11:07 am
From: Charlton Wilbur

>>>>> "NK" == Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

NK> reasonable thing to do. Though if your requirement notation was
NK> rich enough to describe your problem you could argue you'd
NK> already written a program...

I think this is the core of the problem of software proofs.

When you have a sufficiently detailed spec, you can prove that the
software behaves correctly according to that spec.

This just shifts the problem from writing the program to writing the
spec; and when users complain "It doesn't do what it's supposed to!"
they rarely care whether the problem is in the code or in the spec.

Charlton

--
Charlton Wilbur
cwilbur@chromatico.net

== 2 of 2 ==
Date: Thurs, Feb 4 2010 1:32 pm
From: raltbos@xs4all.nl (Richard Bos)

"osmium" <r124c4u102@comcast.net> wrote:

> You seem to think Reagan had no verbal abilities. You DO realize he got
> elected, do you not?

Yeah - not having small nuts.

Richard

==============================================================================
TOPIC: What is on topic here
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 4 2010 11:33 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <kfnock4ylfj.fsf@x-alumni2.alumni.caltech.edu>, Tim Rentsch <txr@alumni.caltech.edu> writes:
> lacos@ludens.elte.hu (Ersek, Laszlo) writes:
>
>> In article <slrnhlrvqr.d0j.usenet-nospam@guild.seebs.net>, Seebs <usenet-nospam@seebs.net> writes:
>>
>>> The big win for me has been compound literals, actually. I love them.
>>> Very handy, very idiomatic.
>>
>> C99 6.5.2.5 "Compound literals", paragraph 10:
>>
>> ----v----
>> EXAMPLE 2 [...] in
>> void f(void)
>> {
>> int *p;
>> /*...*/
>> p = (int [2]){*p};
>> /*...*/
>> }
>>
>> p is assigned the address of the first element of an array of two ints,
>> the first having the value previously pointed to by p and the second,
>> zero. [...]
>> ----^----
>>
>> Is the assignment correct because the end of an initializer is a
>> sequence point? (C99 6.5.2.5p7 and Annex C.) "p" is written to once and
>> read once, and the new value of "p" is not based on the previous value
>> of "p".
>
> But the old value of p is read _to determine_ the new value of
> p. The fragment above is analogous to 'p = p->next', both
> of which are legal.

(Since I only code in C90, I have no working experience with compound
literals, so I apologize for any possibly upcoming stupidity on my
part.)

If I understand correctly, the expression statement above does the
following:
- defines an unnamed array object with automatic storage duration,
- initializes it to { *p, 0 },
- assigns its address to p.

I don't see how the contents of an array can necessarily influence its
address (= placement in memory). Consider the following expression
statements in place of the assignment above:

p = (int [2]){9};
p = (int [2]){i};

If an implementation is permitted by the standard to place the int[2]
array object on the stack at the same address independently from the
array's contents, then the new value of p doesn't depend on *p, and
hence the previous value of p either.

Thank you,
lacos

== 2 of 2 ==
Date: Thurs, Feb 4 2010 1:52 pm
From: Antoninus Twink

On 4 Feb 2010 at 16:28, Keith Thompson wrote:
> What make you think arguing with spinoza1111 will ever generate
> anything but more noise?

Just out of interest Keith, do you consider this post of yours quoted
above to be noise?

==============================================================================
TOPIC: Void questions
http://groups.google.com/group/comp.lang.c/t/f2845347004d9486?hl=en
==============================================================================

== 1 of 5 ==
Date: Thurs, Feb 4 2010 11:48 am
From: Tim Rentsch

Francis Moreau <francis.moro@gmail.com> writes:

> The last question is about the section 6.2.5.26 which states: "A
> pointer to void shall have the same representation and alignment
> requirements as a pointer to a character type.". I'm not sure to
> understand why the spec speaks about alignement requierements since a
> pointer to void cannot be dereferenced.

Note that alignment requirements mentioned here are for
the actual _pointers_, not for what's being pointed to.
A (char*) variable and a (void*) variable have the same
alignment requirement (which is unrelated to the alignment
of (char)).

== 2 of 5 ==
Date: Thurs, Feb 4 2010 12:10 pm
From: Tim Rentsch

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 2/2/2010 4:34 AM, Francis Moreau wrote:
>> Hello,
>>
>> I have some stupids questions about void type and pointer to void.
>>
>> Actually I've always known the answers but I wanted to find the
>> revelant parts in the C specs and fails.
>>
>> The first one is about dereferencing a void pointer. It's just
>> forbidden but when reading 6.5.3.2 about indirection operators, I
>> can't find anything that states it.
>
> 6.5.3.2p4 specifies what happens when dereferencing a
> pointer "to a function" or "to an object." A void* obviously
> can't do the first. What you're probably missing is that it
> also can't do the second, because of 6.2.5p1: "[...] Types are
> partitioned into object types [...], function types [...], and
> incomplete types [...]" A void* is a pointer to an incomplete
> type, not a pointer to an object type, so the language of
> 6.5.3.2p4 doesn't apply.

I believe this interpretation is a misreading. The Standard means
what it says, if the pointer "points to an object" is talking about
where the pointer points, not what type of pointer it is. And this
is there to rule out null pointers, which don't point to an object.
Pointers to incomplete types (and that aren't null pointers, or
point one past the end of an array) still point to objects.

Why then is it undefined behavior? Pray read on...

> The outcome of a dereference is
> undefined not because the Standard says so explicitly, but
> because it doesn't say anything to define it (see 4p2).

Indirecting through a pointer to an incomplete type (not just (void))
is undefined behavior because 6.3.2.1p2 says so explicitly:

Except when it is the operand of the sizeof operator, the unary
& operator, the ++ operator, the -- operator, or the left
operand of the . operator or an assignment operator, an lvalue
that does not have array type is converted to the value stored
in the designated object (and is no longer an lvalue). If the
lvalue has qualified type, the value has the unqualified version
of the type of the lvalue; otherwise, the value has the type of
the lvalue. If the lvalue has an incomplete type and does not
have array type, the behavior is undefined.

== 3 of 5 ==
Date: Thurs, Feb 4 2010 12:13 pm
From: Tim Rentsch

Richard Heathfield <rjh@see.sig.invalid> writes:

> Nick wrote:
>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>
>>> Ben Bacarisse wrote:
>>>> Francis Moreau <francis.moro@gmail.com> writes:
>>>>
>>>>> I have some stupids questions about void type and pointer to void.
>>>> There are no stupid questions.
>>> Actually, there are very many stupid questions. But these weren't
>>> three of them.
>>
>> Is "are there any stupid questions?" a stupid question?
>
> No.
>
>> How about that one?
>
> No. But here's an example of a stupid question: "Will the trolls ever
> get a clue?"

How about whether you will ever get a clue? I know
some people think that's a stupid question.

Stop being such a shit stirrer.

== 4 of 5 ==
Date: Thurs, Feb 4 2010 12:14 pm
From: Tim Rentsch

Francis Moreau <francis.moro@gmail.com> writes:

> The first one is about dereferencing a void pointer. It's just
> forbidden but when reading 6.5.3.2 about indirection operators, I
> can't find anything that states it.

My answer to this question is given in a response to
Eric Sosman's posting.

== 5 of 5 ==
Date: Thurs, Feb 4 2010 1:29 pm
From: Richard Heathfield

Tim Rentsch wrote:
> Richard Heathfield <rjh@see.sig.invalid> writes:
>
>> Nick wrote:
>>> Richard Heathfield <rjh@see.sig.invalid> writes:
>>>
>>>> Ben Bacarisse wrote:
>>>>> Francis Moreau <francis.moro@gmail.com> writes:
>>>>>
>>>>>> I have some stupids questions about void type and pointer to void.
>>>>> There are no stupid questions.
>>>> Actually, there are very many stupid questions. But these weren't
>>>> three of them.
>>> Is "are there any stupid questions?" a stupid question?
>> No.
>>
>>> How about that one?
>> No. But here's an example of a stupid question: "Will the trolls ever
>> get a clue?"
>
> How about whether you will ever get a clue? I know
> some people think that's a stupid question.

I'm one of them.

> Stop being such a shit stirrer.

I'm impressed by your ability to jump to conclusions.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: Issue with printing a string
http://groups.google.com/group/comp.lang.c/t/26e268149fdbfe14?hl=en
==============================================================================

== 1 of 8 ==
Date: Thurs, Feb 4 2010 11:51 am
From: Seebs

On 2010-02-04, santosh <santosh.k83@gmail.com> wrote:
> What about the stdcall ABI, when you don't do fancy linking based on
> the parameter list? The callee will end up popping either too few or
> too many arguments from the stack.

I have apparently never used it, or if I have, I never happen to have seen
something with the wrong number of arguments in it.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 8 ==
Date: Thurs, Feb 4 2010 12:13 pm
From: "Default User"

Michael Foukarakis wrote:

> On Feb 4, 2:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> > Michael Foukarakis wrote:
> > > On Feb 4, 12:08 pm, Richard Heathfield <r...@see.sig.invalid>
> > > wrote:
> > >> Michael Foukarakis wrote:

> > > Indeed. Discussions also need arguments;
> >
> > <sigh> Not so's you'd notice.
>
> Worth putting effort into, nonetheless. Trolls get tired, grow up, or
> die, eventually.

They get tired much faster if you ignore them.

Brian

--
Day 367 of the "no grouchy usenet posts" project

== 3 of 8 ==
Date: Thurs, Feb 4 2010 1:09 pm
From: Phil Carmody

Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> On 2010-02-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> char RandomChar() {
>>> static char src[] = "acbdefghijklmnopqrstuvwxyz";
>>> return src[rand() % sizeof src];
>>> }

>> I doubt you want exactly this. You probably want to use
>>
>> rand() % (sizeof src - 1)

> Oh my goodness! I did mean that, and I have been bitten
> by this bug in my own code. (Though in that case, it was
> a one-off password generator and as I recall I just kept
> running it until I got a string without any \0 characters
> truncating the string.)

I mention in passing that gcc (4.1 here), even with no
optimisation, turns strlen(src) into a constant. I'd feel
a bit odd relying on that, but it's nice to know that at
least on the only compiler I regularly use (modulo a whole
host of different versions), can be relied on to turn the
apparently inefficient into the optimal.

Phil
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

== 4 of 8 ==
Date: Thurs, Feb 4 2010 1:16 pm
From: Andrew Poelstra

On 2010-02-04, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> Andrew Poelstra <apoelstra@localhost.localdomain> writes:
>> On 2010-02-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> char RandomChar() {
>>>> static char src[] = "acbdefghijklmnopqrstuvwxyz";
>>>> return src[rand() % sizeof src];
>>>> }
>
>>> I doubt you want exactly this. You probably want to use
>>>
>>> rand() % (sizeof src - 1)
>
>> Oh my goodness! I did mean that, and I have been bitten
>> by this bug in my own code. (Though in that case, it was
>> a one-off password generator and as I recall I just kept
>> running it until I got a string without any \0 characters
>> truncating the string.)
>
> I mention in passing that gcc (4.1 here), even with no
> optimisation, turns strlen(src) into a constant. I'd feel
> a bit odd relying on that, but it's nice to know that at
> least on the only compiler I regularly use (modulo a whole
> host of different versions), can be relied on to turn the
> apparently inefficient into the optimal.
>

Out of curiousity, what disassembler do you use to tell that?

== 5 of 8 ==
Date: Thurs, Feb 4 2010 1:15 pm
From: Seebs

On 2010-02-04, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
> I mention in passing that gcc (4.1 here), even with no
> optimisation, turns strlen(src) into a constant. I'd feel
> a bit odd relying on that, but it's nice to know that at
> least on the only compiler I regularly use (modulo a whole
> host of different versions), can be relied on to turn the
> apparently inefficient into the optimal.

This actually bit us once. There's another rule:
strcpy(dest, "string literal");
is magically transformed into
memcpy(dest, "string literal", 15);

But. In one of the branches of the Linux kernel tree, someone thought it
would be a great idea to provide a special hand-tuned assembly implementation
of memcpy, which saved a single instruction by returning 0 instead of the
destination pointer.

Enter a lump of code roughly to the effect of:
strcat(strcpy(dest, "foo"), "bar");
and a kernel panic as strcat tried to copy into a null pointer.

After some consideration, we determined that this did not constitute a
toolchain bug.

(The question isn't as trivial as it might seem, because freestanding
environments are in some cases permitted to have a really weird standard
library. There is an option to disable that transformation, but it seemed
smarter to just fix the memcpy() implementation.)

== 6 of 8 ==
Date: Thurs, Feb 4 2010 2:07 pm
From: Ian Collins

Phil Carmody wrote:
>
> I mention in passing that gcc (4.1 here), even with no
> optimisation, turns strlen(src) into a constant. I'd feel
> a bit odd relying on that, but it's nice to know that at
> least on the only compiler I regularly use (modulo a whole
> host of different versions), can be relied on to turn the
> apparently inefficient into the optimal.

Sun cc will do the same, very handy. I guess anywhere the programmer
could use sizeof in place of strlen, the compiler does the same.

--
Ian Collins

== 7 of 8 ==
Date: Thurs, Feb 4 2010 2:26 pm
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <slrnhmme4h.sln.apoelstra@localhost.localdomain>, Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> On 2010-02-04, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:

>> I mention in passing that gcc (4.1 here), even with no
>> optimisation, turns strlen(src) into a constant. I'd feel
>> a bit odd relying on that, but it's nice to know that at
>> least on the only compiler I regularly use (modulo a whole
>> host of different versions), can be relied on to turn the
>> apparently inefficient into the optimal.
>>
>
> Out of curiousity, what disassembler do you use to tell that?

Probably no disassembler, just "gcc -S":

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Overall-Options.html#index-S-75

It works here too (4.3.2):

----v----
#include <string.h>
int main(void)
{
return strlen("The quick brown fox jumps over the lazy dog");
}
----^----

$ gcc -S strlen.c

----v----
main:
.LFB2:
pushq %rbp
.LCFI0:
movq %rsp, %rbp
.LCFI1:
movl $43, %eax
leave
ret
----^----

Cheers,
lacos

== 8 of 8 ==
Date: Thurs, Feb 4 2010 2:28 pm
From: Phil Carmody

Andrew Poelstra <apoelstra@localhost.localdomain> writes:
> On 2010-02-04, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> Andrew Poelstra <apoelstra@localhost.localdomain> writes:
>>> On 2010-02-04, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>> char RandomChar() {
>>>>> static char src[] = "acbdefghijklmnopqrstuvwxyz";
>>>>> return src[rand() % sizeof src];
>>>>> }
>>
>>>> I doubt you want exactly this. You probably want to use
>>>>
>>>> rand() % (sizeof src - 1)
>>
>>> Oh my goodness! I did mean that, and I have been bitten
>>> by this bug in my own code. (Though in that case, it was
>>> a one-off password generator and as I recall I just kept
>>> running it until I got a string without any \0 characters
>>> truncating the string.)
>>
>> I mention in passing that gcc (4.1 here), even with no
>> optimisation, turns strlen(src) into a constant. I'd feel
>> a bit odd relying on that, but it's nice to know that at
>> least on the only compiler I regularly use (modulo a whole
>> host of different versions), can be relied on to turn the
>> apparently inefficient into the optimal.

> Out of curiousity, what disassembler do you use to tell that?

I didn't.

Phil
(more in headers, but please think before looking)
--
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1

==============================================================================
TOPIC: Encoding Date/Time
http://groups.google.com/group/comp.lang.c/t/0ad6871d063ac3e8?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 12:00 pm
From: Nick <3-nospam@temporary-address.org.uk>

Nick Keighley <nick_keighley_nospam@hotmail.com> writes:

> On 4 Feb, 02:43, "PNP" <p...@p.com> wrote:
>
>> I need to fine the current date/time add x hours & y minutes to
>> it. I then need to send it through IPC to a different process which
>> can read this & find the sent time.
>>
>> What is smallest number of bytes I need for sending this data?
>> i.e. How many bytes is that data guaranteed to fit in?
>
> this is unanswerable without more information. Before I read other
> people's posts I assumed you only wanted the time to the minute. Since
> there are 1440 minutes in a day you can get the time into 10.5 bits.
> If you program sends regular updates you might get away with a delta
> (add x minutes to the last value)

If the IPC protocol has a time in the header, you could send a delta
from transmission time and then the number of bytes you need depends
solely how far x and y can be from the time of transmission.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Countdown "operator"
http://groups.google.com/group/comp.lang.c/t/7cac8ce1e80eca94?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 12:13 pm
From: Keith Thompson

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Beej Jorgensen <beej@beej.us> writes:
>> On 01/29/2010 09:08 PM, Albert wrote:
>>> What part(s) of it do you disapprove?
>>
>> I disapprove of the non-idiomatic usage of the --> operator. Er,
>> "operators".
>
> Just a minor correction... Using '-->' as an "operator" is
> in fact idiomatic. It is not a _common_ idiom, but still it
> is an idiom.

It's idio-something.

--
Keith Thompson (The_Other_Keith) kst-u@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"

==============================================================================
TOPIC: Macro to manipulate chars inside string
http://groups.google.com/group/comp.lang.c/t/9d5125687dd742c0?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 4 2010 1:55 pm
From: "bartc"

"Thad Smith" <ThadSmith@acm.org> wrote in message
news:4b6a5b6c$0$77545$892e0abb@auth.newsreader.octanews.com...
> Andre wrote:
>
>> I need a macro to transform an value like 274A into {(char)0x27, (char)
>> 0x4A}. Does anyone know how to do it, or where can I find more
>> information about this kind of macro?
>
> I don't think you can do it with the Standard C preprocessor. It's time
> to write a little utility to do the transformation.

#include "stdio.h"

#define themacro(x) {(char)(x>>8),(char)(x&255)}

int main(void) {
char a[2]=themacro(0x274A);

printf ("A = %X %X\n",a[0],a[1]);
}

Or am I missing something?

(The value is expanded into decimal rather than hex constants; that didn't
seem important as you don't usually see the macro expansions)

--
Bartc

== 2 of 3 ==
Date: Thurs, Feb 4 2010 2:03 pm
From: Keith Thompson

"bartc" <bartc@freeuk.com> writes:
> "Thad Smith" <ThadSmith@acm.org> wrote in message
> news:4b6a5b6c$0$77545$892e0abb@auth.newsreader.octanews.com...
>> Andre wrote:
>>
>>> I need a macro to transform an value like 274A into {(char)0x27, (char)
>>> 0x4A}. Does anyone know how to do it, or where can I find more
>>> information about this kind of macro?
>>
>> I don't think you can do it with the Standard C preprocessor. It's time
>> to write a little utility to do the transformation.
>
> #include "stdio.h"
>
> #define themacro(x) {(char)(x>>8),(char)(x&255)}
>
> int main(void) {
> char a[2]=themacro(0x274A);
>
> printf ("A = %X %X\n",a[0],a[1]);
> }
>
> Or am I missing something?
>
> (The value is expanded into decimal rather than hex constants; that
> didn't seem important as you don't usually see the macro expansions)

No, the macro expanded into constant expressions such as
``(char)(0x274A>>8)'' and ``(char)(0x274A&255)''. The results of
evaluating those constant expressions are numeric values which are
not inherently either decimal or hexadecimal.

Note that converting a value exceeding 127 to char might cause
problems. It's almost certainly better to use unsigned char.

As far as I can tell, we *still* don't know exactly what the original
poster is asking for.

== 3 of 3 ==
Date: Thurs, Feb 4 2010 2:21 pm
From: Andrew Poelstra

On 2010-02-04, Keith Thompson <kst-u@mib.org> wrote:
>
> As far as I can tell, we *still* don't know exactly what the original
> poster is asking for.
>

He went away after somebody (Jacob Navia, I think) suggested he
use his system's UUID en/decoding functions, and the example
values he gave looked an awful lot like UUID's, so I'd say
that was a safe bet that's what he needed.

(Specifically, I think he wanted to copy UUID's from his system
into a #define in some include file and have the code interpret
it properly without needing any special formatting.)

Andrew

==============================================================================
TOPIC: So I want to exhaust a lot of memory
http://groups.google.com/group/comp.lang.c/t/efd5686c57529f9b?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 2:50 pm
From: ImpalerCore

What is the best way to exhaust a lot of memory but at the same time
leave enough so that I can test out of memory errors for some
container functions, i.e. like not having enough memory to allocate a
new list node.

So far, all I've done is something like:

const size_t block_size = 1024*1024;
size_t count;

for ( count = 0; malloc( block_size ); ++count );
...

The smaller the block_size, the longer it takes to exhaust memory. So
I plan to starting with a large block size, exhausting memory,
reducing the block size, exhausting memory, until I get down to a
level that I can exercise my out of memory error handling.

Is this a good strategy? Are there pitfalls that I'm not seeing?
Again, I'm assuming that ending the process reclaims the memory used.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Thursday, February 4, 2010

comp.lang.c - 25 new messages in 10 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts