Re: [9fans] void*

2022-05-16 Thread Humm

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


Re: [9fans] void*

2022-05-16 Thread Bakul Shah
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  
> 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 
> )  Cool stuff.
> 
> 
> On Sun, May 15, 2022, 9:09 AM adr mailto:a...@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
>  
> 
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription 
> 
> 9fans  / 9fans / see discussions 
>  + participants 
>  + delivery options 
> Permalink 
> 
--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tecaea3b9ec8e7066-M5831ffd0a329bdcb8294ee6b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription


Re: [9fans] void*

2022-05-16 Thread Charles Forsyth
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  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


Re: [9fans] void*

2022-05-16 Thread adr

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


Re: [9fans] void*

2022-05-16 Thread hiro
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  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


Re: [9fans] void*

2022-05-16 Thread Lucio De Re
On 5/16/22, hiro <23h...@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


Re: [9fans] sam and 'here documents' on Unix [WAS: Re: Making multiple changes to dot using sam -d]

2022-05-16 Thread Mart Zirnask
Sorry for the late reply -- great hint, thanks very much.

In a perfect world, I would need a solution that also works on Windows
(with the ported unix/p9 tools), but I'll probably build the
sam9f-unix port by iru- [1] for now.

Btw, can anybody point me to the initial ^ and/or _ command patch?
In which 9front release were they added?

1: https://github.com/iru-/sam9f-unix

Thanks and best,
Mart

On 12/05/2022, umbrati...@prosimetrum.com  wrote:
> hmm, interesting. ^ is indeed very useful;
> making it work in sam -d is probably the
> correct thing to do but here's a quick hack.
> (9front specific, tho you can probably figure
> out another way to pretend you typed.)
> 
> umbraticus
> 
> ; fn f{echo ,x/red/c/blue >/dev/kbdin}
> ; sam -d
>  -.
> a
> I hired a red
> redemptionist
> .
> !f
> ,x/red/c/blue
> ,
> I hiblue a blue
> blueemptionist

--
9fans: 9fans
Permalink: 
https://9fans.topicbox.com/groups/9fans/Tcf06324837558cea-M8814cbe0749f46c6bd3477d8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription