[En-Nut-Discussion] strtok_r conflicts

[Theodore A. Roth]

On Tue, 12 Aug 2003 peter.scandrett at transport.alstom.com wrote:

> Hi all,
>
> Last night Ted Roth wrote
>         I also noticed that the strtok_r decl
>         in nutos is different than that in
>         avr-libc and linux.
>
> When I initially wrote STRTOK_R, STRSEP_R and STRSEP_RS quite a few years
> ago I was unaware of the existing function prototypes. (The net was not as
> big as it is today.)
>
> This is my dilemma. Do I modify these functions to fit in with the
> existing function prototypes, or do I leave it alone? The prototypes would
> change from
>         char * strtok_r(  char ** pp_str, char * p_term );
>         char * strsep_r(  char ** pp_str, char * p_term );
>         char * strsep_rs( char ** pp_str, char * p_term, char * p_sep );
> to
>         char * strtok_r(  char * p_str, char * p_term, char ** p_save );
>         char * strsep_r(  char * p_str, char * p_term, char ** p_save );
>         char * strsep_rs( char * p_str, char * p_term, char ** p_save,
> char * p_sep );
>
> Changing it now would mean the minimum amount of code change to others as
> my version has been in circulation for less than two months.
>
> My feeling is my version should change to be the same as linux, qnx, mks,
> redhat, gnu, novell, etc.. However this may not be the best in the long
> term. The changes are not big.

I'm curious why the change would "not be the best in the long term."

I would think that sticking to the standard (I'm assuming that linux,
et. al. adhere to the C standard) would be best in the long term.

>
> Your input, and especially Ted Roth's and Harald Kip's input, would be
> appreciated.

I have no idea about how wide-spread the use of your interface is, but
within the nut source, the impact appears to be minimal. It's really
Harald's call.

Ted Roth