[PATCH] Fix for lib/tst_res.c -- fix -m vs non-m reporting functions

[yaneurabeya]

Hello again all,

     After running a few checks it appears that the -m and the non-m
functions were doing the same exact thing in lib/tst_res.c (at least
in the April and May snapshots of ltp-full). This patch fixes the
behavior so tst_resm and tst_res no longer do the same thing (output
to stdout only), but instead (like the manpage says and the original
intention was):

tst_resm:
     - Output in deterministic way, depending on input parameters provided.

tst_res
     - Do same thing as tst_resm, but output to file specified (and
stdout), or just stdout if file == NULL.

     I also added a sidenote to cat_file as well, considering that
someone (unlikely, but you never know us black-hat folks ;)...) might
pass in a /dev node instead of a typical regular file, and as such
there might need to be another check provided to cat_file or tst_print
*shrugs*...

     Questions and comments are welcome as always.

-Garrett


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Nate Straz-2]

On Jun 18 10:26, Garrett Cooper wrote:

>      After running a few checks it appears that the -m and the non-m
> functions were doing the same exact thing in lib/tst_res.c (at least
> in the April and May snapshots of ltp-full). This patch fixes the
> behavior so tst_resm and tst_res no longer do the same thing (output
> to stdout only), but instead (like the manpage says and the original
> intention was):
>
> tst_resm:
>      - Output in deterministic way, depending on input parameters provided.
>
> tst_res
>      - Do same thing as tst_resm, but output to file specified (and
> stdout), or just stdout if file == NULL.

Which man page did you pull these from?  That's not correct at all.  

I see in ltp/doc/man3/tst_res.3:

       tst_res - Print result message, including file contents

       tst_resm - Print result message

-1 to the patch.

Nate

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On Thu, Jul 3, 2008 at 8:46 AM, Nate Straz <nate@...> wrote:

> On Jun 18 10:26, Garrett Cooper wrote:
>>      After running a few checks it appears that the -m and the non-m
>> functions were doing the same exact thing in lib/tst_res.c (at least
>> in the April and May snapshots of ltp-full). This patch fixes the
>> behavior so tst_resm and tst_res no longer do the same thing (output
>> to stdout only), but instead (like the manpage says and the original
>> intention was):
>>
>> tst_resm:
>>      - Output in deterministic way, depending on input parameters provided.
>>
>> tst_res
>>      - Do same thing as tst_resm, but output to file specified (and
>> stdout), or just stdout if file == NULL.
>
> Which man page did you pull these from?  That's not correct at all.
>
> I see in ltp/doc/man3/tst_res.3:
>
>       tst_res - Print result message, including file contents
>
>       tst_resm - Print result message
>
> -1 to the patch.
>
> Nate

Ok... based on the manpage description that's what I was originally
thinking, but then I got off on a wild tangent, thinking "THIS MUST BE
THE WAY!" (in a conquistador fashion 8-)..).

Is there a specific use-case where that type of function behavior is
desired instead of just using tst_resm's behavior? I see a lot of code
in the syscalls portion of the tree at least, like so:

tst_res(TBROK, NULL, ...)

instead of

tst_resm(TBROK, ...)

so, maybe the purpose of tst_resm vs tst_res needs to be better
clarified in the manpages?

-Garrett

PS As a sidenote it would be really snazzy if someone could stick the
manpages up online, similar to what FreeBSD does:
<http://www.freebsd.org/cgi/man.cgi>. Not a critical point, but
definitely helpful functionality, and helpful when providing a
reference to people =).

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[Nate Straz-2]

On Jul  3 10:19, Garrett Cooper wrote:

> On Thu, Jul 3, 2008 at 8:46 AM, Nate Straz <nate@...> wrote:
> > On Jun 18 10:26, Garrett Cooper wrote:
> >>      After running a few checks it appears that the -m and the non-m
> >> functions were doing the same exact thing in lib/tst_res.c (at least
> >> in the April and May snapshots of ltp-full). This patch fixes the
> >> behavior so tst_resm and tst_res no longer do the same thing (output
> >> to stdout only), but instead (like the manpage says and the original
> >> intention was):
> >>
> >> tst_resm:
> >>      - Output in deterministic way, depending on input parameters provided.
> >>
> >> tst_res
> >>      - Do same thing as tst_resm, but output to file specified (and
> >> stdout), or just stdout if file == NULL.
> >
> > Which man page did you pull these from?  That's not correct at all.
> >
> > I see in ltp/doc/man3/tst_res.3:
> >
> >       tst_res - Print result message, including file contents
> >
> >       tst_resm - Print result message
> >
> > -1 to the patch.
>
> Ok... based on the manpage description that's what I was originally
> thinking, but then I got off on a wild tangent, thinking "THIS MUST BE
> THE WAY!" (in a conquistador fashion 8-)..).
>
> Is there a specific use-case where that type of function behavior is
> desired instead of just using tst_resm's behavior? I see a lot of code
> in the syscalls portion of the tree at least, like so:
>
> tst_res(TBROK, NULL, ...)

I could only guess that they wanted to print the contents of a file
which was previously output by tst_res(), but I don't think that's how
it is supposed to work.

I think those cases can be safely converted to use tst_resm().

> so, maybe the purpose of tst_resm vs tst_res needs to be better
> clarified in the manpages?

I guess so.  For the record, tst_res() is for including the contents of
a temporary file in your results.  tst_resm() is for just printing a
message.

> PS As a sidenote it would be really snazzy if someone could stick the
> manpages up online, similar to what FreeBSD does:
> <http://www.freebsd.org/cgi/man.cgi>. Not a critical point, but
> definitely helpful functionality, and helpful when providing a
> reference to people =).

That sounds reasonable, but then we should really write more man pages.
:)

Nate

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list

[yaneurabeya]

On Thu, Jul 3, 2008 at 10:34 AM, Nate Straz <nate@...> wrote:

> On Jul  3 10:19, Garrett Cooper wrote:
>> On Thu, Jul 3, 2008 at 8:46 AM, Nate Straz <nate@...> wrote:
>> > On Jun 18 10:26, Garrett Cooper wrote:
>> >>      After running a few checks it appears that the -m and the non-m
>> >> functions were doing the same exact thing in lib/tst_res.c (at least
>> >> in the April and May snapshots of ltp-full). This patch fixes the
>> >> behavior so tst_resm and tst_res no longer do the same thing (output
>> >> to stdout only), but instead (like the manpage says and the original
>> >> intention was):
>> >>
>> >> tst_resm:
>> >>      - Output in deterministic way, depending on input parameters provided.
>> >>
>> >> tst_res
>> >>      - Do same thing as tst_resm, but output to file specified (and
>> >> stdout), or just stdout if file == NULL.
>> >
>> > Which man page did you pull these from?  That's not correct at all.
>> >
>> > I see in ltp/doc/man3/tst_res.3:
>> >
>> >       tst_res - Print result message, including file contents
>> >
>> >       tst_resm - Print result message
>> >
>> > -1 to the patch.
>>
>> Ok... based on the manpage description that's what I was originally
>> thinking, but then I got off on a wild tangent, thinking "THIS MUST BE
>> THE WAY!" (in a conquistador fashion 8-)..).
>>
>> Is there a specific use-case where that type of function behavior is
>> desired instead of just using tst_resm's behavior? I see a lot of code
>> in the syscalls portion of the tree at least, like so:
>>
>> tst_res(TBROK, NULL, ...)
>
> I could only guess that they wanted to print the contents of a file
> which was previously output by tst_res(), but I don't think that's how
> it is supposed to work.
>
> I think those cases can be safely converted to use tst_resm().
>
>> so, maybe the purpose of tst_resm vs tst_res needs to be better
>> clarified in the manpages?
>
> I guess so.  For the record, tst_res() is for including the contents of
> a temporary file in your results.  tst_resm() is for just printing a
> message.

Ok, now that makes sense. For cases when mktemp / mkstemp are used,
right, right...

>> PS As a sidenote it would be really snazzy if someone could stick the
>> manpages up online, similar to what FreeBSD does:
>> <http://www.freebsd.org/cgi/man.cgi>. Not a critical point, but
>> definitely helpful functionality, and helpful when providing a
>> reference to people =).
>
> That sounds reasonable, but then we should really write more man pages.
> :)

Another task to file on my plate, once I'm done with my major task of
revising the makefiles =].
-Garrett

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Ltp-list mailing list
Ltp-list@...
https://lists.sourceforge.net/lists/listinfo/ltp-list