Robert Story (Coders) wrote:
On Thu, 07 Oct 2004 21:43:48 -0400 Andy wrote:
AS> I did another CVS pull this
AS> afternoon and started with a fresh tree, I am getting unresolved
AS> references to strtok_r when I try to compile the agent. I looked for the
AS> function definition, but all 'grep -In
On Thu, 07 Oct 2004 21:43:48 -0400 Andy wrote:
AS> I did another CVS pull this
AS> afternoon and started with a fresh tree, I am getting unresolved
AS> references to strtok_r when I try to compile the agent. I looked for the
AS> function definition, but all 'grep -Inr strtok_r ./snmplib' bought
Has the local strtok_r function gone away completely now? I did a CVS
pull last night and was getting errors in the MinGW build about a header
included in strtok_r.c, ok...we can handle that. I was able to compile
by idefing the include out for mingw. I did another CVS pull this
afternoon and s
> So the current choices are:
>
> 1) add strtok_r to tool.c as a temporary location
>
> 2) add new file strtok_r.c (seems to be the previous pattern)
>
> 3) add a new file string_utils.c, merging in existing str*.c files
>
> 4) come to some quick concensus on what a proper directory hierarchy f
>
> From: Robert Story (Coders) <[EMAIL PROTECTED]>
> Date: 2004/10/05 Tue PM 07:39:06 EDT
> To: [EMAIL PROTECTED]
> Subject: Re: proposal: snmplib/string_utils.c
>
> On Tue, 5 Oct 2004 19:09:55 -0400 Robert wrote:
> RS> I'm looking at applying the strtok
eld
Cc: [EMAIL PROTECTED]
Subject: Re: proposal: snmplib/string_utils.c
On Wed, 06 Oct 2004 09:44:01 +0100 Dave wrote:
DS> > If people don't like combining them, how about at least putting
DS> > them in a sub-directory?
DS>
DS> I have long been advocating a more structured
On Wed, 06 Oct 2004 09:44:01 +0100 Dave wrote:
DS> > If people don't like combining them, how about at least putting them in a
DS> > sub-directory?
DS>
DS> I have long been advocating a more structured approach to the library.
DS> But I don't think now is the right time to start doing this.
Ok, i
> If people don't like combining them, how about at least putting them in a
> sub-directory?
I have long been advocating a more structured approach to the library.
But I don't think now is the right time to start doing this.
We're meant to be concentrating on getting 5.2 out of the door.
*Everyt
On Tue, 5 Oct 2004 19:45:01 -0400 [EMAIL PROTECTED] wrote:
SN> > From: Robert Story (Coders) <[EMAIL PROTECTED]>
SN> > Any objections to merging strlcpy.c, strtol.c, strtoul.c and the new
SN> > strtok_r into one file, string_utils.c? (or a similarly named file)
SN> >
SN> I see no reason to merge t
On Tue, 5 Oct 2004 16:30:13 -0700 Steve wrote:
SF> On Tue, Oct 05, 2004 at 07:09:55PM -0400, Robert Story wrote:
SF> This smells like a bad idea. I can imagine all kinds of linker issues if
SF> one of the functions is required by the platform [...]
The code already exists, in their own files. All
I see no reason to merge them together, do you ?
>
> From: Robert Story (Coders) <[EMAIL PROTECTED]>
> Date: 2004/10/05 Tue PM 07:09:55 EDT
> To: [EMAIL PROTECTED]
> Subject: proposal: snmplib/string_utils.c
>
> I'm looking at applying the strtok_r patch for 5.2, which will include a
> strtok_r
On Tue, 5 Oct 2004 19:09:55 -0400 Robert wrote:
RS> I'm looking at applying the strtok_r patch for 5.2, which will include a
RS> strtok_r implementation for platforms where it is missing. I started to
RS> look for a place to put that implementation, and I notices that there are
RS> several other st
On Tue, Oct 05, 2004 at 07:09:55PM -0400, Robert Story wrote:
> I'm looking at applying the strtok_r patch for 5.2, which will include a
> strtok_r implementation for platforms where it is missing. I started to look
> for a place to put that implementation, and I notices that there are several
> ot
13 matches
Mail list logo
