Am 18.06.2024 um 01:39 schrieb Keith Thompson:

> I have a small test program that uses realloc() to expand a 1-byte
> allocated buffer to 2 bytes, then 3, then 4, and so on. In one
> implementation, in one test run, it reallocates at 25 bytes, and
> then not again until just over 128 kbytes. Other implementations
> behave differently.

Usually you don't expand a dynamic array byte per byte. Normaly you
expand it like a C++ vector whose capacity doubles with libstdc++
and libc++ (MSVC adds 50% to the capacity before).

On Mon, 17 Jun 2024 08:08:07 +0200, Janis Papanagnou
<janis_papanagnou+ng@hotmail.com> wrote:

>In a recent thread realloc() was a substantial part of the discussion.
>"Occasionally" the increased data storage will be relocated along
>with the previously stored data. On huge data sets that might be a
>performance factor. Is there any experience or are there any concrete
>factors about the conditions when this relocation happens? - I could
>imagine that it's no issue as long as you're in some kB buffer range,
>but if, say, we're using realloc() to substantially increase buffers
>often it might be an issue to consider. It would be good to get some
>feeling about that internal.
>
>Janis

the only problem i see it is the memory that is free is the first has
to be used, or be returned from malloc or realloc, because that memory
is already in a good position near the cpu

On 18/06/2024 08:09, Tim Rentsch wrote:
> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>
>> Ben Bacarisse to Malcolm McLean:
>>
>>> [next is a comment from Malcolm]
>>>
>>>> Your strategy for avoiding these extremes is exponential
>>>> growth.
>>>
>>> It's odd to call it mine. It's very widely know and used.
>>> "The one I mentioned" might be less confusing description.
>>
>> I think it is a modern English idiom, which I dislike as
>> well. StackOverflow is full of questions starting like:
>> "How do you do this?" and "How do I do that?" They are
>> informal ways of the more literary "How does one do this?"
>> or "What is the way to do that?"
>
> I have a different take here. First the "your" of "your
> strategy" reads as a definite pronoun, meaning it refers
> specifically to Ben and not to some unknown other party.
> (And incidentally is subtly insulting because of that,
> whether it was meant that way or not.)
>
> Second the use of "you" to mean an unspecified other person
> is not idiom but standard usage. The word "you" is both a
> definite pronoun and an indefinite pronoun, depending on
> context. The word "they" also has this property. Consider
> these two examples:
>
> The bank downtown was robbed. They haven't been caught
> yet.
>
> They say the sheriff isn't going to run for re-election.
>
> In the first example "they" is a definite pronoun, referring
> to the people who robbed the bank. In the second example,
> "they" is an indefinite pronoun, referring to unspecified
> people in general (perhaps but not necessarily everyone).
> The word "you" is similar: it can mean specifically the
> listener, or it can mean generically anyone in a broader
> audience, even those who never hear or read the statement
> with "you" in it.
>
> The word "one" used as a pronoun is more formal, and to me
> at least often sounds stilted. In US English "one" is most
> often an indefinite pronoun, either second person or third
> person. But "one" can also be used as a first person
> definite pronoun (referring to the speaker), which an online
> reference tells me is chiefly British English. (I would
> guess that this usage predominates in "the Queen's English"
> dialect of English, but I have very little experience in
> such things.)
>
> Finally I would normally read "I" as a first person definite
> pronoun, and not an indefinite pronoun. So I don't have any
> problem with someone saying "how should I ..." when asking
> for advice. They aren't asking how someone else should ...
> but how they should ..., and what advice I might give could
> very well depend on who is doing the asking.

Ben said
> Restore snipped Ben upthread
"In practice, the cost is usually
moderate and can be very effectively managed by using an exponential
allocation scheme: at every reallocation multiply the storage space by
some factor greater than 1 (I often use 3/2, but doubling is often used
as well)."

So it's open and shut, and no two ways about it. Ben's strategy is
exponential growth. And to be fair I use that strategy myself in
functions like fslutp(). It's only not Ben's strategy if we mean to
imply that Ben was the first person to use expoential growth, or the
first to understand the mathematical implications, and of course that's
not the case. It was all worked out by Euler long before any of us were
born.

The question is whether we can be a bit more rigorous than "we need
exonential growth, let's double on each reallocation. Actually, that
looks a bit greedy. Try 3/2". And we can do that. We can put it on a
sounder statistical footing. Whether it actually worth it or not is a
different matter.

--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

On 18/06/2024 11:19, Malcolm McLean wrote:
> On 18/06/2024 08:09, Tim Rentsch wrote:
>> Anton Shepelev <anton.txt@g{oogle}mail.com> writes:
>>
>>> Ben Bacarisse to Malcolm McLean:
>>>
>>>> [next is a comment from Malcolm]
>>>>
>>>>> Your strategy for avoiding these extremes is exponential
>>>>> growth.
>>>>
>>>> It's odd to call it mine.  It's very widely know and used.
>>>> "The one I mentioned" might be less confusing description.
>>>
>>> I think it is a modern English idiom, which I dislike as
>>> well.  StackOverflow is full of questions starting like:
>>> "How do you do this?" and "How do I do that?"  They are
>>> informal ways of the more literary "How does one do this?"
>>> or "What is the way to do that?"
>>
>> I have a different take here.  First the "your" of "your
>> strategy" reads as a definite pronoun, meaning it refers
>> specifically to Ben and not to some unknown other party.
>> (And incidentally is subtly insulting because of that,
>> whether it was meant that way or not.)
>>
>> Second the use of "you" to mean an unspecified other person
>> is not idiom but standard usage.  The word "you" is both a
>> definite pronoun and an indefinite pronoun, depending on
>> context.  The word "they" also has this property.  Consider
>> these two examples:
>>
>>     The bank downtown was robbed.  They haven't been caught
>>     yet.
>>
>>     They say the sheriff isn't going to run for re-election.
>>
>> In the first example "they" is a definite pronoun, referring
>> to the people who robbed the bank.  In the second example,
>> "they" is an indefinite pronoun, referring to unspecified
>> people in general (perhaps but not necessarily everyone).
>> The word "you" is similar:  it can mean specifically the
>> listener, or it can mean generically anyone in a broader
>> audience, even those who never hear or read the statement
>> with "you" in it.
>>
>> The word "one" used as a pronoun is more formal, and to me
>> at least often sounds stilted.  In US English "one" is most
>> often an indefinite pronoun, either second person or third
>> person.  But "one" can also be used as a first person
>> definite pronoun (referring to the speaker), which an online
>> reference tells me is chiefly British English.  (I would
>> guess that this usage predominates in "the Queen's English"
>> dialect of English, but I have very little experience in
>> such things.)
>>
>> Finally I would normally read "I" as a first person definite
>> pronoun, and not an indefinite pronoun.  So I don't have any
>> problem with someone saying "how should I ..." when asking
>> for advice.  They aren't asking how someone else should ...
>> but how they should ..., and what advice I might give could
>> very well depend on who is doing the asking.
>
> Ben said
> > Restore snipped Ben upthread
> "In practice, the cost is usually
> moderate and can be very effectively managed by using an exponential
> allocation scheme: at every reallocation multiply the storage space by
> some factor greater than 1 (I often use 3/2, but doubling is often used
> as well)."
>
> So it's open and shut, and no two ways about it. Ben's strategy is
> exponential growth. And to be fair I use that strategy myself in
> functions like fslutp(). It's only not Ben's strategy if we mean to
> imply that Ben was the first person to use expoential growth, or the
> first to understand the mathematical implications, and of course that's
> not the case. It was all worked out by Euler long before any of us were
> born.
>
> The question is whether we can be a bit more rigorous than "we need
> exonential growth, let's double on each reallocation. Actually, that
> looks a bit greedy. Try 3/2". And we can do that. We can put it on a
> sounder statistical footing. Whether it actually worth it or not is a
> different matter.
>
Here are some real stats on file sizes, in case anone is interested.

Data set, / OS Log-normal median & mean, Arithmetic mean, 50% occupied by
(< mean)

whole data set, 9.0 KB, 730 KB, 1.5 MB < 5.4 KB
Mac OS 8.0 KB, 533 KB, 1.4 MB < 4.9 KB
Windows 11.5 KB, 1.0 MB, 1.7 MB < 8.3 KB
GNU/Linux 10.8 KB, 1.7MB, 2.2 MB < 4.8 KB

https://www.researchgate.net/publication/353066615_How_Big_Are_Peoples%27_Computer_Files_File_Size_Distributions_Among_User-managed_Collections

--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

Anton Shepelev wrote:

> [cross-posted to: ci.stat.math]
>
> Malcolm McLean:
>
> > We have a continuously growing buffer, and we want the
> > best strategy for reallocations as the stream of
> > characters comes at us. So, given we now how many
> > characters have arrived, can we predict how many will
> > arrive,
>
> Do you mean in the next bunch, or in total (till the end of
> the buffer's lifetime)?
>
> > and therefore ask for the best amount when we reallocate,
> > so that we neither make too many reallocation (reallocate
> > on every byte received) or ask for too much (demand
> > SIZE_MAX memory when the first byte is received).?
> >
> > Your strategy for avoiding these extremes is exponential
> > growth. You allocate a small amount for the first few
> > bytes. Then you use exponential growth, with a factor of
> > ether 2 or 1.5.
>
> This strategy ensures a constant ratio between the amount of
> reallocated data to the length of the buffer by making
> reallocations less frequent as the buffer grows.
>
> > And so we integrate the distribution between the point we
> > are at and infinity. Then we tkae the mean. And that gives
> > us a best estimate of how many bytes are to come, and
> > therefore how much to grow the buffer by.
>
> You have an apriori distribution of the buffer size (can be
> tracked on-the-fly, if unknown beforehand) and a partially
> filled buffer. The task is to calculate the a-posteriori
> distribution of that buffer's final size, and then to
> allocate the predicted value based on a good percentile.
>
> How about using a percentile instead of the mean, e.g. if
> the current size corresponds to percentile p, you allocate a
> capacity corresponding to percentile 1-(1-p)/k , where k>1
> denotes the balance between space and time efficency. For
> example, if the 60th percentile of the buffer is required
> and k=2, you allocate a capacity sufficient to hold
> 100-(100-60)/2=80% of buffers.

Based on essentially no background to this question, not much can be
said. However, if one starts from the suggestion above to use the mean
of some distribution (or later some percentile), one notes that the
"mean" is just the minimum of a quadratic cast function ,,, so an
improvement would be to base the choice on some more realistic cost
function, chosen for the actual application. Given that the scenario
apparently involves a sequence of such decisions, the obvious extension
of the cost-based approach would be to employ some form of dynamic
programming. Of course, this might not be appealing, in which case one
might choose the theoretically-simple approach of tuning a policy based
on good stchastic simulations of the situation.

In sci.stat.math Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
> [cross-posted to: ci.stat.math]
>
> Malcolm McLean:
>
>> We have a continuously growing buffer, and we want the
>> best strategy for reallocations as the stream of
>> characters comes at us. So, given we now how many
>> characters have arrived, can we predict how many will
>> arrive,
>
> Do you mean in the next bunch, or in total (till the end of
> the buffer's lifetime)?
>
Isn't this a halting problem? Aren't the more important data:
how much memory the user is allowed to allocate, the properties of
the current system's memory allocation algorithm, when your stream
will have to go to disc or other slow large volume storage, how
the stream can be compressed on the fly (the latter might well give
strong predictions for future storage requirements based on what
has been read to date).

On 19/06/2024 07:48, David Duffy wrote:
> In sci.stat.math Anton Shepelev <anton.txt@g{oogle}mail.com> wrote:
>> [cross-posted to: ci.stat.math]
>>
>> Malcolm McLean:
>>
>>> We have a continuously growing buffer, and we want the
>>> best strategy for reallocations as the stream of
>>> characters comes at us. So, given we now how many
>>> characters have arrived, can we predict how many will
>>> arrive,
>>
>> Do you mean in the next bunch, or in total (till the end of
>> the buffer's lifetime)?
>>
> Isn't this a halting problem? Aren't the more important data:
> how much memory the user is allowed to allocate, the properties of
> the current system's memory allocation algorithm, when your stream
> will have to go to disc or other slow large volume storage, how
> the stream can be compressed on the fly (the latter might well give
> strong predictions for future storage requirements based on what
> has been read to date).
>
>
No. We have to have some knowledge. And what we probaby know is that the
input is a file stored on someone's personal computer. And someone has
published on the statistical distribution of such files And they have a
log-normal distribution with a mean and a median which he gives. So with
that informaton, we can work out, given that a file is at least N
characters, what is the prbablity that an allocation of any size will
contain the whole file, and how many bytes, on average will be wasted.

Statistical analysis can't tell us what a allocation wil cost versus the
cost of hoggng memory we don't need, however. It can;t tell us what to
do. Just put us in the picture.
--
Check out my hobby project.
http://malcolmmclean.github.io/babyxrc

Malcolm McLean writes that, given the log-normal distribution
of file sizes with known parameters,

> we can work out, given that a file is at least N
> characters, what is the prbablity that an allocation of
> any size will contain the whole file, and how many bytes,
> on average will be wasted.

This is why I thought statisticians might help him: Malcolm
wants to find the aposteriori distribution of the size of a
file, after it has been found to exceed N bytes. Am I right
that if we take the remaining (N>20) part of the density
function and re-normalise it, we shall obtain the desired
distribution?

My proposition was as follows:

1. Find quantile q0 corresponding to the buffer size
currently requested.

2. Calculate new quantile q1 = 1-(1-q0)/k, where k>1 is
an adjustable parameter, and use its corresponding
value as the new allocation size.

For example, assuming for simplicity a uniform [0,20]
distribution of file sizez and k=2, a sequence of allocation
may look like this:

requested allocated
2 20-(20- 2)/2 = 11
12 20-(20-12)/2 = 16
18 20-(20-18)/2 = 19
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> No. We have to have some knowledge. And what we probaby know is that the
> input is a file stored on someone's personal computer. And someone has
> published on the statistical distribution of such files

That's not the case that matters (to me at least). If the input is a
file, we have a much better way of "guessing" the size than guessing and
growing -- just ask for the size. Sure, we might need to make
adjustments if the file is changing, but there is always a better
measure than any statistical analysis.

To some extent this seems like a solution in search of a problem.
Growing the buffer exponentially is simple and effective.

--
Ben.

On 19/06/2024 17:36, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> No. We have to have some knowledge. And what we probaby know is that the
>> input is a file stored on someone's personal computer. And someone has
>> published on the statistical distribution of such files
>
> That's not the case that matters (to me at least). If the input is a
> file, we have a much better way of "guessing" the size than guessing and
> growing -- just ask for the size. Sure, we might need to make
> adjustments if the file is changing, but there is always a better
> measure than any statistical analysis.
>
> To some extent this seems like a solution in search of a problem.

It seems more like a solution that doesn't exist in search of a problem
with absurdly unrealistic requirements. And even if Malcolm's solution
existed, and the problem existed, it /still/ wouldn't work - knowing the
distribution of file sizes tells us nothing about the size of any given
file.

> Growing the buffer exponentially is simple and effective.
>

Yes, that's the general way to handle buffers when you don't know what
size they should be.

A better solutions for this sort of program is usually, as you say,
asking the OS for the file size (there is no standard library function
for getting the file size, but it's not hard to do for any realistic
target OS). And then for big files, prefer mmap to reading the file
into a buffer.

It's only really for unsized "files" such as piped input that you have
no way of getting the size, and then exponential growth is the way to
go. Personally, I'd start with a big size (perhaps 10 MB) that is
bigger than you are likely to need in practice, but small enough that it
is negligible on even vaguely modern computers. Then the realloc code is
unlikely to be used (but it can still be there for completeness).

David Brown <david.brown@hesbynett.no> writes:

> On 19/06/2024 17:36, Ben Bacarisse wrote:
>> Growing the buffer exponentially is simple and effective.
>
> Yes, that's the general way to handle buffers when you don't know what size
> they should be.
>
> A better solutions for this sort of program is usually, as you say, asking
> the OS for the file size (there is no standard library function for getting
> the file size, but it's not hard to do for any realistic target OS). And
> then for big files, prefer mmap to reading the file into a buffer.
>
> It's only really for unsized "files" such as piped input that you have no
> way of getting the size, and then exponential growth is the way to go.
> Personally, I'd start with a big size (perhaps 10 MB) that is bigger than
> you are likely to need in practice, but small enough that it is negligible
> on even vaguely modern computers. Then the realloc code is unlikely to be
> used (but it can still be there for completeness).

There are other uses that have nothing to do with files. I have a small
dynamic array library (just a couple of function) that I use for all
sorts of things. I can read a file or parse tokens or input a line just
by adding characters. Because of its rather general use, I don't start
with a large buffer (though the initial size can be set).

--
Ben.

Malcolm McLean:

> We have to have some knowledge. And what we probaby know
> is that the input is a file stored on someone's personal
> computer. And someone has published on the statistical
> distribution of such files And they have a log-normal
> distribution with a mean and a median which he gives. So
> with that informaton, we can work out, given that a file
> is at least N characters, what is the prbablity that an
> allocation of any size will contain the whole file, and
> how many bytes, on average will be wasted.

Observe that the standard algorithm of exponential growth is
memoryless and self-similar in that in does not depend on
context, or the history of previous reallocations. These
properties belong to (or even identify?) the exponential
distribution. We can therefore assume that exponential-
growth strategy is ideal for exponentially distributed
buffer sizes, and under that assumption determine the
relation between the CDF values (p) corresponding to
consequent re-allcoations:

p = e^x/L ,
p0 = 1-e^(L*x0) ,
p1 = 1-e^(L*x1) ,
x1 = k*x0 (by our strategy), =>
p1 = 1-(1-p0)^k .

which does not depend on the distribution and lets us
generalise this approach for any distribution:

x1 = Q( 1 - ( 1 - CDF(x0) )^k )

where:

x0 : the required size
x1 : the new recommended capacity
Q(p) : the p-Quantile of the given distribution
CDF(x): the CDF of the given distribution
k>1 : balance between speed and space efficiency

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

Cross-posting to alt.english.usage .

Tim Rentsch to Anton Shepelev:

> > I think it is a modern English idiom, which I dislike as
> > well. StackOverflow is full of questions starting like:
> > "How do you do this?" and "How do I do that?" They are
> > informal ways of the more literary "How does one do
> > this?" or "What is the way to do that?"
>
> I have a different take here. First the "your" of "your
> strategy" reads as a definite pronoun, meaning it refers
> specifically to Ben and not to some unknown other party.

And I am /sure/ it is intended in the general (indefinite)
sense, as is the `you' in Malcolm's two following sentences:

> You allocate a small amount for the first few bytes. Then
> you use exponential growth, with a factor of ether 2 or
> 1.5.

This is the typical wording of impersonal instruction in
modern English.

> (And incidentally is subtly insulting because of that,
> whether it was meant that way or not.)

Yes! My first impulse is always to interpret those pronouns
according to their literal (definite) meanings, which gives
the text an insulting (because presumptuos) taint. This is
why I wince at the indefinite useage of first- and second-
person pronouns.

> Second the use of "you" to mean an unspecified other
> person is not idiom but standard usage.

`Idiomatic' can mean `standard':

Of or pertaining to, or conforming to, the mode of
expression peculiar to a language; as, an idiomatic
meaning; an idiomatic phrase.

> The word "you" is both a definite pronoun and an
> indefinite pronoun, depending on context.

It /is/ used as in indefinite pronoun, is not widely
recognised as capable of that function:

https://eslgrammar.org/indefinite-pronouns/
https://dictionary.cambridge.org/grammar/british-grammar/indefinite-pronouns

And when it is, only as an informal relaxation:

https://www.englishclub.com/grammar/pronouns-indefinite.php

These recent informal usages can be ugly.

> The word "they" also has this property.

I know it, and agree:

They took some honey from a tree,
Dressed it up and then called it me.
<https://on.soundcloud.com/NGz7nZgzm4hiQQbd6>

The indefinite `they' can be used formally as well.

> The word "you" is similar: it can mean specifically the
> listener, or it can mean generically anyone in a broader
> audience, even those who never hear or read the statement
> with "you" in it.

Modern teenagers definitely see it that way, and I have to
clench my teech and adapt.

> The word "one" used as a pronoun is more formal, and to me
> at least often sounds stilted. In US English "one" is
> most often an indefinite pronoun, either second person or
> third person.

How can it be a second-person pronoun? The famous phrase
"One never knows, do one?" features a third-person `one'
with a dialectical third-person `do'.

> But "one" can also be used as a first person definite
> pronoun (referring to the speaker), which an online
> reference tells me is chiefly British English.

I had no idea it could, nor does Wikipedia. Can you share
an example of a definite first-person `one'?

> Finally I would normally read "I" as a first person
> definite pronoun, and not an indefinite pronoun.

And so would I, and I hate the indefinte usage.

> So I don't have any problem with someone saying "how
> should I ..." when asking for advice. They aren't asking
> how someone else should ... but how they should ..., and
> what advice I might give could very well depend on who is
> doing the asking.

The problem is, in 99% of cases no personal information is
given that could possibly justify the personal wording of
the question.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On Thu, 20 Jun 2024 02:51:56 +0300, Anton Shepelev <anton.txt@gmail.moc>
wrote in <20240620025156.2ae9300726603b4cb3631547@gmail.moc>:

> Cross-posting to alt.english.usage .

I've set the followup-to: same

>
> Tim Rentsch to Anton Shepelev:
>> But "one" can also be used as a first person definite pronoun
>> (referring to the speaker), which an online reference tells me is
>> chiefly British English.
>
> I had no idea it could, nor does Wikipedia. Can you share an example of
> a definite first-person `one'?

I think that would go something like:

"One wonders how..."

(Also, in some writing, "this one" can replace "I" -- this one used to do
that on Usenet, but was told it was pretentious.)

--
-v

On 19/06/2024 23:24, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 19/06/2024 17:36, Ben Bacarisse wrote:
>>> Growing the buffer exponentially is simple and effective.
>>
>> Yes, that's the general way to handle buffers when you don't know what size
>> they should be.
>>
>> A better solutions for this sort of program is usually, as you say, asking
>> the OS for the file size (there is no standard library function for getting
>> the file size, but it's not hard to do for any realistic target OS). And
>> then for big files, prefer mmap to reading the file into a buffer.
>>
>> It's only really for unsized "files" such as piped input that you have no
>> way of getting the size, and then exponential growth is the way to go.
>> Personally, I'd start with a big size (perhaps 10 MB) that is bigger than
>> you are likely to need in practice, but small enough that it is negligible
>> on even vaguely modern computers. Then the realloc code is unlikely to be
>> used (but it can still be there for completeness).
>
> There are other uses that have nothing to do with files.

Of course. This comment was for the specific purposes being discussed
here. For other uses, there can be many other structures and algorithms
that fit better. Exponentially increasing the size when needed is a
good general-purpose method.

> I have a small
> dynamic array library (just a couple of function) that I use for all
> sorts of things. I can read a file or parse tokens or input a line just
> by adding characters. Because of its rather general use, I don't start
> with a large buffer (though the initial size can be set).
>

>> > I think it is a modern English idiom, which I dislike as
>> > well. StackOverflow is full of questions starting like:
>> > "How do you do this?" and "How do I do that?" They are
>> > informal ways of the more literary "How does one do
>> > this?" or "What is the way to do that?"
>>
>> I have a different take here. First the "your" of "your
>> strategy" reads as a definite pronoun, meaning it refers
>> specifically to Ben and not to some unknown other party.
>
>And I am /sure/ it is intended in the general (indefinite)
>sense, as is the `you' in Malcolm's two following sentences:

This sub-thread is certainly interesting, but it ultimately smacks of
people looking for ways to feel insulted. Victimhood complex, and all that.

But, it makes me think that the problem is the basic paradigm of newsgroup
(i.e., online forum) communication being thought of as personalized. I.e.,
as in direct person-to-person communication - as if it was being spoken in
a real room with real people (face-to-face). The fact is, it is not. It
would be better if we didn't think of it that way. Rather, it should be
thought of as communication between the speaker and an anonymous void.
I.e., I'm not talking to you - I am talking to the anonymous void.
Everybody is.

Sort of like in the (US) House of Representatives - members are not ever
supposed to be talking to each other. Rather, they are always speaking to
the void.

Like I am doing now.

This is also why it is good (And, yes, I know this goes against the CW) to
drop attributions, as I have done here. Keep it anonymous.

--

First of all, I do not appreciate your playing stupid here at all.

- Thomas 'PointedEars' Lahn -

On 20.06.2024 14:10, Kenny McCormack wrote:
>
> This sub-thread is certainly interesting, but it ultimately smacks of
> people looking for ways to feel insulted. Victimhood complex, and all that.
>
> But, it makes me think that the problem is the basic paradigm of newsgroup
> (i.e., online forum) communication being thought of as personalized. I.e.,
> as in direct person-to-person communication - as if it was being spoken in
> a real room with real people (face-to-face). The fact is, it is not. It
> would be better if we didn't think of it that way. Rather, it should be
> thought of as communication between the speaker and an anonymous void.
> I.e., I'm not talking to you - I am talking to the anonymous void.
> Everybody is.
>
> Sort of like in the (US) House of Representatives - members are not ever
> supposed to be talking to each other. Rather, they are always speaking to
> the void.
>
> Like I am doing now.
>
> This is also why it is good (And, yes, I know this goes against the CW) to
> drop attributions, as I have done here. Keep it anonymous.

Part 1

This is hard to achieve given that the technical NG infrastructure and
functions "logically" connect the articles; it's only a little burden
to identify (if not already obvious) the addressee.

I think it would be better to try to stay on the issue as opposed to
reply (as so often done) ad hominem (where arguments don't seem to
exist or don't help anymore). This is of course yet more difficult to
achieve and will in practice [also] not work in Usenet (I'm sure).

Language can be used or interpreted in personal or impersonal forms.
Some communication forms - and more so their semantical contents! -
are (beyond the "you" vs. "one" dichotomy) inherently [set up to be]
personal.

-- Anonymous
:-)

Part 2

That all said. I think it's important to know who said/posted what.
It allows to associate personal context/background information when
replying. You can also be more assured about the quality of contents
(to the good or bad) or even ignore certain posts. It saves time and
protects ones health and mental sanity.[*]

There's of course also post (or threads) that just exchange opinions,
and "we" know everyone [typically] has an opinion (and often even in
cases where they are put up against facts). Some folks are known to
post a lot, respond to every thread that appears, contributing facts
(sometimes) but also opinions (or personal offenses); this may be a
nuisance (or just ignored, unless "anonymously" posted).

So far my opinion on this non-technical meta-topic subthread.

Janis
(Darn, I disclosed my identity!)

[*] Wasn't that the inherent problem of all those "social media"
platforms? - Where anonymous posts - and some say that anonymity
does negatively contribute to the language and contents of such
disturbing posts - lead to barbarian communication conditions.
(I know that only from hearsay but it seems common perception.)

On 17/06/2024 10:22, Bonita Montero wrote:
>
> realloc() is just a convenience funciton. Usually the reallocation
> can't happen in-place and a second malloc() followed by a copy and
> a free() does the same.
> For large data it would be nice if the pages being deallocated later
> would be incrementally marked as discardable after copying a portion.
> This would result in only a small portion of additional physical
> memory being allocated since the newly allocated pages become asso-
> ciated with phyiscal pages when they're touched first. Windows has
> VirtualAlloc() with MEM_RESET for that, Linux has madvise() with
> MADV_DONTNEED.

"Usually can't happen in place"?

Really? It's not something I use a lot, but when it's appropriate I
will. It's got the advantage over doing this myself that for some
portion of calls all the run time library needs to do is change the size
field in the structure.

Nothing else.

No copying, and no duplicate allocations.

What proportion of calls can be managed by changing the size field alone
depends on your workload and the platform. But I doubt there are many
cases where it is 0%.

Andy

On Thu, 20 Jun 2024 02:51:56 +0300, Anton Shepelev wrote:

>> But "one" can also be used as a first person definite pronoun
>> (referring to the speaker), which an online reference tells me is
>> chiefly British English.

We have the same construct in Swedish: 'en', as in "en kanske skulle kunna
ta en banan", meaning "one could perhaps have a banana." Referring to
oneself from an outside perspective, in, for instance, a situation where
there used to be several items on offer to guests, but now there are only
bananas and some dry sponge cake left. IOW, of two lesser desirable items,
one could accept a banana.

--
Cri-Cri

Anton Shepelev <anton.txt@gmail.moc> writes:

> Cross-posting to alt.english.usage .
>
> Tim Rentsch to Anton Shepelev:
>
>>> I think it is a modern English idiom, which I dislike as
>>> well. StackOverflow is full of questions starting like:
>>> "How do you do this?" and "How do I do that?" They are
>>> informal ways of the more literary "How does one do
>>> this?" or "What is the way to do that?"
>>
>> I have a different take here. First the "your" of "your
>> strategy" reads as a definite pronoun, meaning it refers
>> specifically to Ben and not to some unknown other party.
>
> And I am /sure/ it is intended in the general (indefinite)
> sense,

I don't know why you think that. I don't know any native
English speakers who would read it as other than referring
to the person being responded to (who was Ben in this case).
Responding to Malcolm's statement, Ben said "It's odd to
call it mine", so it seems Ben also read it as a definite
pronoun, referring to himself.

As for the rest of your comments, you're reaching bad
conclusions because you're not looking in the right places.
To investigate the meaning and usage of words and phrases,
the best first place to look is always a dictionary. In
the process of writing my earlier response, I consulted
roughly half a dozen different online dictionaries, reading
definitions for 'one', 'you', 'they', 'indefinite pronoun',
'definite pronoun', and probably some other terms. I also
looked at non-dictionary sources if they looked relevant,
but my starting point was dictionaries. Oh, I also looked
up both 'idiom' and 'idiomatic' (which even though they are
related don't mean the same thing).

Incidentally, on the three pages you gave links for,
all of them had at least one example that used "you"
as an indefinite pronoun.

One point I want to clear up. A couple of times you
characterize the indefinite pronoun usage of "you"
as "modern". It is not in any sense modern. I am
a native speaker of English, speaking and reading
the language for well over 60 years. Furthermore I
was raised by a grammarian. In all of that time and
experience there was never any hint that "you" as an
indefinite pronoun was new or unusual or considered
substandard or slang or unacceptable. It is simply
standard usage, and has been for longer than my
lifetime.

>> But "one" can also be used as a first person definite
>> pronoun (referring to the speaker), which an online
>> reference tells me is chiefly British English.
>
> I had no idea it could, nor does Wikipedia. Can you share
> an example of a definite first-person `one'?

(A) Pick a good search engine (I use duckduckgo.com).
(B) Search for the two words one definition.
(C) Read the entries for every online dictionary that
is found, or at least the top five or six.

You should find a couple of examples. It was by going
through this process myself that I discovered "one"
is sometimes used as a first person definite pronoun.

On 20/06/2024 02:34, vallor wrote:
> On Thu, 20 Jun 2024 02:51:56 +0300, Anton Shepelev <anton.txt@gmail.moc>
> wrote in <20240620025156.2ae9300726603b4cb3631547@gmail.moc>:
>
>> Cross-posting to alt.english.usage .
>
> I've set the followup-to: same

I've put it back to comp.lang.c. It's off-topic for that group, but
that's where people were discussing it, and it seems to be of a at least
some interest to some regulars here. (I suppose maybe those regulars
are also followers of alt.english.usage.)

>
>>
>> Tim Rentsch to Anton Shepelev:
>>> But "one" can also be used as a first person definite pronoun
>>> (referring to the speaker), which an online reference tells me is
>>> chiefly British English.
>>
>> I had no idea it could, nor does Wikipedia. Can you share an example of
>> a definite first-person `one'?
>
> I think that would go something like:
>
> "One wonders how..."

It is /possible/, but archaic and very upper-class. You'd immediately
suspect the speaker is wearing a top hat.

It is much more common to say simply "I wonder how...", followed by "You
wonder how..." (with "you" being generic rather than specifically the
person listening). Such usage will be more common in some dialects than
others.

>
> (Also, in some writing, "this one" can replace "I" -- this one used to do
> that on Usenet, but was told it was pretentious.)
>

That would be even less common. The form, again archaic, would be more
usually written as "This writer used to do that..." (or "This
programmer", or however the person wanted to style himself/herself).

David Brown <david.brown@hesbynett.no> writes:
> On 20/06/2024 02:34, vallor wrote:
>> On Thu, 20 Jun 2024 02:51:56 +0300, Anton Shepelev <anton.txt@gmail.moc>
>> wrote in <20240620025156.2ae9300726603b4cb3631547@gmail.moc>:
>>
>>> Cross-posting to alt.english.usage .
>> I've set the followup-to: same
>
> I've put it back to comp.lang.c. It's off-topic for that group,

Please don't do that.

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

Am 20.06.2024 um 22:08 schrieb Vir Campestris:
> On 17/06/2024 10:22, Bonita Montero wrote:
>>
>> realloc() is just a convenience funciton. Usually the reallocation
>> can't happen in-place and a second malloc() followed by a copy and
>> a free() does the same.
>> For large data it would be nice if the pages being deallocated later
>> would be incrementally marked as discardable after copying a portion.
>> This would result in only a small portion of additional physical
>> memory being allocated since the newly allocated pages become asso-
>> ciated with phyiscal pages when they're touched first. Windows has
>> VirtualAlloc() with MEM_RESET for that, Linux has madvise() with
>> MADV_DONTNEED.
>
> "Usually can't happen in place"?

Usually you don't resize the block with a few bytes and if you have
a large memory area it's unlikely that you can allocate a few additional
pages in-place.
C++23 has a nice function with the allocator interface called allocate
_at_least. It returns the pointer to the allocated memory with the size
actually allocated. This fits with modern allocators like mimalloc, je-
malloc or tcmalloc, which round up the allocation to the next 2 ^ N
boundary up to 8kB. So a vector's capacity directly includes the blend.

On Fri, 21 Jun 2024 21:12:12 +0200, Bonita Montero wrote:

> Usually you don't resize the block with a few bytes ...

The usual way I use realloc is to maintain separate counts of the number
of array elements I have allocated, and the number I am actually using. A
realloc call is only needed when the latter hits the former. Every time I
call realloc, I will extend by some minimum number of array elements (e.g.
128), roughly comparable to the sort of array size I typically end up
with.

And then when the structure is complete, I do a final realloc call to
shrink it down so the size is actually that used. Is it safe to assume
such a call will never fail? Hmm ...

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Fri, 21 Jun 2024 21:12:12 +0200, Bonita Montero wrote:
>> Usually you don't resize the block with a few bytes ...
>
> The usual way I use realloc is to maintain separate counts of the number
> of array elements I have allocated, and the number I am actually using. A
> realloc call is only needed when the latter hits the former. Every time I
> call realloc, I will extend by some minimum number of array elements (e.g.
> 128), roughly comparable to the sort of array size I typically end up
> with.
>
> And then when the structure is complete, I do a final realloc call to
> shrink it down so the size is actually that used. Is it safe to assume
> such a call will never fail? Hmm ...

It's not safe to assume that a shrinking realloc call will never fail.
It's possible that it will never fail in any existing implementation,
but the standard makes no such guarantee.

A (perhaps) plausible way it can fail is if allocations of different
sizes are allocated from different pools. Trying to shrink a 1000-byte
object to 100 bytes might fail if the 100-byte pool has been exhausted.
On the other hand, realloc() could just return its argument in such a
case and continue treating the object as a 1000-byte allocation.
(The allocation functions don't have to keep track of how much memory
you asked for, only how much they actually allocated, which is >= what
you asked for.)

Arguably only a poor implementation would fail on a shrinking realloc(),
but the standard permits poor implementations.

Having said all that, if realloc fails (indicated by returning a null
pointer), you still have the original pointer to the object.

Something else that occurs to me: If a shrinking realloc() never fails
in practice, then any code you write to handle a failure won't be
tested.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */