9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] void*
@ 2022-05-15 10:58 adr
  2022-05-15 12:11 ` Humm
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: adr @ 2022-05-15 10:58 UTC (permalink / raw)
  To: 9fans

Hi,
one of the first thing I noticed compiling in plan9 is that arithmetic
on void* is illegal. Other compilers treat void* as uchar*.
Conceptually, it  makes sense. A pointer to void doesn't point to
any object. But then I've seen the use of void* in functions (like
memccpy) when the pointed object is going to be processed as a
byte array. Local uchar*'s are used to do the trick inside the
function.

It wouldn't make more sense to avoid the use of void*
and just use instead uchar* or better still u8int*?

Some thoughts?

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M7d5d7a58e7e77b74d2aa123a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 10:58 [9fans] void* adr
@ 2022-05-15 12:11 ` Humm
  2022-05-15 13:03   ` adr
  2022-05-15 14:46 ` ori
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 20+ messages in thread
From: Humm @ 2022-05-15 12:11 UTC (permalink / raw)
  To: 9fans

>one of the first thing I noticed compiling in plan9 is that arithmetic 
>on void* is illegal.

That’s what the standard says.

While Plan 9 C doesn’t pretend to be compliant, the core language does 
roughly match C89 with a few C99 extensions.

>Other compilers treat void* as uchar*. Conceptually, it  makes sense. 
>A pointer to void doesn't point to any object. But then I've seen the 
>use of void* in functions (like memccpy) when the pointed object is 
>going to be processed as a byte array. Local uchar*'s are used to do 
>the trick inside the function.
>
>It wouldn't make more sense to avoid the use of void* and just use 
>instead uchar* or better still u8int*?

(Those are different.  On Plan 9, we do make (too many) assumptions 
about type sizes, but conceptually, a byte need not be limited to eight 
bit.)

I’m now quoting the C99 Rationale (revision 5.10).

Page 37, § 6.2.5:

>A pointer to void must have the same representation and alignment as 
>a pointer to char; the intent of this rule is to allow existing 
>programs that call library functions such as memcpy and free to 
>continue to work.

Page 48, § 6.3.2.3:

>The use of void* (“pointer to void”) as a generic object pointer type 
>is an invention of the C89 Committee.  Adoption of this type was 
>stimulated by the desire to specify function prototype arguments that 
>either quietly convert arbitrary pointers (as in fread) or complain if 
>the argument type does not exactly match (as in strcmp).

-- 
Humm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Me2a3b163527df44b207e4fc3
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 12:11 ` Humm
@ 2022-05-15 13:03   ` adr
  2022-05-15 13:15     ` adr
  0 siblings, 1 reply; 20+ messages in thread
From: adr @ 2022-05-15 13:03 UTC (permalink / raw)
  To: 9fans

What I mean is if we are going to follow C99 in the use of void*,
we should allow arithmetic on them. If not, there is not point to
use void* as char*, just use char* as the generic pointer. When I
ask something here about the Plan9 compilers, I'm not asking about
some committee's standard, I have access to them, like everyone
else.

By the way I'm curious, someone knows a modern machine with
CHAR_BIT>8? I would prefer to use fixed-width types and let the
compiler deal with these (nowadays) eccentricities.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M3ffa29ce3e6bd94227835bd6
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 13:03   ` adr
@ 2022-05-15 13:15     ` adr
  2022-05-15 13:21       ` arnold
  2022-05-15 15:23       ` Dan Cross
  0 siblings, 2 replies; 20+ messages in thread
From: adr @ 2022-05-15 13:15 UTC (permalink / raw)
  To: 9fans

On Sun, 15 May 2022, adr wrote:

> What I mean is if we are going to follow C99 in the use of void*,
> we should allow arithmetic on them.

Let me be clear, I know that C99 requires the pointer to be a
complete object type to do arithmetic, and I like that, is consistent.
But then I don't see the point to use void* as a generic pointer.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M1f0eaeec24bbe0f8c2c06b0f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 13:15     ` adr
@ 2022-05-15 13:21       ` arnold
  2022-05-15 14:09         ` adr
  2022-05-15 15:23       ` Dan Cross
  1 sibling, 1 reply; 20+ messages in thread
From: arnold @ 2022-05-15 13:21 UTC (permalink / raw)
  To: 9fans

adr <adr@SDF.ORG> wrote:

> On Sun, 15 May 2022, adr wrote:
>
> > What I mean is if we are going to follow C99 in the use of void*,
> > we should allow arithmetic on them.
>
> Let me be clear, I know that C99 requires the pointer to be a
> complete object type to do arithmetic, and I like that, is consistent.
> But then I don't see the point to use void* as a generic pointer.

It allows you pass pointers of any type without requiring casts:

        struct foo s[5] = ...
        memmove(s, & s[1], 4 * sizeof(struct foo));     // shift down 1

The compiler won't complain because any pointer type can be passed
to a void* parameter.  Otherwise you'd need to cast:

        memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));

void* has been standard practice (even on Plan 9) for 30+ years.
It's not worth changing it now. :-)

HTH,

Arnold

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Md96cca95ce4773408cff1b24
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 13:21       ` arnold
@ 2022-05-15 14:09         ` adr
  2022-05-15 14:47           ` ori
  0 siblings, 1 reply; 20+ messages in thread
From: adr @ 2022-05-15 14:09 UTC (permalink / raw)
  To: 9fans

On Sun, 15 May 2022, arnold@skeeve.com wrote:

> It allows you pass pointers of any type without requiring casts:
>
>        struct foo s[5] = ...
>        memmove(s, & s[1], 4 * sizeof(struct foo));     // shift down 1
>
> The compiler won't complain because any pointer type can be passed
> to a void* parameter.  Otherwise you'd need to cast:
>
>        memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));

Sure, but you could change it to do the same with char*.

> void* has been standard practice (even on Plan 9) for 30+ years.
> It's not worth changing it now. :-)

I agree, I just wanted to share some opinions.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M9bc3acdf4dd19efb75ea5a51
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 10:58 [9fans] void* adr
  2022-05-15 12:11 ` Humm
@ 2022-05-15 14:46 ` ori
  2022-05-15 16:07 ` adr
  2022-05-16 14:46 ` Charles Forsyth
  3 siblings, 0 replies; 20+ messages in thread
From: ori @ 2022-05-15 14:46 UTC (permalink / raw)
  To: 9fans

Quoth adr <adr@SDF.ORG>:
> Hi,
> one of the first thing I noticed compiling in plan9 is that arithmetic
> on void* is illegal. Other compilers treat void* as uchar*.
> Conceptually, it  makes sense. A pointer to void doesn't point to
> any object. But then I've seen the use of void* in functions (like
> memccpy) when the pointed object is going to be processed as a
> byte array. Local uchar*'s are used to do the trick inside the
> function.
> 

arithmetic on void* is a gnu extension. It also implies
sizeof(void) == 1; this is indeed true with gcc.

I also don't think it's useful enough to add a special
case to an already special case: it's rare to be able
to do pointer arithmetic on void and *not* access the
memory, in my experience.

> It wouldn't make more sense to avoid the use of void*
> and just use instead uchar* or better still u8int*?

the unique thing about void* is that there is an implicit
conversion from any pointer type to void*; there is not
for uchar* or u8int*.

        memset((u8int*)&x, 0, sizeof(x));

seems unnecessarily clunky.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Ma63068d9d401c85e69d9d87f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 14:09         ` adr
@ 2022-05-15 14:47           ` ori
  2022-05-15 15:49             ` adr
  0 siblings, 1 reply; 20+ messages in thread
From: ori @ 2022-05-15 14:47 UTC (permalink / raw)
  To: 9fans

Quoth adr <adr@SDF.ORG>:
> On Sun, 15 May 2022, arnold@skeeve.com wrote:
> 
> > It allows you pass pointers of any type without requiring casts:
> >
> >        struct foo s[5] = ...
> >        memmove(s, & s[1], 4 * sizeof(struct foo));     // shift down 1
> >
> > The compiler won't complain because any pointer type can be passed
> > to a void* parameter.  Otherwise you'd need to cast:
> >
> >        memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));
> 
> Sure, but you could change it to do the same with char*.
> 

char* has legitimate uses for things other than generic pointers,
and the conversion complaints catch bugs.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M78e7984543661c669776370b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 13:15     ` adr
  2022-05-15 13:21       ` arnold
@ 2022-05-15 15:23       ` Dan Cross
  2022-05-15 15:50         ` Bakul Shah
  1 sibling, 1 reply; 20+ messages in thread
From: Dan Cross @ 2022-05-15 15:23 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]

On Sun, May 15, 2022 at 9:16 AM adr <adr@sdf.org> wrote:

> On Sun, 15 May 2022, adr wrote:
> > What I mean is if we are going to follow C99 in the use of void*,
> > we should allow arithmetic on them.
>
> Let me be clear, I know that C99 requires the pointer to be a
> complete object type to do arithmetic, and I like that, is consistent.
> But then I don't see the point to use void* as a generic pointer.


I confess that I am confused about what, precisely, you are asking for.

You are correct that standard C only allows arithmetic on pointers to
complete object types. But `void *` is not a pointer to a complete object
type, and so therefore pointer arithmetic on pointers of type `void *` is
illegal. So in that sense, Plan 9 C is already following C99.

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M697dfcf01429a681db4155b2
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 1854 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 14:47           ` ori
@ 2022-05-15 15:49             ` adr
  0 siblings, 0 replies; 20+ messages in thread
From: adr @ 2022-05-15 15:49 UTC (permalink / raw)
  To: 9fans

On Sun, 15 May 2022, ori@eigenstate.org wrote:
>> On Sun, 15 May 2022, arnold@skeeve.com wrote:
>>
>>> It allows you pass pointers of any type without requiring casts:
>>>
>>>        struct foo s[5] = ...
>>>        memmove(s, & s[1], 4 * sizeof(struct foo));     // shift down 1
>>>
>>> The compiler won't complain because any pointer type can be passed
>>> to a void* parameter.  Otherwise you'd need to cast:
>>>
>>>        memmove((uchar*) s, (uchar*) & s[1], 4 * sizeof(struct foo));
>>
>> Sure, but you could change it to do the same with char*.
>>
>
> char* has legitimate uses for things other than generic pointers,
> and the conversion complaints catch bugs.

My point here is that It makes more sense to me to use a generic
pointer which have a size (the type it points) of 1, so arithmetic
can be applied to it. Of course I'm not proposing to change the
compiler and all the code. It was just a reflection. Allowing
arithmetic on void* solves the problem. Reading the definition of
void this could look incongruous, but C99 already specifies:

"A pointer to void shall have the same representation and alignment requirements as a
pointer to a character type"

So I don't see any real trouble to allow the same operations as with char*.

Again, just some thoughts. The comments about uchar* or uint8* are
because arithmetic on void* brakes the concept of void, I don't
really like it.  But sometime things are doomed to staid as they
are, even if they don't make sense...

adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M7092e86f1d4c6f710af49d81
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 15:23       ` Dan Cross
@ 2022-05-15 15:50         ` Bakul Shah
  2022-05-15 15:54           ` ori
  0 siblings, 1 reply; 20+ messages in thread
From: Bakul Shah @ 2022-05-15 15:50 UTC (permalink / raw)
  To: 9fans



> On May 15, 2022, at 8:23 AM, Dan Cross <crossd@gmail.com> wrote:
> 
> On Sun, May 15, 2022 at 9:16 AM adr <adr@sdf.org> wrote:
> On Sun, 15 May 2022, adr wrote:
> > What I mean is if we are going to follow C99 in the use of void*,
> > we should allow arithmetic on them.
> 
> Let me be clear, I know that C99 requires the pointer to be a
> complete object type to do arithmetic, and I like that, is consistent.
> But then I don't see the point to use void* as a generic pointer.
> 
> I confess that I am confused about what, precisely, you are asking for.
> 
> You are correct that standard C only allows arithmetic on pointers to complete object types. But `void *` is not a pointer to a complete object type, and so therefore pointer arithmetic on pointers of type `void *` is illegal. So in that sense, Plan 9 C is already following C99.
> 
>         - Dan C.

Can't quote chapter and verse but AFAIK standard C allows +/- on void*.
So for example the following is legal:

void*f(void*x){return x+1;}

The returned value will be one more than the arg.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M57ca9f2db655438f69c42dbf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 15:50         ` Bakul Shah
@ 2022-05-15 15:54           ` ori
  0 siblings, 0 replies; 20+ messages in thread
From: ori @ 2022-05-15 15:54 UTC (permalink / raw)
  To: 9fans

Quoth Bakul Shah <bakul@iitbombay.org>:
> void*f(void*x){return x+1;}

        $ echo 'void*f(void*x){return x+1;}' > test.c
        $ cc -pedantic -std=c99 test.c
        test.c:4:24: warning: arithmetic on a pointer to void is a GNU extension [-Wpointer-arith]
                void*f(void*x){return x+1;}
                                      ~^


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Mfcc883e249a0aefbd19623f0
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 10:58 [9fans] void* adr
  2022-05-15 12:11 ` Humm
  2022-05-15 14:46 ` ori
@ 2022-05-15 16:07 ` adr
  2022-05-16  6:24   ` Skip Tavakkolian
  2022-05-16 14:46 ` Charles Forsyth
  3 siblings, 1 reply; 20+ messages in thread
From: adr @ 2022-05-15 16:07 UTC (permalink / raw)
  To: 9fans

In case someone is asking why this guy is suddenly so thoughtful
about void pointers, it is because I'm porting Ali Gholami Rudi's
neatroof, and he uses a lot of arithmetics with void* in neatmkfn.
I got rid of ape, and this troff looks really easy to port and has
a lot of features. I'll share it when it's working in case someone
is interested.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M683ed8fb049de7a5d4457cbf
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 16:07 ` adr
@ 2022-05-16  6:24   ` Skip Tavakkolian
  2022-05-16 12:46     ` Humm
  2022-05-16 13:23     ` Bakul Shah
  0 siblings, 2 replies; 20+ messages in thread
From: Skip Tavakkolian @ 2022-05-16  6:24 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

If void can have a size, why not 4, 8 or 16?

P.S. I discovered Gholami Rudi's work a little while ago. I was especially
intrigued by Farsi support in neatroff (intro in Farsi produced by Neatroff
and Neatpost: https://litcave.rudi.ir/neatfarsi.pdf)  Cool stuff.


On Sun, May 15, 2022, 9:09 AM adr <adr@sdf.org> wrote:

> In case someone is asking why this guy is suddenly so thoughtful
> about void pointers, it is because I'm porting Ali Gholami Rudi's
> neatroof, and he uses a lot of arithmetics with void* in neatmkfn.
> I got rid of ape, and this troff looks really easy to port and has
> a lot of features. I'll share it when it's working in case someone
> is interested.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M9e20019333d1d1dbde3a2c3d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2489 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-16  6:24   ` Skip Tavakkolian
@ 2022-05-16 12:46     ` Humm
  2022-05-16 13:23     ` Bakul Shah
  1 sibling, 0 replies; 20+ messages in thread
From: Humm @ 2022-05-16 12:46 UTC (permalink / raw)
  To: 9fans

Quoth Skip Tavakkolian:
>If void can have a size, why not 4, 8 or 16?

Really, if it would have a size, it should be zero.  And thus p+n==p.  
Not too useful.  It’s fine as it is.

-- 
Humm

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-Ma41fef7117a53447879d3343
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-16  6:24   ` Skip Tavakkolian
  2022-05-16 12:46     ` Humm
@ 2022-05-16 13:23     ` Bakul Shah
  1 sibling, 0 replies; 20+ messages in thread
From: Bakul Shah @ 2022-05-16 13:23 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 2013 bytes --]

I can see some use of void* arithmetic for malloc/free or
when you’re doing your own allocation for various object
types, where a size of 1 would be handy.

I wonder what a FarC would like!

> On May 15, 2022, at 11:27 PM, Skip Tavakkolian <skip.tavakkolian@gmail.com> wrote:
> 
> 
> If void can have a size, why not 4, 8 or 16?
> 
> P.S. I discovered Gholami Rudi's work a little while ago. I was especially intrigued by Farsi support in neatroff (intro in Farsi produced by Neatroff and Neatpost: https://litcave.rudi.ir/neatfarsi.pdf <https://litcave.rudi.ir/neatfarsi.pdf>)  Cool stuff.
> 
> 
> On Sun, May 15, 2022, 9:09 AM adr <adr@sdf.org <mailto:adr@sdf.org>> wrote:
> In case someone is asking why this guy is suddenly so thoughtful
> about void pointers, it is because I'm porting Ali Gholami Rudi's
> neatroof, and he uses a lot of arithmetics with void* in neatmkfn.
> I got rid of ape, and this troff looks really easy to port and has
> a lot of features. I'll share it when it's working in case someone
> is interested.
> 
> ------------------------------------------
> 9fans: 9fans
> Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M683ed8fb049de7a5d4457cbf <https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M683ed8fb049de7a5d4457cbf>
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription <https://9fans.topicbox.com/groups/9fans/subscription>
> 9fans <https://9fans.topicbox.com/latest> / 9fans / see discussions <https://9fans.topicbox.com/groups/9fans> + participants <https://9fans.topicbox.com/groups/9fans/members> + delivery options <https://9fans.topicbox.com/groups/9fans/subscription>Permalink <https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M9e20019333d1d1dbde3a2c3d>
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M5831ffd0a329bdcb8294ee6b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 3764 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-15 10:58 [9fans] void* adr
                   ` (2 preceding siblings ...)
  2022-05-15 16:07 ` adr
@ 2022-05-16 14:46 ` Charles Forsyth
  2022-05-16 16:03   ` adr
  3 siblings, 1 reply; 20+ messages in thread
From: Charles Forsyth @ 2022-05-16 14:46 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]

it's void* because that can be assigned between other pointer types without
a cast.
x = malloc(sizeof(*x)); instead of x = (T*)malloc(sizeof(*x)); which just
adds clutter.
Similarly it's just free(x) instead of free((void*)x); (or free((uchar*)x)
as I understand your suggestion).


On Sun, 15 May 2022 at 11:59, adr <adr@sdf.org> wrote:

> Hi,
> one of the first thing I noticed compiling in plan9 is that arithmetic
> on void* is illegal. Other compilers treat void* as uchar*.
> Conceptually, it  makes sense. A pointer to void doesn't point to
> any object. But then I've seen the use of void* in functions (like
> memccpy) when the pointed object is going to be processed as a
> byte array. Local uchar*'s are used to do the trick inside the
> function.
> 
> It wouldn't make more sense to avoid the use of void*
> and just use instead uchar* or better still u8int*?
> 
> Some thoughts?
> 
> Regards,
> adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M057b5e29e604b46338b87e89
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 2477 bytes --]

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-16 14:46 ` Charles Forsyth
@ 2022-05-16 16:03   ` adr
  2022-05-16 17:45     ` hiro
  0 siblings, 1 reply; 20+ messages in thread
From: adr @ 2022-05-16 16:03 UTC (permalink / raw)
  To: 9fans

On Mon, 16 May 2022, Charles Forsyth wrote:
> it's void* because that can be assigned between other pointer types without a cast.x = malloc(sizeof(*x));
> instead of x = (T*)malloc(sizeof(*x)); which just adds clutter.
> Similarly it's just free(x) instead of free((void*)x); (or free((uchar*)x) as I understand your
> suggestion).

The idea I wanted to share, more as a light chat than as a suggestion
is that I would find more useful to have a generic pointer (with
the property you have just described) with size (the object pointed
to) of 1. I don't expect anyone to be happy about substituting
void*. GNU (and I think clang followed suit) just made the size of
void* 1. I don't really like this because it breaks the concept of
void, that's the reason I talk about char* and uint8*. But I think
I'm repeating my self a lot, so I will silently retreat back through
the hedge.

Regards,
adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M95c0625b8879224f86e28cd8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-16 16:03   ` adr
@ 2022-05-16 17:45     ` hiro
  2022-05-17  4:00       ` Lucio De Re
  0 siblings, 1 reply; 20+ messages in thread
From: hiro @ 2022-05-16 17:45 UTC (permalink / raw)
  To: 9fans

i still don't understand it. if you want a pointer of size 1 what
keeps you from using a generic char or uint8 pointer?

On 5/16/22, adr <adr@sdf.org> wrote:
> On Mon, 16 May 2022, Charles Forsyth wrote:
>> it's void* because that can be assigned between other pointer types
>> without a cast.x = malloc(sizeof(*x));
>> instead of x = (T*)malloc(sizeof(*x)); which just adds clutter.
>> Similarly it's just free(x) instead of free((void*)x); (or free((uchar*)x)
>> as I understand your
>> suggestion).
> 
> The idea I wanted to share, more as a light chat than as a suggestion
> is that I would find more useful to have a generic pointer (with
> the property you have just described) with size (the object pointed
> to) of 1. I don't expect anyone to be happy about substituting
> void*. GNU (and I think clang followed suit) just made the size of
> void* 1. I don't really like this because it breaks the concept of
> void, that's the reason I talk about char* and uint8*. But I think
> I'm repeating my self a lot, so I will silently retreat back through
> the hedge.
> 
> Regards,
> adr.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M390b72c2b74c880b53607f48
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [9fans] void*
  2022-05-16 17:45     ` hiro
@ 2022-05-17  4:00       ` Lucio De Re
  0 siblings, 0 replies; 20+ messages in thread
From: Lucio De Re @ 2022-05-17  4:00 UTC (permalink / raw)
  To: 9fans

On 5/16/22, hiro <23hiro@gmail.com> wrote:
> i still don't understand it. if you want a pointer of size 1 what
> keeps you from using a generic char or uint8 pointer?
>
I think what he's asking is "what's keeping everyone else from using...".

I guess we're all evangelists at heart.

Lucio.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M1d737e4ac0476d1f4c711af8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2022-05-17  4:00 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-15 10:58 [9fans] void* adr
2022-05-15 12:11 ` Humm
2022-05-15 13:03   ` adr
2022-05-15 13:15     ` adr
2022-05-15 13:21       ` arnold
2022-05-15 14:09         ` adr
2022-05-15 14:47           ` ori
2022-05-15 15:49             ` adr
2022-05-15 15:23       ` Dan Cross
2022-05-15 15:50         ` Bakul Shah
2022-05-15 15:54           ` ori
2022-05-15 14:46 ` ori
2022-05-15 16:07 ` adr
2022-05-16  6:24   ` Skip Tavakkolian
2022-05-16 12:46     ` Humm
2022-05-16 13:23     ` Bakul Shah
2022-05-16 14:46 ` Charles Forsyth
2022-05-16 16:03   ` adr
2022-05-16 17:45     ` hiro
2022-05-17  4:00       ` Lucio De Re

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).