[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GPT name overflow
From: |
Andrew Clausen |
Subject: |
Re: GPT name overflow |
Date: |
Tue, 19 Mar 2002 16:44:19 +1100 |
User-agent: |
Mutt/1.3.17i |
On Mon, Mar 18, 2002 at 03:56:12PM +0000, Richard Hirst wrote:
> hex/dec may not matter; I don't know bsd.
It's not a BSD issue, it's a Parted issue. I guess hex is
more widely used, so we should use it universally for integer
"type" values.
> API docs also need to note that the string returned from
> partition_get_type_name() is only valid until such time as someone calls
> the function again.
I prefer strdup()/free(), and removing the const tag...
That way, you can read it in the prototype (and still include in
the API).
A const thing might fool the person into thinking it's persistant.
> From a UI point of view, we would presumably need some way of querying
> each disk_*.c module for it's supported type names.
Good point. I can't see anything easier/more generic than
per-disk-label-type XXX_partition_type_get_next().
Andrew
- Re: GPT name overflow, Andrew Clausen, 2002/03/09
- Re: GPT name overflow, Andreas Dilger, 2002/03/09
- Re: GPT name overflow, Andreas Dilger, 2002/03/09
- Re: GPT name overflow, Andrew Clausen, 2002/03/09
- Re: GPT name overflow, Andreas Dilger, 2002/03/10
- Re: GPT name overflow, Andrew Clausen, 2002/03/10
- Re: GPT name overflow, Richard Hirst, 2002/03/18
- Re: GPT name overflow,
Andrew Clausen <=
- Re: GPT name overflow, Andreas Dilger, 2002/03/19
- Re: GPT name overflow, Andrew Clausen, 2002/03/19
- Re: GPT name overflow, Andreas Dilger, 2002/03/19
- Re: GPT name overflow, Andrew Clausen, 2002/03/19