>> On 09/28/2011 06:39 AM, Steven M. Schweda wrote:
>>> From: Micah Cowan
In this case, the logic that does a rename of snprintf seems to be at
the end of "vasnprintf.h" rather than directly in snprintf.c.
>>>
>>> Those aren't the droids you're looking for. Try "lib/stdio.in.h"
>>>
From: Micah Cowan
> On 09/28/2011 06:39 AM, Steven M. Schweda wrote:
> > From: Micah Cowan
> >> In this case, the logic that does a rename of snprintf seems to be at
> >> the end of "vasnprintf.h" rather than directly in snprintf.c.
> >
> > Those aren't the droids you're looking for. Try "l
On 09/28/2011 06:39 AM, Steven M. Schweda wrote:
> From: Micah Cowan
>> In this case, the logic that does a rename of snprintf seems to be at
>> the end of "vasnprintf.h" rather than directly in snprintf.c.
>
> Those aren't the droids you're looking for. Try "lib/stdio.in.h"
> (which I also t
From: Micah Cowan
> But, on the other hand, when it chooses to supply its own, it carefully
> macros it away so that the real linker name is something different.
> However, the way it does this (and the way it decides whether to even
> build sprintf.c in the first place), is embedded in the expec
On Tue, 27 Sep 2011, Tim Pizey wrote:
(For what it is worth curl appears to return unix status 0 for 404 pages, I
can at least check for status 8 with wget)
curl instead offers a rather fancy way of outputting selected information
using its -w option, which could include the HTTP status.
I'
