On 24/06/2024 11:55, Keith Thompson wrote:

> 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.
>

That is always a problem with allocation functions. Have you ever known
a non-pathological malloc() to fail?

I think, in fact, there's a good argument for ignoring the possibility
of malloc (and calloc and realloc) failures for most PC code. There is
virtually no chance of failure in reality, and if you get one, there is
almost never a sensible way to deal with it - you just kick the can down
the road by having functions return NULL until something gives up and
stops the program with an error message. You might as well just let the
OS kill the program when you try to access memory at address 0.

I've seen more than enough error handling code that has never been
tested in practice - including error handling code with bugs that lead
to far worse problems than just killing the program.

Of course such treatment is not appropriate for all allocations (or
other functions that could fail). But often I think it is better to
write clearer and fully testable (and tested!) code which ignores
hypothetical errors, rather than some of the untestable and untested
jumbles that are sometimes seen in an attempt to "handle" allocation
failures.

Am 24.06.2024 um 10:40 schrieb Lawrence D'Oliveiro:

> 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 ...

In C++ you dont't have to think about that. Do an emplace_back and the
capacity() doubles with libstdc++ and libc++ if the vevtor becomes full.

Am 24.06.2024 um 11:55 schrieb Keith Thompson:
> 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.

With modern memory allocators a shrink can easily fail if the shrunken
block falls into a different size class and there's no memory for a
block in this class.
mimalloc, jemalloc and TCMalloc round up the size to the next power of
two up to 8kB. If yoz have a 8kB-class block and it shrinks below 4kB
and there's no page (6kB for all mentioned allocators) for this class
and no additional pool can be allocated the shrink fails.

In article <v5bv37$vejk$1@raubtier-asyl.eternal-september.org>,
....
>In C++ you dont't have to think about that.

You don't have to worry about it in Fortran, either.

--
"He is exactly as they taught in KGB school: an egoist, a liar, but talented - he
knows the mind of the wrestling-loving, under-educated, authoritarian-admiring
white male populous."
- Malcolm Nance, p59. -

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

> 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. [...]

You have an annoying habit. Your writing often comes across as
authoritarian and somewhat condescending. Furthermore you tend not
to listen very well. Your response above is a case in point. You
ignore what I'm talking about (which is not whether Ben uses an
exponential growth strategy, or whether such a strategy is "Ben's"
or not), and instead talk about something that is irrelevant to what
I was saying. You have completely missed the point. Your comments
do nothing to extend the conversation. From where I sit all they do
is cause irritation and illustrate how muddled your thinking is.
I'm sure this isn't the first time you've heard comments along these
lines. It would be nice if you would make an effort to improve
your behavior in light of these repeated comments.

On 24/06/2024 18:32, Tim Rentsch wrote:
>
> You have an annoying habit. Your writing often comes across as
> authoritarian and somewhat condescending. Furthermore you tend not
> to listen very well.

The irony of that post is /astounding/.

I have met few people with a greater knowledge and insight in the C
language than you. And I have met few with less self-insight.

On 24/06/2024 12:40, David Brown wrote:
> On 24/06/2024 11:55, Keith Thompson wrote:
>
>> 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.
>>
>
> That is always a problem with allocation functions.  Have you ever known
> a non-pathological malloc() to fail?
>
> I think, in fact, there's a good argument for ignoring the possibility
> of malloc (and calloc and realloc) failures for most PC code.  There is
> virtually no chance of failure in reality, and if you get one, there is
> almost never a sensible way to deal with it - you just kick the can down
> the road by having functions return NULL until something gives up and
> stops the program with an error message.  You might as well just let the
> OS kill the program when you try to access memory at address 0.
>
> I've seen more than enough error handling code that has never been
> tested in practice - including error handling code with bugs that lead
> to far worse problems than just killing the program.
>
> Of course such treatment is not appropriate for all allocations (or
> other functions that could fail).  But often I think it is better to
> write clearer and fully testable (and tested!) code which ignores
> hypothetical errors, rather than some of the untestable and untested
> jumbles that are sometimes seen in an attempt to "handle" allocation
> failures.
>
>
Baby X has bbx_malloc() which is guaranteed never to return NULL, and
never to return a pointer to an allocation which cannot be indexed by an
int.

I use a "goto out_of_memory" in regular code, however.

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

Am 24.06.2024 um 17:44 schrieb Kenny McCormack:
> In article <v5bv37$vejk$1@raubtier-asyl.eternal-september.org>,
> ...
>> In C++ you dont't have to think about that.
>
> You don't have to worry about it in Fortran, either.

But Fortran is for sure not that flexible that you could build your
own containers basing on the same logic, partitially with lowlevel
facilities which are derived from C. I implemnented a parallel hash
map with some reader writer's locks which feel rather like a native
component of the language; try this with Fortran.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 24/06/2024 12:40, David Brown wrote:

>> Of course such treatment is not appropriate for all allocations (or
>> other functions that could fail).  But often I think it is better to
>> write clearer and fully testable (and tested!) code which ignores
>> hypothetical errors, rather than some of the untestable and untested
>> jumbles that are sometimes seen in an attempt to "handle" allocation
>> failures.
>>
>>
>Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>never to return a pointer to an allocation which cannot be indexed by an
>int.

What do you mean by 'indexed by an int'? So, what happens if I index
your allocation with -109235?

Or did you mean to say unsigned (or positive) int less than the
size of the allocation?

On 6/24/2024 4:40 AM, David Brown wrote:
> On 24/06/2024 11:55, Keith Thompson wrote:
>
>> 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.
>>
>
> That is always a problem with allocation functions.  Have you ever known
> a non-pathological malloc() to fail?
>
> I think, in fact, there's a good argument for ignoring the possibility
> of malloc (and calloc and realloc) failures for most PC code.  There is
> virtually no chance of failure in reality, and if you get one, there is
> almost never a sensible way to deal with it -
[...]

I have had to deal and roll with malloc failures. It put the server in
panic mode and it started killing connections that were already timed
out, dumping some caches (freelists of regions, ect), ect... There is a
way to recover.

Am 24.06.2024 um 21:33 schrieb Chris M. Thomasson:
> On 6/24/2024 4:40 AM, David Brown wrote:
>> On 24/06/2024 11:55, Keith Thompson wrote:
>>
>>> 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.
>>>
>>
>> That is always a problem with allocation functions.  Have you ever
>> known a non-pathological malloc() to fail?
>>
>> I think, in fact, there's a good argument for ignoring the possibility
>> of malloc (and calloc and realloc) failures for most PC code.  There
>> is virtually no chance of failure in reality, and if you get one,
>> there is almost never a sensible way to deal with it -
> [...]
>
> I have had to deal and roll with malloc failures. It put the server in
> panic mode and it started killing connections that were already timed
> out, dumping some caches (freelists of regions, ect), ect... There is a
> way to recover.
>

There are applications where you can ignore malloc()-failures /
bad_alloc since they only allocate a small amount of memory or
a lot of small allocations which sum up to a small amount of
memory.

scott@slp53.sl.home (Scott Lurndal) writes:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
>>Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>>never to return a pointer to an allocation which cannot be indexed by an
>>int.
>
> What do you mean by 'indexed by an int'? So, what happens if I index
> your allocation with -109235?
>
> Or did you mean to say unsigned (or positive) int less than the
> size of the allocation?

If I recall correctly, Malcolm hates size_t. I presume that
bbx_malloc() will never allocate more than INT_MAX bytes.

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

On Mon, 24 Jun 2024 13:40:08 +0200, David Brown wrote:

> Have you ever known a non-pathological malloc() to fail?

I was once commissioned, many decades ago, to write a multispectral image
viewer to run on old MacOS. I followed my usual memory-allocation
discipline. The client reported how he tried to open too many images at
once, and ran out of memory; my program reported one out-of-memory error,
gave up trying to open the rest of the files, and gracefully recovered
without crashing.

The program that had been supplied to him for Microsoft Windows, however,
gave an error for *each* file it failed to open.

On 24/06/2024 22:28, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>>> Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>>> never to return a pointer to an allocation which cannot be indexed by an
>>> int.
>>
>> What do you mean by 'indexed by an int'? So, what happens if I index
>> your allocation with -109235?
>>
>> Or did you mean to say unsigned (or positive) int less than the
>> size of the allocation?
>
> If I recall correctly, Malcolm hates size_t. I presume that
> bbx_malloc() will never allocate more than INT_MAX bytes.
>
Exactly.
Currently bbx_malloc() does take a size_t, but there version in which it
takes an int. However you get warning sif yiub try something like
bbx_mallcc(10 * sizeof(int)) on the basis that expressin is size_t.

But if you pass either a negative number or more than iNT_MAX, it
assumes the request is invalid and terminates with an error message.

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

On 6/24/2024 2:28 PM, Keith Thompson wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> [...]
>>> Baby X has bbx_malloc() which is guaranteed never to return NULL, and
>>> never to return a pointer to an allocation which cannot be indexed by an
>>> int.
>>
>> What do you mean by 'indexed by an int'? So, what happens if I index
>> your allocation with -109235?
>>
>> Or did you mean to say unsigned (or positive) int less than the
>> size of the allocation?
>
> If I recall correctly, Malcolm hates size_t. I presume that
> bbx_malloc() will never allocate more than INT_MAX bytes.
>

He still has to deal with bbx_malloc failing. Don't like automatically
aborting...

bbx_malloc(INT_MAX);
bbx_malloc(INT_MAX);
bbx_malloc(INT_MAX);
....

;^)

On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> 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.
>
> ...
>
> Having said all that, if realloc fails (indicated by returning a null
> pointer), you still have the original pointer to the object.

In other words, it’s safe to ignore any error from that last shrinking
realloc? That’s good enough for me. ;)

On Mon, 24 Jun 2024 18:50:15 +0100, Malcolm McLean wrote:

> Baby X has bbx_malloc() which is guaranteed never to return NULL ...

Does it actually allocate the (physical) memory?

I wrote a memory-hog app for Android once, and found that allocating large
amounts of memory space had very little impact on the system. Then when I
added code to actually write data into those allocated pages, that’s when
it really started to break into a sweat ...

Am 25.06.2024 um 09:06 schrieb Lawrence D'Oliveiro:

> I wrote a memory-hog app for Android once, and found that allocating large
> amounts of memory space had very little impact on the system. Then when I
> added code to actually write data into those allocated pages, that’s when
> it really started to break into a sweat ...

Then android is also doing overcommit.

Test this code with your Linux installation. For my installation
glibc does all realloc()ations in-place. Really surprising for me.

#include <stdio.h>
#include <stdlib.h>

int main()
{ void *p = malloc( 0x100000000 );
printf( "%p\n", p );
p = realloc( p, 1 );
printf( "%p\n", p );
malloc( 0x100000000 - 0x10000 );
p = realloc( p, 0x100000000 );
printf( "%p\n", p );
}

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>> 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.
>>
>> ...
>>
>> Having said all that, if realloc fails (indicated by returning a null
>> pointer), you still have the original pointer to the object.
>
> In other words, it’s safe to ignore any error from that last shrinking
> realloc? That’s good enough for me. ;)

What? No, that's not what I said at all.

Suppose you do something like:

some_type *p = malloc(BIG_VALUE);
// ...
p = realloc(p, SMALL_VALUE);

If the realloc() succeeds and doesn't relocate and copy the object,
you're fine. If realloc() succeeds and *does* relocate the object, p
still points to memory that has now been deallocated, and you don't have
a pointer to the newly allocated memory. If realloc() fails, it returns
a null pointer, but the original memory is still valid -- but again, the
assignment clobbers your only pointer to it.

I presume you can write code that handles all three possibilities, but
you can't just ignore any errors.

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

On 25/06/2024 09:48, Bonita Montero wrote:
> Test this code with your Linux installation. For my installation
> glibc does all realloc()ations in-place. Really surprising for me.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
>     void *p = malloc( 0x100000000 );
>     printf( "%p\n", p );
>     p = realloc( p, 1 );
>     printf( "%p\n", p );
>     malloc( 0x100000000 - 0x10000 );
>     p = realloc( p, 0x100000000 );
>     printf( "%p\n", p );
> }
Try allocating a bunch of little items, and looking at where they are.
They'll likely be contiguous, or evenly spaced, depending on your
implementation and what "little" is.

Then resize them all. Some will move.

Andy.
--
Your C++ comment up-thread BTW is off-topic here. My favourite C++
container is vector, and that has a reserve call so you can keep growing
the container without lots of reallocations.

On 6/25/24 6:05 AM, Keith Thompson wrote:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Mon, 24 Jun 2024 02:55:39 -0700, Keith Thompson wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> 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.
>>>
>>> ...
>>>
>>> Having said all that, if realloc fails (indicated by returning a null
>>> pointer), you still have the original pointer to the object.
>>
>> In other words, it’s safe to ignore any error from that last shrinking
>> realloc? That’s good enough for me. ;)
>
> What? No, that's not what I said at all.
>
> Suppose you do something like:
>
> some_type *p = malloc(BIG_VALUE);
> // ...
> p = realloc(p, SMALL_VALUE);
>
> If the realloc() succeeds and doesn't relocate and copy the object,
> you're fine. If realloc() succeeds and *does* relocate the object, p
> still points to memory that has now been deallocated, and you don't have
> a pointer to the newly allocated memory. If realloc() fails, it returns
> a null pointer, but the original memory is still valid -- but again, the
> assignment clobbers your only pointer to it.
>
> I presume you can write code that handles all three possibilities, but
> you can't just ignore any errors.
>

The idiom I always learned for realloc was something like:

some_type *p = malloc(size);
if (!p) {
// allocation failed, do something about it. (might be just abort)
}

....

some_type *np = realloc(p, new_size);
if (np) {
p = np;
} else {
// p still points to old buffer, but you didn't get the new size
// so do what you can to handle the situation.
}

// p here points to the current buffer,
// might be the old size or the new.

Am 25.06.2024 um 12:55 schrieb Vir Campestris:
> On 25/06/2024 09:48, Bonita Montero wrote:
>> Test this code with your Linux installation. For my installation
>> glibc does all realloc()ations in-place. Really surprising for me.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main()
>> {
>>      void *p = malloc( 0x100000000 );
>>      printf( "%p\n", p );
>>      p = realloc( p, 1 );
>>      printf( "%p\n", p );
>>      malloc( 0x100000000 - 0x10000 );
>>      p = realloc( p, 0x100000000 );
>>      printf( "%p\n", p );
>> }
> Try allocating a bunch of little items, and looking at where they are.
> They'll likely be contiguous, or evenly spaced, depending on your
> implementation and what "little" is.
>
> Then resize them all. Some will move.
>
> Andy.

The interesting part is that after doing the first realloc()
the memory being freee isn't reused for the next malloc().

On 6/25/2024 4:48 AM, Bonita Montero wrote:
> Test this code with your Linux installation. For my installation
> glibc does all realloc()ations in-place. Really surprising for me.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main()
> {
>     void *p = malloc( 0x100000000 );
>     printf( "%p\n", p );
>     p = realloc( p, 1 );
>     printf( "%p\n", p );
>     malloc( 0x100000000 - 0x10000 );
>     p = realloc( p, 0x100000000 );
>     printf( "%p\n", p );
> }

$ gcc -Wall montera_test.c -o mt
montera_test.c: In function ‘main’:
montera_test.c:10:9: warning: ignoring return value of ‘malloc’ declared
with attribute ‘warn_unused_result’ [-Wunused-result]
10 | malloc( 0x100000000 - 0x10000 );
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

$ ./mt
0x7fb976f12010
0x7fb976f12010
0x7fb876f11010

Am 25.06.2024 um 15:56 schrieb DFS:
> On 6/25/2024 4:48 AM, Bonita Montero wrote:
>> Test this code with your Linux installation. For my installation
>> glibc does all realloc()ations in-place. Really surprising for me.
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main()
>> {
>>      void *p = malloc( 0x100000000 );
>>      printf( "%p\n", p );
>>      p = realloc( p, 1 );
>>      printf( "%p\n", p );
>>      malloc( 0x100000000 - 0x10000 );
>>      p = realloc( p, 0x100000000 );
>>      printf( "%p\n", p );
>> }
>
>
> $ gcc -Wall montera_test.c -o mt
> montera_test.c: In function ‘main’:
> montera_test.c:10:9: warning: ignoring return value of ‘malloc’ declared
> with attribute ‘warn_unused_result’ [-Wunused-result]
>    10 |         malloc( 0x100000000 - 0x10000 );
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

This actually isn't a problem because I just wanted to test if the tail
of the p-block is immediately rezsed so that the next grow can't recycle
the memory. But interestingly all steps are done in-place.