* [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).