Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #168197 > unrolled thread

Why is glibc not extensive?

Back to article view | Back to comp.lang.c

Contents

  Why is glibc not extensive? Amit <amitchoudhary0523@gmail.com> - 2022-11-16 22:31 -0800
    Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:05 +0000
      Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:18 -0800
        Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-17 05:24 -0800
        Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-17 13:57 +0000
        Re: Why is glibc not extensive? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-17 17:04 +0000
        Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 09:32 +0100
          Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 02:32 -0800
            Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:09 +0100
              Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 04:47 -0800
                Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-18 13:59 +0100
                  Re: Why is glibc not extensive? A <amit234234234234@gmail.com> - 2022-11-18 05:27 -0800
                Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-18 17:04 +0000
                  Re: Why is glibc not extensive? David Brown <david.brown@hesbynett.no> - 2022-11-21 08:50 +0100
                    Bart (Was: Why is glibc not extensive?) gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-21 14:14 +0000
                Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-21 08:10 -0800
                  Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-11-26 09:07 -0800
                    Re: Why is glibc not extensive? Michael S <already5chosen@yahoo.com> - 2022-11-26 16:11 -0800
                      Re: Why is glibc not extensive? Kaz Kylheku <864-117-4973@kylheku.com> - 2022-11-27 13:05 +0000
                        Re: Why is glibc not extensive? scott@slp53.sl.home (Scott Lurndal) - 2022-11-27 16:30 +0000
                        Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 12:20 -0600
                          Re: Why is glibc not extensive? Bart <bc@freeuk.com> - 2022-11-27 21:13 +0000
                            Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-27 21:53 -0600
                      Re: Why is glibc not extensive? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-03 01:17 -0800
          Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 15:11 -0600
    Re: Why is glibc not extensive? Bonita Montero <Bonita.Montero@gmail.com> - 2022-11-17 19:05 +0100
      Re: Why is glibc not extensive? gazelle@shell.xmission.com (Kenny McCormack) - 2022-11-18 08:09 +0000
        Re: Why is glibc not extensive? BGB <cr88192@gmail.com> - 2022-11-23 13:55 -0600

Page 1 of 2  [1] 2  Next page →

#168197 — Why is glibc not extensive?

Hi,

In my opinion, glibc should have support for maps, sets, balanced binary trees, many more string functions, etc. (I know tree and hash are there in glibc), so that developers don't have to implement them themselves, thus saving lots of man hours all over the world. This will also make C more user friendly like C++ and Java.

Amit

[toc] | [next] | [standalone]

#168218

On 17/11/2022 06:31, Amit wrote:
> Hi,
> 
> In my opinion, glibc should have support for maps, sets, balanced binary trees, many more string functions, etc. (I know tree and hash are there in glibc), so that developers don't have to implement them themselves, thus saving lots of man hours all over the world. This will also make C more user friendly like C++ and Java.

There must be 1000s of such libraries already available, all doing 
things slightly differently, with different choices and with different 
applications in mind.

You want the maintainers of C to decide which ones to build in to the 
standard language? (Maybe decide which of umpteen GUI libraries to 
include too.)

People use C /because/ it has that flexibility to use any library or to 
implement your own.

Anyway a lot of your suggestions really demand generic solutions, and C 
doesn't have generic types. For those, there are myriad more assorted 
ways to add those to C, but the results are usually ungainly and painful 
to use.

C is just not suited for such things.

[toc] | [prev] | [next] | [standalone]

#168221

On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
> On 17/11/2022 06:31, Amit wrote: 
> 
> Anyway a lot of your suggestions really demand generic solutions, and C 
> doesn't have generic types. For those, there are myriad more assorted 
> ways to add those to C, but the results are usually ungainly and painful 
> to use. 
> 
> C is just not suited for such things.

Generics can be implemented in C without much hassle.

I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL.

The following is part of my header file which lists how I achieved generics in C:

 struct element                                                                   
{                                                                                
    void *data;                                                                  
    long data_len;                                                               
    struct element *next;                                                        
};                                                                               
                                                                                 
typedef void (*call_function_before_deleting_data)(struct element *);            
typedef void (*compare_elements_function)(struct element *, struct element *);   
                                                                                 
struct generic_unordered_set_container                                           
{                                                                                
    struct element *first;                                                       
    struct element *fi; // fi stands for forward iterator                        
    long total_number_of_elements;                                               
    // callback functions                                                        
    call_function_before_deleting_data cfbdd_callback_function;                  
    compare_elements_function ce_function;                                       
    // to be thread-safe                                                         
    pthread_mutex_t mtx;                                                         
    pthread_mutexattr_t mtx_attr;                                                
};                                         

Amit

[toc] | [prev] | [next] | [standalone]

#168222

On Thursday, 17 November 2022 at 18:48:45 UTC+5:30, A wrote:
> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote: 
> > On 17/11/2022 06:31, Amit wrote: 
> > 
> > Anyway a lot of your suggestions really demand generic solutions, and C 
> > doesn't have generic types. For those, there are myriad more assorted 
> > ways to add those to C, but the results are usually ungainly and painful 
> > to use. 
> > 
> > C is just not suited for such things.
> Generics can be implemented in C without much hassle. 
> 
> I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL. 
> 
> The following is part of my header file which lists how I achieved generics in C: 
> 
> struct element 
> { 
> void *data; 
> long data_len; 
> struct element *next; 
> }; 
> 
> typedef void (*call_function_before_deleting_data)(struct element *); 
> typedef void (*compare_elements_function)(struct element *, struct element *); 
> 
> struct generic_unordered_set_container 
> { 
> struct element *first; 
> struct element *fi; // fi stands for forward iterator 
> long total_number_of_elements; 
> // callback functions 
> call_function_before_deleting_data cfbdd_callback_function; 
> compare_elements_function ce_function; 
> // to be thread-safe 
> pthread_mutex_t mtx; 
> pthread_mutexattr_t mtx_attr; 
> }; 
> 
> Amit

I forgot to add that data will copy user data irrespective of user data being a pointer or a concrete structure.

Something like this:

int add_new_element(struct generic_unordered_set_container *gusc_ptr, void *data, long data_len) 
{

    _some_code_

    nddt->data_len = data_len;
    memcpy(nddt->data, data, (size_t)(nddt->data_len));

    _some_code_

}

Amit

[toc] | [prev] | [next] | [standalone]

#168225

On 17/11/2022 13:18, A wrote:
> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>> On 17/11/2022 06:31, Amit wrote:
>>
>> Anyway a lot of your suggestions really demand generic solutions, and C
>> doesn't have generic types. For those, there are myriad more assorted
>> ways to add those to C, but the results are usually ungainly and painful
>> to use.
>>
>> C is just not suited for such things.
> 
> Generics can be implemented in C without much hassle.
> 
> I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL.

As I said, lots of people have attemted this. If I tried it, I would do 
it differently from your, with different trade-offs. Which one should 
standard C have?

> 
> The following is part of my header file which lists how I achieved generics in C:
> 
>   struct element
> {
>      void *data;
>      long data_len;
>      struct element *next;
> };
>                                                                                   
> typedef void (*call_function_before_deleting_data)(struct element *);
> typedef void (*compare_elements_function)(struct element *, struct element *);
>                                                                                   
> struct generic_unordered_set_container
> {
>      struct element *first;
>      struct element *fi; // fi stands for forward iterator
>      long total_number_of_elements;
>      // callback functions
>      call_function_before_deleting_data cfbdd_callback_function;


>      compare_elements_function ce_function;
>      // to be thread-safe
>      pthread_mutex_t mtx;
>      pthread_mutexattr_t mtx_attr;
> };

What does an example of use actually look like, compared with C++?

C++ has famously long-winded and 'busy' syntax; is yours going to be 
longer or shorter?

And why would somebody use this particular library, in C, compared to 
just using C++?

For example, a simple array like this:

    vector<int> A = {10,20,30,40};

[toc] | [prev] | [next] | [standalone]

#168234

A <amit234234234234@gmail.com> writes:

> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>> On 17/11/2022 06:31, Amit wrote: 
>> 
>> Anyway a lot of your suggestions really demand generic solutions, and C 
>> doesn't have generic types. For those, there are myriad more assorted 
>> ways to add those to C, but the results are usually ungainly and painful 
>> to use. 
>> 
>> C is just not suited for such things.
>
> Generics can be implemented in C without much hassle.

The code you posted shows that it really is quite a lot of hassle.

> I am currently implementing C++ STL in C.  And the my data structures
> are generic - any type of data can be used just like in C++ STL.

C++ containers have type checking and automatic destruction both of
which are big wins.  Why not use C++ rather than try to write a poor
man's STL in C?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168245

On 17/11/2022 14:18, A wrote:
> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>> On 17/11/2022 06:31, Amit wrote:
>>
>> Anyway a lot of your suggestions really demand generic solutions, and C
>> doesn't have generic types. For those, there are myriad more assorted
>> ways to add those to C, but the results are usually ungainly and painful
>> to use.
>>
>> C is just not suited for such things.
> 
> Generics can be implemented in C without much hassle.
> 

No, they cannot.

> I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL.
> 

No, they cannot.

Of course you can make generic containers in C, but you cannot approach 
the user convenience, safety, or efficiency that is found in other 
languages that have better support for this kind of thing.  You have no 
choice but to use generic "void *" pointers, long names, and awkward syntax.

If you have a vector of "widgets" in a programming language, and you try 
to add a "whatsit" to it, there are basically three things that can happen :

1. The compiler will complain (that's the C++ style).

2. The language can happily work correctly with a vector containing 
"widgets" and "whatsits" and treat them safely (even if the application 
code gets confused).  That's Python style.

3. The language can happily accept the nonsense at compile time, perhaps 
copying only bits of the "whatsit" or including rubbish in the vector. 
No one knows what will happen, and as you try to use the "whatsit" as 
though it were a "widget", you can cause all kinds of corruption or 
problems that turn up as unexpected effects in completely different 
parts of the code making debugging a nightmare.  That's C "void*" style.


Then you have user convenience.  If you want to set the field "x" in 
element "i" of vector "v" to 1, in C++ you write "v[i].x = 1;".  In C 
"generic containers", you write:

	widget * p;
	vector_get_as_reference(v, i, &p);
	p->x = 1;

Or maybe you have something with macro wrappers :

	VECTOR_GET_AS_REF(v, i, widget)->x = 1;


I haven't even covered whether you should be holding copies of the 
widget structures in the vector, or references to them, or references 
with reference counters, or how you might handle allocation of new 
widgets and freeing of old ones.

You /can/ do it all in C, but the usage of the containers will not be 
comparable in terms of convenience for the programmer, safety, or 
efficiency.

The norm in C is to make the lists or containers you need for the data 
types you need and the features you need.  Usually that's not too hard, 
and the results are hugely nicer to use and more efficient than any C 
generic containers.


That doesn't mean generic containers in C are a bad idea - especially 
more advanced containers that are harder for programmers to write 
themselves.  But don't kid yourself that you'll get something as nice as 
C++'s standard containers, or the containers built into most higher 
level languages.

[toc] | [prev] | [next] | [standalone]

#168252

On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote:
> On 17/11/2022 14:18, A wrote: 
> > On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote: 
> >> On 17/11/2022 06:31, Amit wrote: 
> >> 
> >> Anyway a lot of your suggestions really demand generic solutions, and C 
> >> doesn't have generic types. For those, there are myriad more assorted 
> >> ways to add those to C, but the results are usually ungainly and painful 
> >> to use. 
> >> 
> >> C is just not suited for such things. 
> > 
> > Generics can be implemented in C without much hassle. 
> >
> No, they cannot.

I am implementing them and for me it is not a hassle.



> > I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL. 
> >
> No, they cannot. 
> 

Why? You can save any kind of data in void *. Psuedocode is below:

save(void *x, len)
{
//assume, memory, etc. is allocated.
memcpy(generic_data_struct->data, data, len);
}

User code:

struct a temp;
save(&temp, sizeof(temp));

> Of course you can make generic containers in C, but you cannot approach 
> the user convenience, safety, or efficiency that is found in other 
> languages that have better support for this kind of thing. You have no 
> choice but to use generic "void *" pointers, long names, and awkward syntax. 

I am not trying to do all those - safety, or efficiency, etc. I am just implementing them because I want to do this in my free time. And, in case, someone uses my code then it will be a bonus.

Why would the syntax be awkward? It is straight forward C syntax.

The following lines of code don't look awkward to me:

memcpy(generic_data_struct->data, data, len);
save(&temp, sizeof(temp));

Amit

[toc] | [prev] | [next] | [standalone]

#168254

On 18/11/2022 11:32, A wrote:
> 
> On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote:
>> On 17/11/2022 14:18, A wrote:
>>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>>>> On 17/11/2022 06:31, Amit wrote:
>>>>
>>>> Anyway a lot of your suggestions really demand generic solutions, and C
>>>> doesn't have generic types. For those, there are myriad more assorted
>>>> ways to add those to C, but the results are usually ungainly and painful
>>>> to use.
>>>>
>>>> C is just not suited for such things.
>>>
>>> Generics can be implemented in C without much hassle.
>>>
>> No, they cannot.
> 
> I am implementing them and for me it is not a hassle.
> 
> 
> 
>>> I am currently implementing C++ STL in C. And the my data structures are generic - any type of data can be used just like in C++ STL.
>>>
>> No, they cannot.
>>
> 
> Why? You can save any kind of data in void *. 

Exactly.  Including the wrong kind.

> Psuedocode is below:
> 
> save(void *x, len)
> {
> //assume, memory, etc. is allocated.
> memcpy(generic_data_struct->data, data, len);
> }
> 
> User code:
> 
> struct a temp;
> save(&temp, sizeof(temp));

That won't help anyone - there is nowhere to store the data.

> 
>> Of course you can make generic containers in C, but you cannot approach
>> the user convenience, safety, or efficiency that is found in other
>> languages that have better support for this kind of thing. You have no
>> choice but to use generic "void *" pointers, long names, and awkward syntax.
> 
> I am not trying to do all those - safety, or efficiency, etc. I am just implementing them because I want to do this in my free time. And, in case, someone uses my code then it will be a bonus.
> 

Doing things for fun and interest is always a good enough reason in my 
book.  But you should be aware of what you are doing, and what you are 
not doing!

And if you /want/ other people to use your code (it's a great way to get 
feedback with bug reports or suggestions), you will want to:

a) Use size_t like the rest of the world.

b) Stop making impossible claims about it and its usability.

c) Read the feedback and responses you get from discussions, with the 
understanding that people are giving you free advice to help you write 
better code.

> Why would the syntax be awkward? It is straight forward C syntax.
> 

You didn't read my post, did you?  Try it again - there's little point 
in my repeating myself.

> The following lines of code don't look awkward to me:
> 
> memcpy(generic_data_struct->data, data, len);
> save(&temp, sizeof(temp));
> 
> Amit

[toc] | [prev] | [next] | [standalone]

#168256

On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
> On 18/11/2022 11:32, A wrote: 
> > 
> > On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote: 
> >> On 17/11/2022 14:18, A wrote: 
> >>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote: 
> >>>> On 17/11/2022 06:31, Amit wrote: 
> >>>> 


> a) Use size_t like the rest of the world. 
> 

This is a problem. If I am not convinced then why should I follow the world? The world can use size_t but I will use long and if the world says that I should be using size_t then I will ignore that. And if because of this, no one wants to use my code then its fine with me. I am writing this code for myself, not for the world, and if someone wants to use it, its fine. If no one uses it then that is also fine with me.

But in my company, I definitely follow company's coding guidelines.

But for my personal software, I follow my coding guidelines even if it is different from the world. I am not forcing anyone to use my software. Its all free will.

About reading your post, I did read your post. It looks like you are referring to the following code of yours:

----------------
Then you have user convenience. If you want to set the field "x" in
element "i" of vector "v" to 1, in C++ you write "v[i].x = 1;". In C
"generic containers", you write:

widget * p;
vector_get_as_reference(v, i, &p);
p->x = 1;

Or maybe you have something with macro wrappers :

VECTOR_GET_AS_REF(v, i, widget)->x = 1;
----------------

Here, the point is that the data is opaque to my library. My library doesn't know what's there in the data. So, my library can't modify the data.

The user only knows what's there in the data. So, my library code won't be awkward.

My structure is:

struct element
{
    void *data;
    long data_len;
    struct element *next;
};

And if user has stored widget * in data then the user can do:

elem = get_element(i);
((widget *)(elem->data))->x = 1.

The user code also doesn't look awkward to me but I am not sure but even if it is then should I (as a library developer) be bothered about that?

Amit

[toc] | [prev] | [next] | [standalone]

#168259

On 18/11/2022 13:47, A wrote:
> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
>> On 18/11/2022 11:32, A wrote:
>>>
>>> On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote:
>>>> On 17/11/2022 14:18, A wrote:
>>>>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>>>>>> On 17/11/2022 06:31, Amit wrote:
>>>>>>
> 
> 
>> a) Use size_t like the rest of the world.
>>
> 
> This is a problem. If I am not convinced then why should I follow the world? The world can use size_t but I will use long and if the world says that I should be using size_t then I will ignore that. And if because of this, no one wants to use my code then its fine with me. I am writing this code for myself, not for the world, and if someone wants to use it, its fine. If no one uses it then that is also fine with me.
> 
> But in my company, I definitely follow company's coding guidelines.
> 
> But for my personal software, I follow my coding guidelines even if it is different from the world. I am not forcing anyone to use my software. Its all free will.
> 

You can write any kind of code for yourself - that's fine, of course. 
But it seems a strange point to battle the world about.


> About reading your post, I did read your post. It looks like you are referring to the following code of yours:
> 
> ----------------
> Then you have user convenience. If you want to set the field "x" in
> element "i" of vector "v" to 1, in C++ you write "v[i].x = 1;". In C
> "generic containers", you write:
> 
> widget * p;
> vector_get_as_reference(v, i, &p);
> p->x = 1;
> 
> Or maybe you have something with macro wrappers :
> 
> VECTOR_GET_AS_REF(v, i, widget)->x = 1;
> ----------------
> 
> Here, the point is that the data is opaque to my library. My library doesn't know what's there in the data. So, my library can't modify the data.
> 
> The user only knows what's there in the data. So, my library code won't be awkward.
> 
> My structure is:
> 
> struct element
> {
>      void *data;
>      long data_len;
>      struct element *next;
> };
> 
> And if user has stored widget * in data then the user can do:
> 
> elem = get_element(i);
> ((widget *)(elem->data))->x = 1.
> 
> The user code also doesn't look awkward to me but I am not sure but even if it is then should I (as a library developer) be bothered about that?
> 
> Amit


Again, you are missing any way of identifying which container is in use. 
  Surely your code supports more than one container in a program?

So the user code in your setup (for element "i" in vector "v") would be 
something like :

	struct element * elem = get_element(v, i)
	((widget *)(elem->data))->x = 1

And you don't think that is awkward compared to :

	v[i].x = 1;

?

[toc] | [prev] | [next] | [standalone]

#168260

On Friday, 18 November 2022 at 18:29:24 UTC+5:30, David Brown wrote:
> On 18/11/2022 13:47, A wrote: 
> > On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote: 
> >> On 18/11/2022 11:32, A wrote: 
> >>> 
> >>> On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote: 
> >>>> On 17/11/2022 14:18, A wrote: 
> >>>>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote: 
> >>>>>> On 17/11/2022 06:31, Amit wrote: 
> >>>>>> 
> > 
> > 
> >> a) Use size_t like the rest of the world. 
> >> 
> > 
> > This is a problem. If I am not convinced then why should I follow the world? The world can use size_t but I will use long and if the world says that I should be using size_t then I will ignore that. And if because of this, no one wants to use my code then its fine with me. I am writing this code for myself, not for the world, and if someone wants to use it, its fine. If no one uses it then that is also fine with me. 
> > 
> > But in my company, I definitely follow company's coding guidelines. 
> > 
> > But for my personal software, I follow my coding guidelines even if it is different from the world. I am not forcing anyone to use my software. Its all free will. 
> >
> You can write any kind of code for yourself - that's fine, of course. 
> But it seems a strange point to battle the world about.

I was only trying to check whether the world would agree with me. The world didn't agree with me and it is fine.

> Again, you are missing any way of identifying which container is in use. 
> Surely your code supports more than one container in a program? 
>

My library supports only one container. I have different libraries for different containers. Generic set is a library, then generic map is another different library, and so on.
 
> So the user code in your setup (for element "i" in vector "v") would be 
> something like : 
> 
> struct element * elem = get_element(v, i)
> ((widget *)(elem->data))->x = 1
> And you don't think that is awkward compared to :
> v[i].x = 1;
> ?

In comparison, it definitely looks awkward.

But as standalone, the above C code doesn't look awkward to me - in the companies that I have worked for, I had to do far more awkward things in C than this. One example was to convert raw bytes into nested structures of a 3G telecommunications networking protocol way back in 2000 - 2001 for Lucent.

I think you must also would have written lot of awkward code in C. 

Amit

[toc] | [prev] | [next] | [standalone]

#168262

On 18/11/2022 12:47, A wrote:
> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
>> On 18/11/2022 11:32, A wrote:
>>>
>>> On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote:
>>>> On 17/11/2022 14:18, A wrote:
>>>>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>>>>>> On 17/11/2022 06:31, Amit wrote:
>>>>>>
> 
> 
>> a) Use size_t like the rest of the world.
>>
> 
> This is a problem. If I am not convinced then why should I follow the world? The world can use size_t but I will use long and if the world says that I should be using size_t then I will ignore that.

I use neither long nor size_t when calling `malloc`.

Because I normally use it via an FFI from other languages. The only 
thing I need to know is that its parameter is a 64-bit unsigned type on 
my platforms of interest.

I write that as 'u64', which is an exactly defined type in the language 
I use.

The problem with `long` in C is that the language only specifies that it 
is a signed type of at least 32 bits. It's actual size depends on platform.

So I'd stay clear of it. If I was using C to call malloc, I'd define 
'u64' on top of `unsigned long long`, or on top of `uint64_t`, which I 
know will be that size for all platforms of interest.

[toc] | [prev] | [next] | [standalone]

#168319

On 18/11/2022 18:04, Bart wrote:
> On 18/11/2022 12:47, A wrote:
>> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
>>> On 18/11/2022 11:32, A wrote:
>>>>
>>>> On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote:
>>>>> On 17/11/2022 14:18, A wrote:
>>>>>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote:
>>>>>>> On 17/11/2022 06:31, Amit wrote:
>>>>>>>
>>
>>
>>> a) Use size_t like the rest of the world.
>>>
>>
>> This is a problem. If I am not convinced then why should I follow the 
>> world? The world can use size_t but I will use long and if the world 
>> says that I should be using size_t then I will ignore that.
> 
> I use neither long nor size_t when calling `malloc`.
> 
> Because I normally use it via an FFI from other languages. The only 
> thing I need to know is that its parameter is a 64-bit unsigned type on 
> my platforms of interest.
> 
> I write that as 'u64', which is an exactly defined type in the language 
> I use.
> 
> The problem with `long` in C is that the language only specifies that it 
> is a signed type of at least 32 bits. It's actual size depends on platform.
> 
> So I'd stay clear of it. If I was using C to call malloc, I'd define 
> 'u64' on top of `unsigned long long`, or on top of `uint64_t`, which I 
> know will be that size for all platforms of interest.
> 

I appreciate preferring to use explicitly sized types.  And I appreciate 
preferring them over types whose size may vary between platforms, even 
on the same target processor, such as "long".

But unless you have decided that the only platforms that are of interest 
to you are those with 64-bit size_t, then calling malloc with a 
parameter of type u64 (or "uint64_t", as we say in C), will be wrong on 
other targets.

Maybe you no longer care about targets other than 64-bit PCs.  And I 
have no idea what the OP is targeting.

[toc] | [prev] | [next] | [standalone]

#168323 — Bart (Was: Why is glibc not extensive?)

In article <tlfajl$3ov81$1@dont-email.me>,
David Brown  <david.brown@hesbynett.no> wrote:
...
>But unless you have decided that the only platforms that are of interest 
>to you are those with 64-bit size_t, then calling malloc with a 
>parameter of type u64 (or "uint64_t", as we say in C), will be wrong on 
>other targets.
>
>Maybe you no longer care about targets other than 64-bit PCs.  And I 
>have no idea what the OP is targeting.

Bart has certainly made it clear in multiple postings to this newsgroup
that the only platform he cares about is 64-bit PCs.  So, no ifs, buts or
maybes about that.

So, your implicit criticism of that position rings hollow.

-- 
If you don't have faith, it's because you are reading the Bible with an
honest, truthful, real-answer seeking heart.

    - Rick C Hodgin -

[toc] | [prev] | [next] | [standalone]

#168324

On Friday, November 18, 2022 at 2:47:42 PM UTC+2, A wrote:
> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote: 
> > On 18/11/2022 11:32, A wrote: 
> > > 
> > > On Friday, 18 November 2022 at 14:03:00 UTC+5:30, David Brown wrote: 
> > >> On 17/11/2022 14:18, A wrote: 
> > >>> On Thursday, 17 November 2022 at 18:35:22 UTC+5:30, Bart wrote: 
> > >>>> On 17/11/2022 06:31, Amit wrote: 
> > >>>> 
> 
> 
> > a) Use size_t like the rest of the world. 
> >
> This is a problem. If I am not convinced then why should I follow the world? The world can use size_t but I will use long and if the world says that I should be using size_t then I will ignore that.

So, you don't want to use size_t because it is unsigned. Well.
Then use signed type ptrdiff_t. When you want to hold size of 
arbitrary objects ptrdiff_t is more portable than 'long'.
In corner case of size of object that occupies more than half
of address space both ptrdiff_t and 'long' are not good enough,
but at least ptrdiff_t works in all other cases. The same can't
be said about 'long' which does not work in pretty common case
of size of big objects (>= 2GB) on Win64.

There is also non-C-standard signed type ssize_t that is 
visually more similar to size_t and available pretty widely.
But I see no reasons to prefer it over ptrdiff_t.
Also, in my book visual similarity is a disadvantage.

[toc] | [prev] | [next] | [standalone]

#168355

Michael S <already5chosen@yahoo.com> writes:

> On Friday, November 18, 2022 at 2:47:42 PM UTC+2, A wrote:
>
>> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:

[...]

>>> a) Use size_t like the rest of the world.
>>
>> This is a problem.  If I am not convinced then why should I follow
>> the world?  The world can use size_t but I will use long and if the
>> world says that I should be using size_t then I will ignore that.
>
> So, you don't want to use size_t because it is unsigned.  Well.
> Then use signed type ptrdiff_t.  When you want to hold size of
> arbitrary objects ptrdiff_t is more portable than 'long'.
> In corner case of size of object that occupies more than half
> of address space both ptrdiff_t and 'long' are not good enough,
> but at least ptrdiff_t works in all other cases.  The same can't
> be said about 'long' which does not work in pretty common case
> of size of big objects (>= 2GB) on Win64.

IMO it's a mistake to hard-wire either 'long' or 'ptrdiff_t' to
be the name of a (signed) size type.  Whatever type is chosen
should allow as wide a range of values as needed, and neither of
those types will necessarily do that.  Furthermore the type name
used should reflect the purpose rather than the representation.
Assuming the name 's_size' is considered appropriate and
acceptable, a suitable typedef can be chosen using a scheme
along these lines:

    #include <limits.h>
    #include <stdint.h>

    #if INT_MAX >= SIZE_MAX
    typedef int             s_size;
    #elif LONG_MAX >= SIZE_MAX
    typedef long            s_size;
    #elif defined LLONG_MAX && LLONG_MAX >= SIZE_MAX
    typedef long long       s_size;
    #else
    typedef intmax_t        s_size;
    #endif

after which any interfaces desired should use 's_size' for values
of a signed size type.

[toc] | [prev] | [next] | [standalone]

#168358

On Saturday, November 26, 2022 at 7:08:15 PM UTC+2, Tim Rentsch wrote:
> Michael S <already...@yahoo.com> writes: 
> 
> > On Friday, November 18, 2022 at 2:47:42 PM UTC+2, A wrote: 
> > 
> >> On Friday, 18 November 2022 at 17:39:58 UTC+5:30, David Brown wrote:
> [...]
> >>> a) Use size_t like the rest of the world. 
> >> 
> >> This is a problem. If I am not convinced then why should I follow 
> >> the world? The world can use size_t but I will use long and if the 
> >> world says that I should be using size_t then I will ignore that. 
> > 
> > So, you don't want to use size_t because it is unsigned. Well. 
> > Then use signed type ptrdiff_t. When you want to hold size of 
> > arbitrary objects ptrdiff_t is more portable than 'long'. 
> > In corner case of size of object that occupies more than half 
> > of address space both ptrdiff_t and 'long' are not good enough, 
> > but at least ptrdiff_t works in all other cases. The same can't 
> > be said about 'long' which does not work in pretty common case 
> > of size of big objects (>= 2GB) on Win64.
> IMO it's a mistake to hard-wire either 'long' or 'ptrdiff_t' to 
> be the name of a (signed) size type. Whatever type is chosen 
> should allow as wide a range of values as needed, and neither of 
> those types will necessarily do that. Furthermore the type name 
> used should reflect the purpose rather than the representation. 
> Assuming the name 's_size' is considered appropriate and 
> acceptable, a suitable typedef can be chosen using a scheme 
> along these lines: 
> 
> #include <limits.h> 
> #include <stdint.h> 
> 
> #if INT_MAX >= SIZE_MAX 
> typedef int s_size; 
> #elif LONG_MAX >= SIZE_MAX 
> typedef long s_size; 
> #elif defined LLONG_MAX && LLONG_MAX >= SIZE_MAX 
> typedef long long s_size; 
> #else 
> typedef intmax_t s_size; 
> #endif 
> 
> after which any interfaces desired should use 's_size' for values 
> of a signed size type.

Your solution is theoretically pure but I don't find it practical.
For example, I don't want 64-bit s_size on my Cortex-M that
in practice will never ever have objects  bigger than 2**31-1.

Also, hopefully before I am retired, intmax_t on common 64-bit 
platforms (x86-64, ARM64, POWER) will become 128-bit.
In my personal opinion, it's long overdue.
If current rate of Moore Law is not improved then even with
all conservatism of standard bodies it will happen several 
decades before the first individual object reaches 2**63-1.
Or, much more likely,  on 64-bit architectures, size of 
individual objects will never be as big as  2**63-1. If it at all
happens, it would be long after migration to wider addresses.
So, if we follow your suggestion, we'll use 128-bit s_size 
on 64-bit platforms for sole benefit of compatibility with very
unlikely corner case in very remote future.

 

[toc] | [prev] | [next] | [standalone]

#168361

On 2022-11-27, Michael S <already5chosen@yahoo.com> wrote:
> If current rate of Moore Law is not improved then even with
> all conservatism of standard bodies it will happen several 
> decades before the first individual object reaches 2**63-1.

Currently, people are using the top bits of 64 bit pointers
for funny things:

- Android implements pointer-tagging. The upper 16 bits of a pointer
are a tag, which can be used to validate it.  E.g. if you malloc
some space, free it and malloc again such that the same space
is returned, it will have a different tag. The hardware strips
away the tag; only the lower 48 bits (at most) is significant.

- A collection of techiques called NaN boxing can store a 50 bit
pointer, fully unboxed 64 bit double, or a 50 bit integer, in a 64 bit
word. This is a boon for dynamic languages, which can have unboxed
floats.

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal

[toc] | [prev] | [next] | [standalone]

#168363

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>On 2022-11-27, Michael S <already5chosen@yahoo.com> wrote:
>> If current rate of Moore Law is not improved then even with
>> all conservatism of standard bodies it will happen several 
>> decades before the first individual object reaches 2**63-1.
>
>Currently, people are using the top bits of 64 bit pointers
>for funny things:
>
>- Android implements pointer-tagging. The upper 16 bits of a pointer
>are a tag, which can be used to validate it.  E.g. if you malloc
>some space, free it and malloc again such that the same space
>is returned, it will have a different tag. The hardware strips
>away the tag; only the lower 48 bits (at most) is significant.

Android is an operating system, not a processor architecture.

"The hardware strips away the tag". The typical hardware used for
android that can strip (technically, ignore) tags is ARMv8.

The translation control register contains a bit called "TBI" which
tells the page table walker to ignore the most significant byte of
the virtual address when translating to a physical address.  Software
is free to use that byte for its own tagging purposes. This is the
mechanism used by Android when running on ARMv8 hardware and
support for this feature is in Android 11 and up.  See chapter
D8.7 in DDI0487I.a.

If the processor supports the option FEAT_PAUTH feature, then the the
upper bits of the virtual address contain a cryptographic pointer authentication
code (produced and checked by special instructions).  The size of the PAC
field is related to the size of the virtual address as
configured in translation control registers (which can be
configured to be at most 52 bits (leaving 12 for the PAC tag)
or at the smallest, 25 bits (16 bits if the optional FEAT_TTST
feature is implemented) leaving 39 (or 48) bits for the PAC code.
See chapter D8.8 in DDI0487I.a.

When using FEAT_PAC, the hardware both creates and verifies the
authentication code.

https://source.android.com/docs/security/test/tagged-pointers

ARM added (in V8.5) an optional feature called MTE (Memory Tagging
Extension) which has a separate 4-bit tag for each 16 bytes in the
tagged memory range.  These bits are independent of the 16-byte
region[*]. I'm not currently aware of any implementation of ARMv8
that supports this extension.   Each access to memory from an
application where MTE is enabled will match the current application
tag with the tag associated with the memory being accessed and
abort the access on a tag mismatch.  See chapter D9 in DDI0487I.a.

[*] conceptually, tag ram is a distinct physical memory space not
accessible from software except via special privileged
instructions.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web