usage of size_t

[Seebs]

Humm... I may me misunderstanding you, buy exactly why do the objects need
to be stored elsewhere?

If they don't, where does the pointer point?

I mean, the list already stores a reference to the
object and that's good enough for me. For instance, where am I using extra
storage to "store objects" in the following program:

"Extra" meaning "in addition to the list objects".

In:

struct foo {
struct foo *next;
char data[];
};
(C99), each allocated "struct foo" contains the associated data.

In:
struct foo {
struct foo *next;
char *data;
};
each allocated "struct foo" contains a pointer to data which must be stored
elsewhere.

-s

 

[Chris M. Thomasson]

Chris M. Thomasson wrote:



If that object isn't stored somewhere, to what does the reference refer?
First rule of objects: Everything Has To Be Somewhere.


Line 78.

I think I was totally misunderstanding the issue Richard!

 

[Chris M. Thomasson]

If they don't, where does the pointer point?


"Extra" meaning "in addition to the list objects".

[...]

Okay, but how would you implement my sample program using nothing but
value-based containers? Assume that you are forced to work with a container
library that provided nothing but value-based containers. Each object is
stored on N lists and I do not want each node to have a separate copy of an
object.

 

[Chris M. Thomasson]

Chris M. Thomasson wrote:



If that object isn't stored somewhere, to what does the reference refer?
First rule of objects: Everything Has To Be Somewhere.


Line 78.

Fair enough. But how would I create that program using nothing but
value-based containers?

 

[Chris M. Thomasson]

Chris M. Thomasson wrote:


Step 1: using what we are now calling a "value-based" container, read in
the data, and pass a pointer to it, and its size, to the container add
function, e.g. array_add(&array, &foo, sizeof foo);

Step 2 would go something like this:

n = array_count(array);
for(i = 0; i < n; i++)
{
p = array_fetch(array, i);
list_add(&list, &p, sizeof p);
}

Okay. I am curious as to how the list nodes internal structure would look?
It seems like you could end up wasting some space in this case. For
instance, if the node was like:


struct node
{
struct node* next;
void* data;
size_t size;
};


Is the `node::size' member not wasted space if we only store a pointer to an
object? Also, would the container have to actually allocate space for a
pointer? Humm... Would the container have to make two allocations, 1 for the
node, and 1 for the data in this case?


Also, if this was C99:


struct node
{
struct node* next;
char data[];
};


Would there be alignment issues if you stored something that was not a char?

 

[Chris M. Thomasson]

Okay. I am curious as to how the list nodes internal structure would look?
It seems like you could end up wasting some space in this case. For
instance, if the node was like:


struct node
{
struct node* next;
void* data;
size_t size;
};


Is the `node::size' member not wasted space if we only store a pointer to
an object? Also, would the container have to actually allocate space for a
pointer? Humm... Would the container have to make two allocations, 1 for
the node, and 1 for the data in this case?

Well, according to your linked list implementation:


http://groups.google.com/group/comp.lang.c/browse_frm/thread/a77ea83913603f48


I would have to pay the penalty of allocating a node, and allocating space
for a pointer! IMVHO, this is completely unacceptable and it shows how a
value-based container is simply no good at all for certain problems.

 

[spinoza1111]

Humm... I may me misunderstanding you, buy exactly why do the objects need
to be stored elsewhere?

If they don't, where does the pointer point?

I mean, the list already stores a reference to the
object and that's good enough for me. For instance, where am I using extra
storage to "store objects" in the following program:

"Extra" meaning "in addition to the list objects".

In:

        struct foo {
                struct foo *next;
                char data[];
        };
(C99), each allocated "struct foo" contains the associated data.

No, it doesn't. Furthermore, you are representing the problem as one
of character data only as if that were the only type of linked list.
In this example, as in your second example below, an address is in the
node!

The two methods are equivalent. char a[] == char *a functionally and
conceptually.

struct a { char arr[1]; };
struct b { char* ptr; } bb;
printf("%d %d\n", sizeof(bb), sizeof(bb));

Prints 4 4 no matter what size arr is or even if the array size is
removed.

struct a { char arr[1000]; };
struct b { char* ptr; } bb;
printf("%d %d\n", sizeof(bb), sizeof(bb));

Prints 4 4

This is a much more egregious error than any you've proven as regards
Schildt, and I've added the two errors here (misrepresentation of
array/pointer relationship and apparently thinking that all linked
lists must be characters) to a growing collection of serious newbie
errors that you have made. You need to replace "C: the Complete
Reference" with an APOLOGY for your disgusting behavior and proven
incompetence.

In:
        struct foo {
                struct foo *next;
                char *data;
        };
each allocated "struct foo" contains a pointer to data which must be stored
elsewhere.

Inadequate. Not all data is string data.

 

[spinoza1111]

You can't possibly be surprised by this.  Consider his assertion that if
it was hard to write, it should be hard to read.  Clearly, this is a man
devoted to trying to create job security by every possible tactic other
than actually being good at his job.

You're in a dreamworld, inhabited by cartoon projections of your own
psychological transference, because far from being interested in "job
security", I have, as I have said, left the field in disgust with
people like you. I had, during a career that was three times as long
as the norm in a field where most programmers are laid off after ten
years, quite a lot of job security owing to my willingness to learn
object oriented approaches and the Web.

In your cartoon dreamworld, your pathetic little videogame of a life,
the minor avatars of programmers were trained (in fact, in the
Dreamtime of the 1970s) by a deliberate corporate misinterpretation of
Dijkstra's 1972 Turing lecture to disavow self-interest, and never
imply by word that they were interested in job security.

The material contradiction was that a "free market" based society
preached on the one hand universal self-interest and ****-you as
morality, while at the same time demanding that corporations be ever
larger in order to best serve a small wealthy elite. Which required
dragooning people like you, who don't count, into large "teams" of
paid slaves who then had to disavow the previous committment to
universal competition and work like a big happy family.

In fact, absent a property right in a job after a trial period,
something which is denied people in our fuckyou society, there could
at a minimum be a right to ensure job security by establishing tenure
through a skill in something objectively determinable, which means
something whose standards are established OUTSIDE the corporation. But
in the interest of the corporation, even this type of job security was
an obstacle to profit, and the result was that through a deliberate
misinterpretation of structured programming, "skill at programming"
became group-subjective. It became in fact the least common
denominator "skill", which meant that even literate comments (in
little shops staffed by attention-disordered psychology majors) became
deviance from normalized deviance, and a "quirk"...from which clowns
like Peter can infer "incompetence".

More importantly:  Let's say that we take him to mean "some compilers for
variants of C, which are not actually conforming".

Okay.  Name one.  Here's a test program:

        #include <stdlib.h>
        /* #include <malloc.h> */
        int main(void) {
                void *p = malloc(1);
                free(p);
                return 0;
        }

Name a compiler on which this fails, but where if you uncommented the
second line, it would work.  The compiler must have shipped some time
after 1992 -- it can't be old enough to vote.

After getting rid of 0xa0 characters that you so carelessly left in,
apparently, the code compiles and runs with both or either statements
in Microsoft C++ Express in C mode.

 

[spinoza1111]

Probably because there's no such construct in portable C. You can
simulate exceptions using standard C, but it gets ugly very quickly.
Pity.

I don't see how the difference between storing an object and
referencing an object in a linked list makes a difference here.

In your preferred method, the objects are stored in an external
location from the list and referenced using pointers in the list
nodes. The objects still need to be stored somewhere, so the cost is N
+ M where N is the storage for objects and M is the storage for
pointers to the objects.

I'm not talking about the storage complexity of the source copy of the
objects. I referred, quite clearly, to the time complexity of making
the copy, an O(n) operation which is unnecessary unless the
specification requires a duplicate copy of data.

With the copying method, the list will replace the "external location"
and act as the primary point of storage for the objects. Then if
references are needed beyond the list, pointers can be used. Once
again, the cost is N + M.

See above.

The only difference here is swapped roles of storage and reference.
The storage costs are identical if you want one pointer for each
object, so if copying brings the system to it's knees, referencing
will too.

Not true. The copy in Richard's code is an extra cost imposed by his
decision (possibly made in ignorance) that it's proper to copy things
into his linked list.

I suspect you're imagining both the external location *and*
interdependent copies stored in the list, which is very likely to be a
flawed design before the implementation details of your list even
enter into the picture.

Gobbledegook on steroids,
Sesquipedelian, perfectly formed,
In which we search for meaning in voids
Between the spaces where the meaning should lie.
Be that as it may, in this *opera buffa*
Little headway can be made
'Gainst the nonsense storm in which flies the Worm.
The syntax, tho' it appears Chomsky low
Is in fact corporate Chomsky Three:
What's important is not the meaning
Of the quivering naked whole,
No, what's important are keywords,
For that's what people remember these days.
She says it's flawed so it must be flawed
Somehow someway and one fine day
We'll get a round "tuit" and hey, hey hey
Then we'll know, why it's fucked.

 

[spinoza1111]

spinoza1111wrote:



There Is No Duplicate, unless one chooses to make it.

int loadlistfoo(parms)
{
   struct foo bar = {0};
   while(getrec(&bar, fp))
   {
     list_add(&list, &bar, sizeof bar);
   }

}

Let's say the above loop creates 2000 records. When the function
returns, there are 2000 records in memory. Not 4000. Not 6000. Just
2000. There Is No Duplicate.

It would be pleasant if, occasionally, it would take you less than a
week to understand the blindingly obvious.

What has taken me a long time is understanding how limited a
programmer you are.

Here, you take a trivial file loop and make a complete copy of the
file in memory using your very slow bytewise move in the linked list
"tool", and you give no reason why this pattern would be useful.

If you have a valid reason in simple business programming to read a
complete file into memory (which is rare), then it's best done by a
single read, followed as needed by creating an index by searching for
whatever characters separate records. Your silly code is O(n)*2*K
since for each record, it does what's probably a bytewise O(n) read of
each record followed by ANOTHER O(n) transfer of data. Whereas reading
the complete file (or segments large enough to increase the read speed
without taking too much space) is order the number of bytes of the
file plus (not times) the number of records times a small fixed amount
of time for setting links per node.

If the file can change during the complete operation, without record
adds or deletes, then the links should point to offsets within the
file. Your code of course has a complete exposure in this scenario. It
will fail, and such idiot code exists and fails in many contexts.

But, of course, the usual scenario in which a linked list is not this
pathetic little business data processing from the days of Cobol. It's
when an existing data set in memory needs to be accessed by >1
alternate paths and/or subsets of data sets are required, and the
situation arises not in business data processing but in compilers,
tools and OSen.

Your linked fool tool is USELESS for these types of applications and
betrays a stunning ignorance of computer science, as if you have the
least license to open your yap about linked lists.

It is basically flawed since in the scenario you have presented your
"reusable tool" creates an unnecessary duplicate of a data set whose
size is unpredictable. It means that your conceptual world is in fact
a Dreamtime, since it's based on data processing gestures such as
sequential file processing which are completely out of date. This is a
recreational Dreamtime, since actual programming gestures do not
typically incorporate such claptrap.

Finally, I would also draw your attention to a marked difference in
literary style between your defense of your code, and my critique.

You present as typical an approach from the past, and the "brevity" of
your presentation presupposes that all "sane" programmers "know all
about this". Which they do, because sequential file processing is
presented overmuch in inferior programming courseware with the result
that it is often used at key points in data base systems, lowering the
efficiency and security of the data base system by a considerable
amount.

Secretly knowing your inadequacy and how inadequate your presentation
and code is, you end with the usual unjustified and unproven global
attack on my qualifications and credibility, because this is the way
of the weak.

In fine, this is the "nonsense" you snip: it is in fact the heart of
the matter.

Shove it up your ass.

 

[spinoza1111]

spinoza1111wrote:

Humm... I may me misunderstanding you, buy exactly why do the objects need
to be stored elsewhere?
If they don't, where does the pointer point?
I mean, the list already stores a reference to the
object and that's good enough for me. For instance, where am I using extra
storage to "store objects" in the following program:
"Extra" meaning "in addition to the list objects".
In:
        struct foo {
                struct foo *next;
                char data[];
        };
(C99), each allocated "struct foo" contains the associated data.

No, it doesn't. Furthermore, you are representing the problem as one
of character data only as if that were the only type of linked list.

Um, that's nonsense. What he's doing is explaining to Chris the
difference between containing and indexing in terms of storage, and he's
trying to do so in a way that even you can understand. Clearly, he's
failing at that last bit, but that's hardly surprising. His char example
is just that - an example.

He won't let Schildt use similar examples where a concrete example has
features that aren't true of the general case. I won't let him. If he
had credibility, I would. It's that simple.

In this example, as in your second example below, an address is in the
node!

The two methods are equivalent. char a[] == char *a functionally and
conceptually.

Rubbish. The first one is a "struct hack" - IMHO ugly, but pragmatic in
C90 and codified (with slightly different syntax, reflected above) in
C99. Usage is as follows:

struct foo *new = malloc(sizeof *new + number_of_extra_bytes_needed);
if(new != NULL)
{
   new->next = NULL;
   strcpy(new->data, data);

}

You would do better to learn from Seebs than to presume to teach him.

Not in a million years.

You have nothing to teach but expletives, and I expect he knows those
already.

No, I don't think he does. And as far as I'm fucking concerned,
asshole, the time for a good, solid motherfucking expletive est
arrive, since ten fucking years of trying to make you behave with
common decency have not changed your **** character. Using expletives
is a VICTIMLESS action, whereas your constant attacks on reputations
and good names here, based on a series of temp jobs and a pathetic
book, has damaged people and wasted our time.

   struct a { char arr[1]; };

That isn't what he wrote.

   struct b { char* ptr; } bb;
        printf("%d %d\n", sizeof(bb), sizeof(bb));

Prints 4 4 no matter what size arr is or even if the array size is
removed.

So you're saying that, on systems with 4-byte pointers, if you print out
the size of a structure containing nothing but a pointer, twice, it'll
print out 4, twice? Gee whizz! (Hint: you printed the same size twice.)

I noticed the error 60 seconds after posting and removed the post. I
believe I also posted a followup. Whereas you and Seebach need
consistently to have your errors explained to you, in some cases
repeatedly.

Now, please put down your non sequitur and step away from your reply
button, and pop over to a Web browser. Look up "struct hack". You'll
find a zillion hits for it. Read, mark, learn, and inwardly digest. And
it won't be long before you're trying to pretend that you knew about it
all along.

To "hack", alack, is not what to the wise and grave aspire
It means to get "results" in a mode fit only for the fire
It's a job for apes and monkeys, low creatures in greed for gold
It is Stygian, it is Augean, it is for creatures dank and cold.
My code is so unusual because it is in fact well wrought
To deliberately "hack" might seem real cute but it delivers aught:
But what the cunting **** do you care, the client pays his bill
And before the bugs and low performance start, you disappear over
Whoredom's hill.

Cue expletive.

No, let us NOT now cue an "expletive",
Let's cue instead pentameter iambic:
For indeed, your villainy, while it hath not
Dimension tragic, hath had tragic issue.
A monster from the depths of contract code
Thinking himself a man, dons man's attire
To curse him for a fool it is not enow
To make others, not he, see the tragic result.
He is blind, he howls upon the heath,
His is the soul of much less than a Flea,
He is deaf to reason in any season,
Trogdolyte homunculus and Frankenstein
Who's set his face on all that is fine.
So the low sew their ignorant bile
And so the wise weep, and no longer smile.
We have gotten too and now we're through
With applying to you, words like fuckhead, whore and ****:
We leave you bone-strewn in your cave, and fairer fields, we hunt.

   struct a { char arr[1000]; };
   struct b { char* ptr; } bb;
        printf("%d %d\n", sizeof(bb), sizeof(bb));

Prints 4 4

You're still printing the same size twice.

Jerk. This error was found and corrected, and the post deleted. It
took me ten seconds to find it. How long did it take you?

A Monster thinks that he's a man
And howls his lies to all who'll hear
Finds fool's gold and seizes it,
Gibbers and capers in apish triumph.
Defeated in the eyes of the only wise,
Who are, in fact, those who only wise would someday be,
He quests about in search of foul fetid fiends
To follow him festering in his fennish den,
And there recount with a fearfilled snigger
Tales of those wights who would be men
Tales of those who sought the truth,
Tales of those whom they hate so much
For they can never hear nor see
Glory in their misery.

Very true, your error is much more egregious. Did you really think you
could make a 1000-byte array only four bytes big?

No.

We all know that software and software talk is error prone. However,
you and Seebach, owing to the fact that you're both incompetent, have
treated the errors of others without charity and are now being subject
to the same treatment, only by someone who's far more qualified...so
much so that because data processing is a cost center, there's really
no need for that wight to waste his spirit on such an expanse of
shame, talking with the clue challenged, halt and lame.

You did indeed add that error. But Seebs didn't.


Rubbish. Proof by reductio: You just started a sentence with "This".

Spare me the pompous Latin. You're not qualified to use it.

Therefore, apparently you think all sentences must start with "This".
How ridiculous is that?

Gee, when all else fails, change the subject: either retail some war
story about someone who you think was even more incompetent and a
weakling that you think you are, or reduce random shit to absurdity,
which demonstrates nothing.

 > to a growing collection of serious newbie


You don't know what you're talking about, and it shines out from every word.





Your criticism is misplaced. He's not showing you how to use a
type-blind list. That's already been done, in the source text under
discussion. Rather, he's showing you (or rather, Chris) the difference
between containing and indexing.

By his logic, that he applied in "C: the Complete Nonsense", we can
infer that he thinks that all linked lists must be char. Frankly, I
don't think he's that much a fool, and I made this clear. I merely
pointed out that he made the same gesture as Schildt, but expects to
be forgiven.

This demonstrates my points. Like most creeps, he's been, probably,
overmothered to believe that he's "special", and thus may apply
different standards to others that he applies to himself. He can use
char in a linked list, which MAY be interpreted by the newbie, reading
random posts, as implying that "all linked lists must be char", but
Herb could not say that the heap is in high memory by way of
illustration (as does the high school geometry teacher draw ONE
triangle) without Seebach getting his panty hose in a tangle.

In fact, just as a careful writer would have written, had he believed
that Herb's clarity hides error, that "Herb is only apparently clear",
a careful writer/coder would have either used pointer to void in the
example, or else annotated it to the effect that char was only an
example. However, because Seebie failed to learn to write in skewl,
such complexity strikes him as precisely that kind of quirkiness that
would have by his own rule, marginalized him.

"Normalized deviance" means that Seebach, when he wrote the silly %s
solution, didn't dare even try to do the job right, using strstr
instead of strchr. He literally is afraid to think, and do a good job,
and this is why he so hates people who make the effort, and laughs at
them when they make mistakes: it's because he sees the secret contour
of his own weakness.

 

[Willem]

Keith Thompson wrote:
) If two pointers that point to the same thing don't compare equal,
) then the implementation is non-conforming. C99 6.5.9p6:
)
) Two pointers compare equal if and only if both are null pointers,
) both are pointers to the same object [...]
)
) (The "[...]" deals at some length with function pointers and pointers
) just past the end of objects.)
)
) I suppose I'm not surprised that a C compiler that deals with the
) various memory models might not be completely conforming.

I would imagine that one way to get different segmentffset pointers that
point to the same address would be for one of the pointers to be obtained
by going outside of the bounds of a different object.

For example, if each malloc() would return a segment pointer to the
allocated memory, and an offset pointer of 0.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[Julienne Walker]

Pity.

Not really. C isn't a language that lends itself to proper exception
support because there are too many points where exceptions fall flat.
One can see the problems by looking at C++. C++ exceptions are useful
to a point, but in my opinion they're not nearly as beneficial as they
would be if C++ integrated them more fully into the language (throwing
an exception on out of bounds array indexing, for example) and had
native garbage collection.

By the time you plug the holes, you'll have something more like Java
or C#.

I'm not talking about the storage complexity of the source copy of the
objects. I referred, quite clearly, to the time complexity of making
the copy, an O(n) operation which is unnecessary unless the
specification requires a duplicate copy of data.

No, you didn't make it clear at all. The statement I quoted and
replied to can easily be interpreted as: copying to a linked list
makes the system run slow if there's 'just enough' memory. This
suggests that referencing in a linked list wouldn't run slow in the
same situation, which is the implication that my reply refutes.

I agree that copying large objects may be problematic, especially with
an extra malloc call. I don't agree that it's a deal breaker. I'm not
the only one who's suggested that copying a pointer to the data rather
than the data itself is one way to get the effect of referencing with
a copying linked list. You just need to be aware of your memory
management (as one should be), and avoid unnecessary copies on the
client side.

See above.

See above.

Not true. The copy in Richard's code is an extra cost imposed by his
decision (possibly made in ignorance) that it's proper to copy things
into his linked list.

The copy may be an extra cost. Or it may not. Let's say the original
object being copied is a local variable as opposed to dynamically
allocated memory. A copy is necessary if the list node lives longer
than the scope of said local variable. Either way you're calling
malloc and copying the object.

Richard's design is actually very close to the boilerplate for my own
published container libraries at www.eternallyconfuzzled.com (which
may or may not be designed differently if I rewrote them). The
container maintains 'dup' and 'rel' delegates which manage copying and
releasing of the contained objects. When creating a new node, dup
copies the data as in:

node->data = container->dup(data);

When deleting an existing node, the pointer is released:

container->rel(node->data);

If one wants copying semantics, simply call malloc and copy the data
in dup, then free it in rel. For referencing semantics, return the
argument in dup and do nothing in rel:

void *dup(void *data)
{
return data;
}

void rel(void *data)
{
// No work needed
}

This design is preference agnostic in that copying and referencing are
both supported. However, if I were writing about data structures, I'd
only mention this design in passing (or attach complete libraries as
supplementary to the chapter) because the extra fluff takes away from
the topic being taught.

You may notice that I follow this pattern in my tutorials on that site
if you've read them. The tutorials typically use integer data and a
copying design to minimize boilerplate code and highlight the data
structures being described. Then the libraries act as supplementary to
exhibit a more reusable implementation.

I know C Unleashed came with a CD, but I never looked at it. Perhaps
Richard could comment on whether he did the same thing.

 

[Seebs]

Okay, but how would you implement my sample program using nothing but
value-based containers? Assume that you are forced to work with a container
library that provided nothing but value-based containers. Each object is
stored on N lists and I do not want each node to have a separate copy of an
object.

I wouldn't, because I don't think that can be done. That's one of the reasons
that not every container implementation is value-based.

-s

 

[Seebs]

struct foo {
struct foo *next;
char data[];
};

In this example, as in your second example below, an address is in the
node!

The two methods are equivalent. char a[] == char *a functionally and
conceptually.

Rubbish. The first one is a "struct hack" - IMHO ugly, but pragmatic in
C90 and codified (with slightly different syntax, reflected above) in
C99.

Yes.

In this case, no, 'char data[]' and 'char *data' are NOT the same.

#include <stdlib.h>
#include <assert.h>

struct foo {
struct foo *next;
char data[];
};
struct bar {
struct bar *next;
char *data;
};

int
main(void) {
struct foo *f;
struct bar *b;
f = malloc(sizeof(*f) + 16);
/* this next line would be an error, because data is not
* a modifiable thing: */
/* f->data = malloc(16); */
b = malloc(sizeof(*b));
b->data = malloc(16);
assert((void *) f->data == (void *) &(f->data));
assert((void *) b->data != (void *) &(b->data));
printf("hello, world!");
free(b->data);
free(b);
free(f);
return 0;
}

Assuming malloc succeeds, this allocates two structures, in each of
which x->data is the address of 16 bytes of usable storage. In one
of them, that 16 bytes is part of the same object; in the other, it's
a separate allocated block.

It might have been simpler to illustrate this with "char data[16];",
but apparently spinoza1111 would have thought that, too, was the same as
'char *data', which it's not in a structure definition. (He's probably
confused by the weirdness of arrays as parameters?)

-s

 

[blmblm]

[ snip ]

After getting rid of 0xa0 characters that you so carelessly left in,

There were no 0xa0 characters in the copy of Seebs's post delivered
to me by the news server I use. There *ARE* such characters in
many posts made using the Google Groups posting interface, which
seems to employ them as part of a "quoted printable" encoding.
Perhaps the ones you found were added by the GG interface?

apparently, the code compiles and runs with both or either statements
in Microsoft C++ Express in C mode.

So the online documentation that seems to indicate that both are
needed is incorrect. Hm.

 

[Chris M. Thomasson]

Chris M. Thomasson wrote:



Fine, so don't use it.

I guess I could use it in conjunction with a reference-based container. The
objects themselves could be stored directly in a value-based container.
Then, I would add references to these objects to the ref-based containers.
Quite frankly, the biggest concern I have with the pure value-based solution
is that the container just might call `malloc()' to allocate space for a
pointer. So, why not have a special interface for pointers?


<quick pseudo-code typed into newsreader>
_____________________________________________________________
struct node
{
struct node* next;
void* object;
size_t size;
};


struct list
{
struct node* next;
};


int
list_push_pointer(struct list* const self,
void* object)
{
struct node* node = malloc(sizeof(*node));

if (! node) return 0;

node->next = self->head;
node->object = object;
node->size = 0;
self->head = node;

return 1;
}


int
list_push(struct list* const self,
void* object,
size_t size)
{
struct node* node

if (! size) return 0;

if (! (node = malloc(sizeof(*node)))) return 0;

if (! (node->object = malloc(size))))
{
free(node);
return 0;
}

memcpy(node->object, object, size);
node->next = self->head;
node->size = size;
self->head = node;

return 1;
}
_____________________________________________________________


Does something like that sound workable to you?

But for other problems, it's fine. There is no silver bullet.

Absolutely.

 

[Chris M. Thomasson]

I wouldn't, because I don't think that can be done. That's one of the
reasons
that not every container implementation is value-based.

Touché! :^)

 

[Richard Tobin]

Okay. @Name one. @Here's a test program:

@ @ @ @ #include <stdlib.h>
@ @ @ @ /* #include <malloc.h> */
@ @ @ @ int main(void) {
@ @ @ @ @ @ @ @ void *p = malloc(1);
@ @ @ @ @ @ @ @ free(p);
@ @ @ @ @ @ @ @ return 0;
@ @ @ @ }

[/QUOTE]

After getting rid of 0xa0 characters that you so carelessly left in,

There were no 0xa0 (NBSP, non-breaking space) characters in Seebs's
post. It was in plain ascii. However, you have introduced many in
your reply, and I have replaced them in the quoted text with @ signs
so you can see them.

You appear to be using some software which replaces multiple spaces
(such as double spaces at the end of sentences) and tabs with
sequences of alternate NBSPs and plain space characters. I can only
conjecture what horrible environment this might make sense in.

-- Richard

 

[spinoza1111]

spinoza1111wrote:

        struct foo {
                struct foo *next;
                char data[];
        };
In this example, as in your second example below, an address is in the
node!
The two methods are equivalent. char a[] == char *a functionally and
conceptually.

**** you, asshole. Richard got a copy of a post which I withdrew by
means of delete attempt and a retraction ten seconds after it was
posted. You're Swift Boating.

Yes, I know less about C than you, but you're not even a programmer,
and no amount of deception will refute this.

Rubbish. The first one is a "struct hack" - IMHO ugly, but pragmatic in
C90 and codified (with slightly different syntax, reflected above) in
C99.

Yes.

In this case, no, 'char data[]' and 'char *data' are NOT the same.

        #include <stdlib.h>
        #include <assert.h>

        struct foo {
                struct foo *next;
                char data[];
        };
        struct bar {
                struct bar *next;
                char *data;
        };

        int
        main(void) {
                struct foo *f;
                struct bar *b;
                f = malloc(sizeof(*f) + 16);
                /* this next line would be an error, because data is not
                 * a modifiable thing: */
                /* f->data = malloc(16); */
                b = malloc(sizeof(*b));
                b->data = malloc(16);
                assert((void *) f->data == (void *) &(f->data));
                assert((void *) b->data != (void *) &(b->data));
                printf("hello, world!");
                free(b->data);
                free(b);
                free(f);
                return 0;
        }

Assuming malloc succeeds, this allocates two structures, in each of
which x->data is the address of 16 bytes of usable storage.  In one
of them, that 16 bytes is part of the same object; in the other, it's
a separate allocated block.

It might have been simpler to illustrate this with "char data[16];",
but apparentlyspinoza1111would have thought that, too, was the same as
'char *data', which it's not in a structure definition.  (He's probably
confused by the weirdness of arrays as parameters?)

**** you, asshole. This is Fascist use of media: to make absurd
hypotheses about what I MIGHT think in hopes that stupid shits will
remember this as true, or possible, and thereby create mere doubt.
It's akin to "argument by fictional as well as false analogy":
retailing a story about SOMEONE ELSE who amused you.

I've compiled arrays as parameters. I developed a model for so doing
in the case of Quick Basic, and this was dev edited by one of the best
people in the business.

I was briefly forgetful of a way of declaring arrays which I last used
twenty years ago and which I avoid, since fixed length arrays are not
good. I am relearning C in order to get rid of you and Heathfield, and
since "learning a programming language" is something for children as
opposed to "learning computer science", I am ramping up fast. I'm the
one (and not Keith Thompson) that took five seconds to find your
strlen bug.

**** you, Peter Seebach, and your corporate games. If you continue,
there are going to be letters to your employers and our publisher, and
a lawsuit. I don't need a job in programming since I am good at many
other things, unlike you, and I'm too old to take the shit you spew on
me lying down.