Forgot to include the changes to the header file in the first patch.
(Oops. Without that, the compiler optimizes out the null test because
it has a crazy "this can never be null" optimization hint applied.)
No idea what the _THROW is for and whether or not I should have
removed that or left it?
On Sunday 25 October 2009 15:19:49 Rob Landley wrote:
> - int readlinks = 0;
> + int readlinks = 0, allocated = 0;
> ...
> + if (!got_path) {
> + got_path = alloca(PATH_MAX);
> + allocated++;
> + }
> ...
> + if (allocated) got_path = strdup(got_path);
it
On Monday 26 October 2009 07:20:23 Mike Frysinger wrote:
> On Sunday 25 October 2009 15:19:49 Rob Landley wrote:
> > - int readlinks = 0;
> > + int readlinks = 0, allocated = 0;
> > ...
> > + if (!got_path) {
> > + got_path = alloca(PATH_MAX);
> > + allocated++;
> > + }
On Mon, 26 Oct 2009, Rob Landley wrote:
... Also, in my experience _Bool is about as real-world useful as the
bit field notation with the colons, and is really there to keep the
language pedants and the c++ guys happy without actually accomplishing
much. I've never seen it actually produce b
On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
>
>On Mon, 26 Oct 2009, Rob Landley wrote:
>
>>... Also, in my experience _Bool is about as real-world useful as
>>the bit field notation with the colons, and is really there to keep
>>the language pedants and the c++ guys happy with
On Tuesday 27 October 2009 08:54:50 Ricard Wanderlof wrote:
> It can produce more readable, less error-prone C code though. We use
> hardware register definitions such as
>
> typedef struct {
>unsigned int x : 8;
>unsigned int y : 8;
>unsigned int control_bit : 1;
>unsigned int dumm
On Tuesday 27 October 2009 02:54:50 Ricard Wanderlof wrote:
> On Mon, 26 Oct 2009, Rob Landley wrote:
> > ... Also, in my experience _Bool is about as real-world useful as the
> > bit field notation with the colons, and is really there to keep the
> > language pedants and the c++ guys happy without
On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> >On Mon, 26 Oct 2009, Rob Landley wrote:
> >>... Also, in my experience _Bool is about as real-world useful as
> >>the bit field notation with the colons, and is
On Tue, 27 Oct 2009, Rob Landley wrote:
On Mon, 26 Oct 2009, Rob Landley wrote:
... Also, in my experience _Bool is about as real-world useful as the
bit field notation with the colons, and is really there to keep the
language pedants and the c++ guys happy without actually accomplishing
much.
On Tuesday 27 October 2009 13:46:19 Chris Gray wrote:
> On Tuesday 27 October 2009 08:54:50 Ricard Wanderlof wrote:
> > It can produce more readable, less error-prone C code though. We use
> > hardware register definitions such as
> >
> > typedef struct {
> >unsigned int x : 8;
> >unsigned
On Tuesday 27 October 2009 15:44:42 Rob Landley wrote:
> On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> > On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> > >On Mon, 26 Oct 2009, Rob Landley wrote:
> > >>... Also, in my experience _Bool is about as real-wor
On Wednesday 28 October 2009 03:47:03 Mike Frysinger wrote:
> while the memory leakage needs to be addressed, the answer isnt with
> alloca. the spec states that it must be via malloc(), but even ignoring
> that, it also states that the caller must call free() on the returned
> pointer. obvious
On Tuesday 27 October 2009 15:44:42 Rob Landley wrote:
> On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> > On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> > >On Mon, 26 Oct 2009, Rob Landley wrote:
> > >>... Also, in my experience _Bool is about as real-wor
> -Original Message-
> From: uclibc-boun...@uclibc.org [mailto:uclibc-boun...@uclibc.org] On
> Behalf Of Mike Frysinger
> Sent: den 28 oktober 2009 09:02
> To: uclibc@uclibc.org
> Subject: Re: Quick and dirty malloc() support for realpath.
[ cut ]
> @@ -114,6 +1
On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> From: Mike Frysinger
>
> [ cut ]
>
> > @@ -114,6 +114,8 @@ char got_path[];
> > while (*path != '\0' && *path != '/') {
> > if (new_path > max_path) {
> > __set_errno(ENAM
On Wed, Oct 28, 2009 at 05:12:55AM -0400, Mike Frysinger wrote:
>On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
>> From: Mike Frysinger
better but the prototype part is missing (and a note that this
particular func now adheres to SUSv4 base, eventually)
___
> -Original Message-
> From: Mike Frysinger [mailto:vap...@gentoo.org]
> Sent: den 28 oktober 2009 10:13
> To: Peter Kjellerstedt
> Cc: uclibc@uclibc.org
> Subject: Re: Quick and dirty malloc() support for realpath.
>
> On Wednesday 28 October 2009 04:57:01
On Wednesday 28 October 2009 02:47:03 Mike Frysinger wrote:
> On Tuesday 27 October 2009 15:44:42 Rob Landley wrote:
> > On Tuesday 27 October 2009 05:51:05 Bernhard Reutner-Fischer wrote:
> > > On Tue, Oct 27, 2009 at 08:54:50AM +0100, Ricard Wanderlof wrote:
> > > >On Mon, 26 Oct 2009, Rob Landle
On Wednesday 28 October 2009 07:57:50 Bernhard Reutner-Fischer wrote:
> On Wed, Oct 28, 2009 at 05:12:55AM -0400, Mike Frysinger wrote:
> >On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> >> From: Mike Frysinger
>
> better but the prototype part is missing (and a note that this
>
On Wednesday 28 October 2009 08:08:40 Peter Kjellerstedt wrote:
> > From: Mike Frysinger [mailto:vap...@gentoo.org]
> > On Wednesday 28 October 2009 04:57:01 Peter Kjellerstedt wrote:
> > > From: Mike Frysinger
> > > > our friend goto solves the leak. stick it in the middle of the file
> > > > to
On Wed, Oct 28, 2009 at 12:19:44PM -0500, Rob Landley wrote:
>Please read the patch I submitted.
>
>@@ -168,5 +172,6 @@
>new_path--;
>/* Make sure it's null terminated. */
>*new_path = '\0';
>+ if (allocated) got_path = strdup(got_path);
please follow the esta
On Wed, Oct 28, 2009 at 02:21:39PM -0400, Mike Frysinger wrote:
>did you want me to commit then ?
Please do.
___
uClibc mailing list
uClibc@uclibc.org
http://lists.busybox.net/mailman/listinfo/uclibc
22 matches
Mail list logo
