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

Amit <amitchoudhary0523@gmail.com> writes:
>In my opinion, glibc should have support for maps, sets, balanced binary
>trees, many more string functions, etc.

That would make C what I call an "application programming language".

C is a system programming language, intended to be used to /implement/
such things as maps for application programming languages or to be
used for programming tasks where one can get by without such things.

Often, C programmers cheat a bit, choosing what /can/ be done in C.
For instance, the Python program

map ={ 'a': a, 'b': b }
map[ c ]()

could be translated into

if( !strcmp( c, "a" ))a();
else if( !strcmp( c, "b" ))b();
else unknown_name_error();

. While a sequence of comparisons should be slower than using a hash
map, the C version in practice will probably still be faster.

If you want to have maps you can either choose a C library for maps,
C++, or some application programming language.

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>If you want to have maps you can either choose a C library for maps,
>C++, or some application programming language.

BTW: In C++, they find that usually ::std::vector is faster
than any other container, even for those cases where the
other containers seem to match the requirements better.

Video "Modern C++: What You Need to Know" (2014) - Herb Sutter
(starting from the about minute twenty three - "Real arrays")

So, if one wants to implement any container in C, it might
be sensible to start with something like ::std::vector.
Maybe this is all one ever needs. For a start, one could
use this for strings.

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.

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

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

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};

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.

Am 17.11.2022 um 07:31 schrieb Amit:
> 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

glibc is for everything the C language supports as well as
Posix- SysV-,BSD- and Linux-spefic APIs. As C doesn't support
anything you suggest your idea doesn't fit.

In article <tl5t5c$2mnpk$1@dont-email.me>,
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Am 17.11.2022 um 07:31 schrieb Amit:
>> 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
>
>glibc is for everything the C language supports as well as
>Posix- SysV-,BSD- and Linux-spefic APIs. As C doesn't support
>anything you suggest your idea doesn't fit.
>

I heard about this time, back in 1993 or thereabouts, where someone made a
Usenet suggestion that something should be added to the existing libraries
in either C or Unix (not sure which, it was a long time ago) and at least
one responder *didn't* crap all over the idea.

Hasn't happened since, of course...

--
There's nothing more American than demanding to carry an AR-15 to
"protect yourself" but refusing to wear a mask to protect everyone else.

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.

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

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

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

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;

?

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

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.

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.

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 -

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.

On 11/18/2022 2:09 AM, Kenny McCormack wrote:
> In article <tl5t5c$2mnpk$1@dont-email.me>,
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Am 17.11.2022 um 07:31 schrieb Amit:
>>> 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
>>
>> glibc is for everything the C language supports as well as
>> Posix- SysV-,BSD- and Linux-spefic APIs. As C doesn't support
>> anything you suggest your idea doesn't fit.
>>
>
> I heard about this time, back in 1993 or thereabouts, where someone made a
> Usenet suggestion that something should be added to the existing libraries
> in either C or Unix (not sure which, it was a long time ago) and at least
> one responder *didn't* crap all over the idea.
>
> Hasn't happened since, of course...
>

Though to be fair, most stuff that makes sense in the C library is stuff
that is either relevant to the core language, or can't be done in a
portable or efficient way in C.

High-level features, like container libraries or data structures, do not
fit. These are better left to platform or 3rd party libraries.

As noted in the past, my ideas would include:
Ability to load/store values from a pointer with a specific size and
endianess;
Some extensions for malloc;
Some alternate memcpy variants with different semantics;
....

But could go further:
Some standardized-ish API for working with SIMD vectors.

As-is, this is a mix of implementation dependent and/or platform
dependent extensions. Ideally, it should also work independently of
if/what specific SIMD features are supported by the CPU (able to fall
back to a plain C implementation for targets) which lack native SIMD.

In my implementation, there are features which would not make as much
sense in C proper, such as extensions for a dynamic type system (my
compiler and ISA also partly get involved in the mechanics of the
dynamic type-system; which are also defined as part of the ABI rules).

Basically, it allows a "variant" type which may hold any type of value
as a tagged reference (or occasionally "boxing" values as heap-allocated
objects if they can't be held directly in the tagged-reference format).

This was relevant mostly to some of my other languages, and is also
seemingly coming up in the context of communication between tasks.

Say: Task A exists in one address space, Task B exists in another, and
one wants to pass some data from one to another.

If A malloc's something, and passes it to B, then B can't do anything
with it. A traditional approach would involve RPC and an IDL compiler
which has enough context to serialize and pass the data structures (say
via ASN.1 or whatever else).

But, with a dynamic type-system, it can be serialized and decoded
transparently without needing an IDL (and things like object-level
interfaces can be maintained transparently across task boundaries; the
underlying RPC events being mostly hidden from both parties).

Similarly, a more specialized mechanisms can be used for dealing with
buffer-like objects (say, a blob of bytes for IO, the contents of a "DIB
Bitmap Object", ...). (Say, the sending task registers the buffer as
"shared" and the receiving task "maps" the buffer via a syscall, which
then then performs a Task-to-Task memory copy if "read" or "dirty", and
when the buffer is released its contents are copied back to the original
buffer if it was mapped as "dirty" or "write"; the buffer typically
being "unshared" once the original call finishes).

This would then be wrapped in a more traditional C style interface.
Seemed like a "lesser evil" vs needing to deal with IDLs.

Note that local communication would use a bulky (but fast) serialization
scheme (mostly passing data as a blob of tagrefs with pointers replaced
with internal references into this blob). For "more general" use, would
likely use something akin to S-Expressions (the dynamic typesystem in
this case is along vaguely similar lines to those seen in Scheme and
Common Lisp), just printing and parsing S-Expressions would be too much
overhead for local communication between tasks.
An intermediate option being a more compact variable-length binary
serialization (say, not always burning 8 bytes for every fixnum, etc).

Such as a program talking to a GUI or Display HAL interface; used so
that it can draw contents to the screen without needing direct access to
the display hardware's framebuffer or similar. Where, in this case, this
was used rather than sockets (or the X11 protocol or similar). Seems
also like sockets would have had a higher overhead and latency in this
case than an RPC style mechanism (which in this case, more directly
invokes the task-switch mechanism; as a special type of syscall).

Interfaces across this mechanism can also take a form resembling COM
objects (but, a lot of the above comes up with "how does one pass data
beyond the basic argument list?"...).

But, yeah, not really sure what to make of this.
Makes some sense as platform level features, but not really as part of C
itself.

On 11/18/2022 2:32 AM, 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.
>

IMHO, one may eventually reach a point where it becomes "less of a
hassle" to use an API wrapper to implement dynamic types, say for
example, one has types like:
lvoVariant //can hold "whatever"

Then say, calls like:
lvoVariant lvoFixnum(int64_t val); //wrap as a fixnum
int64_t lvoGetFixnum(lvoVariant var); //get the fixnum
bool lvoFixnumP(lvoVariant var); //is this a fixnum?

lvoVariant lvoFlonum(double val); //wrap as a flonum
double lvoGetFlonum(lvoVariant var); //get the flonum
bool lvoFlonumP(lvoVariant var); //is this a flonum?

...

For arrays:
lvoVariant lvoGetIndex(lvoVariant obj, int idx);
int lvoSetIndex(lvoVariant obj, int idx, lvoVariant var);
...

For cons lists:
lvoVariant lvoCons(lvoVariant car, lvoVariant cdr); //make a cons
bool lvoConsP(lvoVariant var); //is this a cons?
lvoVariant lvoCar(lvoVariant); //get 'car' from cons
lvoVariant lvoCdr(lvoVariant); //get 'cdr' from cons
...

For other stuff:
lvoVariant lvoAdd(lvoVariant va, lvoVariant vb); //add two values
...

So, for your "generic" array or dictionary, one can basically just put
whatever into it, and it "magically works", as the containers don't
actually need to care what types they are being used to hold.

Granted, yes, this sort of thing is very awkward and slow vs normal C
style, but can scale better to more complex cases than trying to pretend
that C is C++ ...

No good way to do automatic GC or "destructors" in pure C, this would
effectively require wrapper calls to initialize and destroy every local
variable, wrappers to manage things like variable assignment, ...

Say (as macros):
lvoInit(varA); //create and initialize a variable to null
lvoDestroy(varA); //destroy variable when it leaves scope
lvoSet(varA, value); //modify a variable

This crosses the line though in terms of how much hassle one can
reasonably expect people to deal with.

Say:
lvoInit2(varA, varB);
lvoSet(varB, lvoFixnum(3));
lvoSet(varA, lvoAdd(varB, lvoFixnum(4)));
...
lvoDestroy2(varA, varB);

Slightly less of a pain if one can have compiler extensions though:
__var varA, varB; //"__var" keyword invokes magic
varA=3;
varB=varA+4;

Where the compiler can manage most of the "arcane magic" (so, no need to
'init', 'set' or 'destroy' variables as the compiler can figure out this
part).

But, alas, this will not work in a compiler that does not support
dynamic types, whereas an API like the above doesn't need to assume any
special compiler support.

Overall performance impact would be similar in both cases (just because
they are less visible, doesn't mean that the code isn't being
implemented internally in terms of a mess of function calls into the
runtime library and similar).

Similarly, it is still kinda awkward to use given the typesystems don't
mix particularly cleanly (no good way around this).

Though, can note that, even as such, at least in my case, the relative
performance overhead of using the dynamic typesystem tends to be "less
severe than one might intuitively expect".

....

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

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.

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.

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