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.
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 =
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
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
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
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:
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
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
Quoth Bakul Shah :
> 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;}
> On May 15, 2022, at 8:23 AM, Dan Cross wrote:
>
> On Sun, May 15, 2022 at 9:16 AM adr 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
On Sun, 15 May 2022, o...@eigenstate.org wrote:
On Sun, 15 May 2022, arn...@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
On Sun, May 15, 2022 at 9:16 AM adr 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,
Quoth adr :
> On Sun, 15 May 2022, arn...@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
Quoth adr :
> 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
>
On Sun, 15 May 2022, arn...@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*
adr 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.
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
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
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,
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
20 matches
Mail list logo
