Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #163420 > unrolled thread
| Started by | Meredith Montgomery <mmontgomery@levado.to> |
|---|---|
| First post | 2021-11-12 15:48 -0300 |
| Last post | 2021-11-19 16:07 -0300 |
| Articles | 20 on this page of 75 — 20 participants |
Back to article view | Back to comp.lang.c
on why declare a struct with a single array in it Meredith Montgomery <mmontgomery@levado.to> - 2021-11-12 15:48 -0300
Re: on why declare a struct with a single array in it Guillaume <message@bottle.org> - 2021-11-12 19:56 +0100
Re: on why declare a struct with a single array in it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-12 19:31 +0000
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-12 21:07 +0100
Re: on why declare a struct with a single array in it pozz <pozzugno@gmail.com> - 2021-11-18 15:53 +0100
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-18 16:13 +0100
Re: on why declare a struct with a single array in it Manfred <noname@add.invalid> - 2021-11-18 16:26 +0100
Re: on why declare a struct with a single array in it pozz <pozzugno@gmail.com> - 2021-11-18 17:22 +0100
Re: on why declare a struct with a single array in it Manfred <noname@add.invalid> - 2021-11-18 18:04 +0100
Re: on why declare a struct with a single array in it Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 16:00 -0300
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-18 22:58 +0100
Re: on why declare a struct with a single array in it Guillaume <message@bottle.org> - 2021-11-19 17:53 +0100
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 11:27 -0800
Re: on why declare a struct with a single array in it scott@slp53.sl.home (Scott Lurndal) - 2021-11-19 20:46 +0000
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-19 12:52 -0800
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-20 13:36 +0100
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-20 14:49 +0000
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-20 15:52 -0800
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 00:19 +0000
Re: on why declare a struct with a single array in it Richard Damon <Richard@Damon-Family.org> - 2021-11-20 20:44 -0500
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-21 14:51 +0100
Re: on why declare a struct with a single array in it Manfred <noname@add.invalid> - 2021-11-21 19:32 +0100
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-21 21:51 +0100
Re: on why declare a struct with a single array in it Manfred <noname@add.invalid> - 2021-11-22 03:17 +0100
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-22 11:31 +0100
Re: on why declare a struct with a single array in it Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-10 04:21 -0800
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-12-10 14:43 +0100
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-22 11:56 +0000
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-10 01:47 -0800
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-12-10 10:55 +0000
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-12-10 14:51 +0100
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-11 06:56 -0800
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-12-11 16:04 +0000
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-12-11 17:23 +0000
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-21 05:30 -0800
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2022-01-21 13:49 +0000
Re: on why declare a struct with a single array in it "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-11 12:17 -0800
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-12 13:00 +0000
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-12 08:25 -0800
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-12 17:38 +0000
Re: on why declare a struct with a single array in it Dick <thiebauddick2@aol.com> - 2021-12-12 16:19 -0500
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-13 08:06 +0000
Re: on why declare a struct with a single array in it Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-13 01:30 -0800
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-12-13 09:34 +0100
Re: on why declare a struct with a single array in it Robert Latest <boblatest@yahoo.com> - 2021-12-13 18:53 +0000
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-13 20:38 +0000
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-15 00:38 -0800
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-12-15 11:21 +0000
Re: on why declare a struct with a single array in it Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-15 10:26 -0800
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-15 10:45 -0800
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-12-10 10:52 -0800
Re: on why declare a struct with a single array in it Guillaume <message@bottle.org> - 2021-11-22 04:06 +0100
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-22 11:32 +0000
Re: on why declare a struct with a single array in it Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 13:00 -0800
Re: on why declare a struct with a single array in it "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-21 13:08 -0800
Re: on why declare a struct with a single array in it Richard Damon <Richard@Damon-Family.org> - 2021-11-20 20:44 -0500
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 12:22 +0000
Re: on why declare a struct with a single array in it Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-11-20 20:13 -0700
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 12:35 +0000
Re: on why declare a struct with a single array in it Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2021-11-21 10:53 -0700
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 18:49 +0000
Re: on why declare a struct with a single array in it "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-21 13:04 -0800
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 14:42 +0000
Re: on why declare a struct with a single array in it Guillaume <message@bottle.org> - 2021-11-21 01:34 +0100
Re: on why declare a struct with a single array in it Bart <bc@freeuk.com> - 2021-11-21 00:48 +0000
Re: on why declare a struct with a single array in it "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-20 16:58 -0800
Re: on why declare a struct with a single array in it David Brown <david.brown@hesbynett.no> - 2021-11-21 14:40 +0100
Re: on why declare a struct with a single array in it "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-21 12:59 -0800
Re: on why declare a struct with a single array in it scott@slp53.sl.home (Scott Lurndal) - 2021-11-21 15:58 +0000
Re: on why declare a struct with a single array in it gazelle@shell.xmission.com (Kenny McCormack) - 2021-11-20 10:55 +0000
Re: on why declare a struct with a single array in it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2021-11-13 08:47 +0000
Re: on why declare a struct with a single array in it Guillaume <message@bottle.org> - 2021-11-13 18:23 +0100
Re: on why declare a struct with a single array in it Kaz Kylheku <480-992-1380@kylheku.com> - 2021-11-13 17:55 +0000
Re: on why declare a struct with a single array in it Anton Shepelev <anton.txt@g{oogle}mail.com> - 2021-11-19 13:14 +0300
Re: on why declare a struct with a single array in it Meredith Montgomery <mmontgomery@levado.to> - 2021-11-19 16:07 -0300
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Dick <thiebauddick2@aol.com> |
|---|---|
| Date | 2021-12-12 16:19 -0500 |
| Message-ID | <sp5p0u$l4g$1@dont-email.me> |
| In reply to | #163804 |
On 12/12/21 12:38 PM, Kenny McCormack wrote: > In article <861r2h7pu4.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> gazelle@shell.xmission.com (Kenny McCormack) writes: >> >>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> ... >>> >>>>> Well, that is your opinion. >>>> >>>> More accurately, it is my belief. >>> >>> There is no difference between an opinion and a belief. >> >> There is in the way that I use these two words. > > Give me an example of how you could have an opinion about something and not > have it be your belief. > > And/or vice versa. > There's a difference in how most people use the words.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2021-12-13 08:06 +0000 |
| Message-ID | <sp6uu2$1q2vn$1@news.xmission.com> |
| In reply to | #163807 |
In article <sp5p0u$l4g$1@dont-email.me>, Dick <thiebauddick2@aol.com> wrote: >On 12/12/21 12:38 PM, Kenny McCormack wrote: >> In article <861r2h7pu4.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> gazelle@shell.xmission.com (Kenny McCormack) writes: >>> >>>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> ... >>>> >>>>>> Well, that is your opinion. >>>>> >>>>> More accurately, it is my belief. >>>> >>>> There is no difference between an opinion and a belief. >>> >>> There is in the way that I use these two words. >> >> Give me an example of how you could have an opinion about something and not >> have it be your belief. >> >> And/or vice versa. >> >There's a difference in how most people use the words. But, nobody can say what that difference is... Anyway, I say otherwise, but for reasons beyond the scope of this post. -- Elect a clown, expect a circus.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2021-12-13 01:30 -0800 |
| Message-ID | <c1b7db0f-55a6-4424-ab8f-687e19dc10e9n@googlegroups.com> |
| In reply to | #163810 |
On Monday, 13 December 2021 at 08:06:37 UTC, Kenny McCormack wrote: > In article <sp5p0u$l4g$1...@dont-email.me>, Dick <thieba...@aol.com> wrote: > >On 12/12/21 12:38 PM, Kenny McCormack wrote: > >> In article <861r2h7...@linuxsc.com>, > >> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote: > >>> gaz...@shell.xmission.com (Kenny McCormack) writes: > >>> > >>>> In article <86h7bf6...@linuxsc.com>, > >>>> Tim Rentsch <tr.1...@z991.linuxsc.com> wrote: > >>>> ... > >>>> > >>>>>> Well, that is your opinion. > >>>>> > >>>>> More accurately, it is my belief. > >>>> > >>>> There is no difference between an opinion and a belief. > >>> > >>> There is in the way that I use these two words. > >> > >> Give me an example of how you could have an opinion about something and not > >> have it be your belief. > >> > >> And/or vice versa. > >> > >There's a difference in how most people use the words. > But, nobody can say what that difference is... > > Anyway, I say otherwise, but for reasons beyond the scope of this post. > You don't get exact synonyms in a natural language. One form always acquires certain overtones that the other lacks. It may be archaic, or associated with a different dialect, or it might have a subtle shade of meaning. "Opinions" are less serious, less stable and deep seated than beliefs. So "his Buddhist beliefs" but not "his Buddhist opinions", unless you wish to question the seriousness of someone's Buddhism.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2021-12-13 09:34 +0100 |
| Message-ID | <sp70ic$j7p$1@dont-email.me> |
| In reply to | #163807 |
On 12/12/2021 22:19, Dick wrote: > On 12/12/21 12:38 PM, Kenny McCormack wrote: >> In article <861r2h7pu4.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> gazelle@shell.xmission.com (Kenny McCormack) writes: >>> >>>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> ... >>>> >>>>>> Well, that is your opinion. >>>>> >>>>> More accurately, it is my belief. >>>> >>>> There is no difference between an opinion and a belief. >>> >>> There is in the way that I use these two words. >> >> Give me an example of how you could have an opinion about something >> and not >> have it be your belief. >> >> And/or vice versa. >> > There's a difference in how most people use the words. The more relevant point would be how Tim differentiates between the words. Clearly it was important to him. Equally clearly, people have subtly different ideas about what the words mean to /them/, and whether there is a significant difference between them. (There is, unfortunately, no standards document for the English language.) If Tim wants more people to appreciate what exactly he meant, then he'll have to elaborate. If he doesn't care about what others think (and my guess is that Kenny was added to Tim's naughty list long before I was), he'll not bother.
[toc] | [prev] | [next] | [standalone]
| From | Robert Latest <boblatest@yahoo.com> |
|---|---|
| Date | 2021-12-13 18:53 +0000 |
| Message-ID | <j1pj4fFq3mbU3@mid.individual.net> |
| In reply to | #163807 |
Dick wrote: >>>>>> Well, that is your opinion. >>>>> >>>>> More accurately, it is my belief. >>>> >>>> There is no difference between an opinion and a belief. >>> >>> There is in the way that I use these two words. >> >> Give me an example of how you could have an opinion about something and not >> have it be your belief. >> >> And/or vice versa. >> > There's a difference in how most people use the words. Is that your opinion or your belief?
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2021-12-13 20:38 +0000 |
| Message-ID | <sp8b0u$1qnvg$1@news.xmission.com> |
| In reply to | #163828 |
In article <j1pj4fFq3mbU3@mid.individual.net>, Robert Latest <boblatest@yahoo.com> wrote: >Dick wrote: >>>>>>> Well, that is your opinion. >>>>>> >>>>>> More accurately, it is my belief. >>>>> >>>>> There is no difference between an opinion and a belief. >>>> >>>> There is in the way that I use these two words. >>> >>> Give me an example of how you could have an opinion about something and not >>> have it be your belief. >>> >>> And/or vice versa. >>> >> There's a difference in how most people use the words. > >Is that your opinion or your belief? Apparently, both. And that's basically my point. Anyway, and for what it's worth, I basically reserve the word "belief" for matters of religion (where, by religion, I actually mean any situation where people believe a thing with no evidence). Anything else is an opinion. And, in terms of the words, I would use, I would usually say "Well, I think that ...". Very rarely, would I say "I believe that ..." (unless I was in the area of religion). -- The last time a Republican cared about you, you were a fetus.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-12-15 00:38 -0800 |
| Message-ID | <86v8zq460v.fsf@linuxsc.com> |
| In reply to | #163804 |
gazelle@shell.xmission.com (Kenny McCormack) writes: > In article <861r2h7pu4.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> gazelle@shell.xmission.com (Kenny McCormack) writes: >> >>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> ... >>> >>>>> Well, that is your opinion. >>>> >>>> More accurately, it is my belief. >>> >>> There is no difference between an opinion and a belief. >> >> There is in the way that I use these two words. > > Give me an example of how you could have an opinion about > something and not have it be your belief. > > And/or vice versa. Don't you think it would be better first to try to find out the sense in which I mean the two words, rather than steering the discussion towards a pointless and futile argument?
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2021-12-15 11:21 +0000 |
| Message-ID | <spcj3c$1ss42$1@news.xmission.com> |
| In reply to | #163842 |
In article <86v8zq460v.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >gazelle@shell.xmission.com (Kenny McCormack) writes: > >> In article <861r2h7pu4.fsf@linuxsc.com>, >> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >> >>> gazelle@shell.xmission.com (Kenny McCormack) writes: >>> >>>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>> ... >>>> >>>>>> Well, that is your opinion. >>>>> >>>>> More accurately, it is my belief. >>>> >>>> There is no difference between an opinion and a belief. >>> >>> There is in the way that I use these two words. >> >> Give me an example of how you could have an opinion about >> something and not have it be your belief. >> >> And/or vice versa. > >Don't you think it would be better first to try to find out the >sense in which I mean the two words, rather than steering the >discussion towards a pointless and futile argument? I have been doing exactly that - trying to get you to explain how, in your terms, the words differ in meaning. My own view is that while the words are effectively synonyms, people tend to use each of them in different contexts. As I said earlier, to me, a "belief" is an opinion not backed by evidence. Usually, these "beliefs" are in the general area of religion - you know, virgin births, talking snakes, 6Kyo Earth, etc. -- To be evangelical is to spend every waking moment hovering around two emotional states: fear and rage. Evangelicals are seriously the angriest and most vicious bunch of self-pitying, constantly-moaning whinybutts I've ever encountered.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2021-12-15 10:26 -0800 |
| Message-ID | <86r1ad4td2.fsf@linuxsc.com> |
| In reply to | #163844 |
gazelle@shell.xmission.com (Kenny McCormack) writes: > In article <86v8zq460v.fsf@linuxsc.com>, > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> gazelle@shell.xmission.com (Kenny McCormack) writes: >> >>> In article <861r2h7pu4.fsf@linuxsc.com>, >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> gazelle@shell.xmission.com (Kenny McCormack) writes: >>>> >>>>> In article <86h7bf6vhd.fsf@linuxsc.com>, >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> ... >>>>> >>>>>>> Well, that is your opinion. >>>>>> >>>>>> More accurately, it is my belief. >>>>> >>>>> There is no difference between an opinion and a belief. >>>> >>>> There is in the way that I use these two words. >>> >>> Give me an example of how you could have an opinion about >>> something and not have it be your belief. >>> >>> And/or vice versa. >> >> Don't you think it would be better first to try to find out the >> sense in which I mean the two words, rather than steering the >> discussion towards a pointless and futile argument? > > I have been doing exactly that - trying to get you to explain how, > in your terms, the words differ in meaning. Ahh. In that case, I believe that every even number greater than two is the sum of two primes.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-12-15 10:45 -0800 |
| Message-ID | <87mtl19074.fsf@nosuchdomain.example.com> |
| In reply to | #163842 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Don't you think it would be better first to try to find out the
> sense in which I mean the two words, rather than steering the
> discussion towards a pointless and futile argument?
No, because you've passed up numerous opportunities to explain what
you mean. If you had wanted to avoid "a pointless and futile
argument", you could have done so easily.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-12-10 10:52 -0800 |
| Message-ID | <871r2kb8cp.fsf@nosuchdomain.example.com> |
| In reply to | #163761 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> Anyone who seriously proposes having to supply a size argument to
> free memory for a general purpose allocator like malloc() either
> hasn't bothered to think or doesn't know how to think. Kind of
> par for the course for the long-running Bart and David show.
Tim, it's sad to see this kind of crap from you. I remember when you
had interesting things to say here.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Guillaume <message@bottle.org> |
|---|---|
| Date | 2021-11-22 04:06 +0100 |
| Message-ID | <snf1gn$r3q$1@gioia.aioe.org> |
| In reply to | #163554 |
Le 21/11/2021 à 21:51, David Brown a écrit : > No. It merely relieves the heap implementation from having to store the > size of the allocation. Any other metadata (such as for tracking free > space lists, or handling efficient multi-threaded access) will still be > needed. > >> I believe there are countless implementations of malloc out there, and I >> guess this might not be the case, or it may be the case today but not >> tomorrow. Of all the typical implementations of malloc() and similar general-purpose allocators, I've always seen the same approach of storing metadata either right before (with then the appropriate padding if required), or right after the actual usable block of memory. In a number of cases, the metadata is even duplicated both before and after the block - for data locality reasons. This can be more efficient cache-wise.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-11-22 11:32 +0000 |
| Message-ID | <snfv3u$qc1$1@dont-email.me> |
| In reply to | #163559 |
On 22/11/2021 03:06, Guillaume wrote: > Le 21/11/2021 à 21:51, David Brown a écrit : >> No. It merely relieves the heap implementation from having to store the >> size of the allocation. Any other metadata (such as for tracking free >> space lists, or handling efficient multi-threaded access) will still be >> needed. >> >>> I believe there are countless implementations of malloc out there, and I >>> guess this might not be the case, or it may be the case today but not >>> tomorrow. > > > Of all the typical implementations of malloc() and similar > general-purpose allocators, I've always seen the same approach of > storing metadata either right before (with then the appropriate padding > if required), or right after the actual usable block of memory. In a > number of cases, the metadata is even duplicated both before and after > the block - for data locality reasons. This can be more efficient > cache-wise. Have you considered the reason why such implementations need to store such metadata at all? Namely, because the specification says that malloc must record the size simply so that free() will know what it is!
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2021-11-22 13:00 -0800 |
| Message-ID | <87ee77j47i.fsf@nosuchdomain.example.com> |
| In reply to | #163567 |
Bart <bc@freeuk.com> writes:
> On 22/11/2021 03:06, Guillaume wrote:
>> Le 21/11/2021 à 21:51, David Brown a écrit :
>>> No. It merely relieves the heap implementation from having to store the
>>> size of the allocation. Any other metadata (such as for tracking free
>>> space lists, or handling efficient multi-threaded access) will still be
>>> needed.
>>>
>>>> I believe there are countless implementations of malloc out there, and I
>>>> guess this might not be the case, or it may be the case today but not
>>>> tomorrow.
>>
>> Of all the typical implementations of malloc() and similar
>> general-purpose allocators, I've always seen the same approach of
>> storing metadata either right before (with then the appropriate
>> padding if required), or right after the actual usable block of
>> memory. In a number of cases, the metadata is even duplicated both
>> before and after the block - for data locality reasons. This can be
>> more efficient cache-wise.
>
> Have you considered the reason why such implementations need to store
> such metadata at all?
>
> Namely, because the specification says that malloc must record the
> size simply so that free() will know what it is!
There's no explicit requirement for free() to know the size of the
record being deallocated. It likely will in most implementations,
but I can imagine an implementation where deallocation doesn't
require knowing the size.
One example: malloc() may allocate more size than was asked for, and
remember only the actual allocated size, not the requested size.
Or the allocated size might change after allocation if a following
block is freed. (But realloc() does make it convenient to have some
idea of what was requested.)
Or malloc() and free() might be implemented on top of some lower
level interface that doesn't expose that information.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2021-11-21 13:08 -0800 |
| Message-ID | <snecgg$og6$2@dont-email.me> |
| In reply to | #163547 |
On 11/21/2021 5:51 AM, David Brown wrote: > On 21/11/2021 02:44, Richard Damon wrote: >> On 11/20/21 7:19 PM, Bart wrote: > >>> It doesn't make sense. > > I don't want to make a habit of it, but I agree with Bart here :-) > >> >> Maybe not to you, but I would sure hate to have to keep track of all >> that data, and would likely just wrap this dumb malloc with something >> smarter. > > And that is /fine/. For those few cases where it might be inconvenient > to know the size at deallocation time, make a wrapper so that the size > is tracked. If you need that functionality, write the code and pay the > price - others that don't need the heap to record their allocation sizes > shouldn't have to pay for your needs. It is no different from malloc > and calloc - if you want the convenience of zeroing the memory, you can > use calloc, but if you don't want it you can use malloc and not pay for > the extra effort. For some reason this is making me think of a bug I found in MSVC: https://groups.google.com/g/comp.lang.c++/c/48Tm8j8ag-0/m/VYI8rvB9vIwJ > > Of course it is too late to make such untracked-size heap functions the > standard for C - I see it as an unlucky choice made long ago. After > all, if you had "malloc_untracked" and "free_untracked" then it would be > a simple matter to implement traditional C "malloc" and "free" on top of it. > >> >> If you need a lot of a fixed sized blocks, there are lots of algorithms >> that work well for that with much less or zero overhead (if the blocks >> are big enough for a pointer) > > Yes, of course there are many ways of efficiently handling fixed size > blocks. But it would be more convenient if the common heap system > didn't have this particular inefficiency. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2021-11-20 20:44 -0500 |
| Message-ID | <LvhmJ.55057$np6.17637@fx46.iad> |
| In reply to | #163534 |
On 11/20/21 7:19 PM, Bart wrote: > On 20/11/2021 23:52, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 19/11/2021 21:52, Keith Thompson wrote: >> [...] >>>> Perhaps -- but typically that information is not stored in the pointer >>>> itself. If it were, all void* values would have to store that extra >>>> information. >>>> >>>> (I think it's easier to store bookkeeping data before the allocated >>>> space. If you store it after the space, it's hard to know where it >>>> is.) >>> >>> That's the most common way for a simple malloc/free system. >>> >>> It has always struck me as a mistake that C did things that way - in my >>> opinion, "free" should have taken an additional parameter of the size >>> for the deallocation. >> >> Meh. That would have introduced another rich source of programming >> errors (passing the wrong size). > > You could also pass the wrong size to malloc, or the wrong pointer to free. > >> Probably most implementations would >> have kept track of the size anyway, so they could detect errors. > > I doubt that, unless it's for debugging mode. > > If an application needs to allocate 100 million 32-byte nodes, which > would occupy 3.2GB by themselves, how much extra would be needed for the > size, 'just for checking'? > > On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB > extra just so someone can write: > > free(p); > > instead of: > > free(p, sizeof(treenode)); > > possibly in just one place in the program. > > It doesn't make sense. > Maybe not to you, but I would sure hate to have to keep track of all that data, and would likely just wrap this dumb malloc with something smarter. If you need a lot of a fixed sized blocks, there are lots of algorithms that work well for that with much less or zero overhead (if the blocks are big enough for a pointer)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-11-21 12:22 +0000 |
| Message-ID | <snddlt$684$1@dont-email.me> |
| In reply to | #163539 |
On 21/11/2021 01:44, Richard Damon wrote: > On 11/20/21 7:19 PM, Bart wrote: >> On 20/11/2021 23:52, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 19/11/2021 21:52, Keith Thompson wrote: >>> [...] >>>>> Perhaps -- but typically that information is not stored in the pointer >>>>> itself. If it were, all void* values would have to store that extra >>>>> information. >>>>> >>>>> (I think it's easier to store bookkeeping data before the allocated >>>>> space. If you store it after the space, it's hard to know where it >>>>> is.) >>>> >>>> That's the most common way for a simple malloc/free system. >>>> >>>> It has always struck me as a mistake that C did things that way - in my >>>> opinion, "free" should have taken an additional parameter of the size >>>> for the deallocation. >>> >>> Meh. That would have introduced another rich source of programming >>> errors (passing the wrong size). >> >> You could also pass the wrong size to malloc, or the wrong pointer to >> free. >> >>> Probably most implementations would >>> have kept track of the size anyway, so they could detect errors. >> >> I doubt that, unless it's for debugging mode. >> >> If an application needs to allocate 100 million 32-byte nodes, which >> would occupy 3.2GB by themselves, how much extra would be needed for >> the size, 'just for checking'? >> >> On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB >> extra just so someone can write: >> >> free(p); >> >> instead of: >> >> free(p, sizeof(treenode)); >> >> possibly in just one place in the program. >> >> It doesn't make sense. >> > > Maybe not to you, but I would sure hate to have to keep track of all > that data, and would likely just wrap this dumb malloc with something > smarter. I still don't understand why you have to keep track of /allocated/ blocks. Once allocated, they belong to the application; why does the allocator need to care about them? Once deallocated, or before they are allocated, then the allocator can do what it likes with them. But it can use data within the blocks: it doesn't need any extra space. (Unless the block is tiny, like one byte, then it will have to impose a minimum size.) > If you need a lot of a fixed sized blocks, there are lots of algorithms > that work well for that with much less or zero overhead (if the blocks > are big enough for a pointer) Lots of same-sized blocks you mean? Then sure, there are all sorts of custom allocators that could be used. Including the case where you know that you will never free memory so there is no point wasting time and space with housekeeping information. But this is about the general purpose allocator provided by with malloc and free. You can always add a 'better' allocator on top that uses extra overheads; it's harder the other way around.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2021-11-20 20:13 -0700 |
| Message-ID | <1bfsrqkxoz.fsf@pfeifferfamily.net> |
| In reply to | #163534 |
Bart <bc@freeuk.com> writes: > On 20/11/2021 23:52, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 19/11/2021 21:52, Keith Thompson wrote: >> [...] >>>> Perhaps -- but typically that information is not stored in the pointer >>>> itself. If it were, all void* values would have to store that extra >>>> information. >>>> >>>> (I think it's easier to store bookkeeping data before the allocated >>>> space. If you store it after the space, it's hard to know where it is.) >>> >>> That's the most common way for a simple malloc/free system. >>> >>> It has always struck me as a mistake that C did things that way - in my >>> opinion, "free" should have taken an additional parameter of the size >>> for the deallocation. >> Meh. That would have introduced another rich source of programming >> errors (passing the wrong size). > > You could also pass the wrong size to malloc, or the wrong pointer to free. > >> Probably most implementations would >> have kept track of the size anyway, so they could detect errors. > > I doubt that, unless it's for debugging mode. > > If an application needs to allocate 100 million 32-byte nodes, which > would occupy 3.2GB by themselves, how much extra would be needed for > the size, 'just for checking'? If that's what you're doing, you shouldn't be using malloc() for the individual nodes. > On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB > extra just so someone can write: > > free(p); > > instead of: > > free(p, sizeof(treenode)); > > possibly in just one place in the program. > > It doesn't make sense. Remember, you have to have all the data structures to keep track of the allocated space so malloc() will work. I expect that requirement will eat up close to that much space anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2021-11-21 12:35 +0000 |
| Message-ID | <sndeel$atj$1@dont-email.me> |
| In reply to | #163541 |
On 21/11/2021 03:13, Joe Pfeiffer wrote: > Bart <bc@freeuk.com> writes: > >> On 20/11/2021 23:52, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>>> On 19/11/2021 21:52, Keith Thompson wrote: >>> [...] >>>>> Perhaps -- but typically that information is not stored in the pointer >>>>> itself. If it were, all void* values would have to store that extra >>>>> information. >>>>> >>>>> (I think it's easier to store bookkeeping data before the allocated >>>>> space. If you store it after the space, it's hard to know where it is.) >>>> >>>> That's the most common way for a simple malloc/free system. >>>> >>>> It has always struck me as a mistake that C did things that way - in my >>>> opinion, "free" should have taken an additional parameter of the size >>>> for the deallocation. >>> Meh. That would have introduced another rich source of programming >>> errors (passing the wrong size). >> >> You could also pass the wrong size to malloc, or the wrong pointer to free. >> >>> Probably most implementations would >>> have kept track of the size anyway, so they could detect errors. >> >> I doubt that, unless it's for debugging mode. >> >> If an application needs to allocate 100 million 32-byte nodes, which >> would occupy 3.2GB by themselves, how much extra would be needed for >> the size, 'just for checking'? > > If that's what you're doing, you shouldn't be using malloc() for the > individual nodes. Why not; isn't that exactly what it's for? And what is the alternative, to create a custom allocator? >> On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB >> extra just so someone can write: >> >> free(p); >> >> instead of: >> >> free(p, sizeof(treenode)); >> >> possibly in just one place in the program. >> >> It doesn't make sense. > > Remember, you have to have all the data structures to keep track of the > allocated space so malloc() will work. Everyone is saying this; no one is explaining exactly why it needs to! Are you saying that, unless an allocated block is tagged with a size, malloc has no idea which pool memory has been allocated and which hasn't? I've written a few allocators over the years, they have never needed to record the size of a block.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2021-11-21 10:53 -0700 |
| Message-ID | <1bbl2dl7j2.fsf@pfeifferfamily.net> |
| In reply to | #163545 |
Bart <bc@freeuk.com> writes: > On 21/11/2021 03:13, Joe Pfeiffer wrote: >> Bart <bc@freeuk.com> writes: >>> >>> If an application needs to allocate 100 million 32-byte nodes, which >>> would occupy 3.2GB by themselves, how much extra would be needed for >>> the size, 'just for checking'? >> If that's what you're doing, you shouldn't be using malloc() for the >> individual nodes. > > Why not; isn't that exactly what it's for? Because it isn't optimized for a use case like that. It's a general purpose allocator, and you're using it for a situation that's 'way out on the fringes. > And what is the alternative, to create a custom allocator? Yes. When I've had similar situations I've allocated large blocks with malloc() and then allocated my little blocks from the big ones. >>> On my machine that seems to be 16 bytes per node, so 50% more. 1.6GB >>> extra just so someone can write: >>> >>> free(p); >>> >>> instead of: >>> >>> free(p, sizeof(treenode)); >>> >>> possibly in just one place in the program. >>> >>> It doesn't make sense. >> Remember, you have to have all the data structures to keep track of >> the >> allocated space so malloc() will work. > > Everyone is saying this; no one is explaining exactly why it needs to! > > Are you saying that, unless an allocated block is tagged with a size, > malloc has no idea which pool memory has been allocated and which > hasn't? > > I've written a few allocators over the years, they have never needed > to record the size of a block.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web