git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] fread does not return negative on error

From
IMIngo Molnar <mingo@elte.hu>
Date
Jun 24, 2009, 12:12 UTC
Message-ID
<20090624121226.GA20564@elte.hu>
In-Reply-To
<c07716ae0906240353h67932054w3dc3ba6dbb864dff@mail.gmail.com>
* Christian Couder <christian.couder@gmail.com> wrote:
Show 54 quoted lines
> Hi,
> 
> On Wed, Jun 24, 2009 at 10:18 AM, Ingo Molnar<mingo@elte.hu> wrote:
> >
> > * Junio C Hamano <gitster@pobox.com> wrote:
> >
> >> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> >>
> >> > the following patch is for git.  I just removed the unneeded check for
> >> > res == 0 from your version.  Does it look OK?
> >>
> >> The patch looks good, and both of our in-tree users do error out
> >> when the returned value is 0 (imap-send.c checks with "<= 0" which
> >> looks a tad amateurish, though) correctly.
> >>
> >> Funny, there is no caller of this function in the original context
> >> this bug originally found, which I think is linux-2.6/tools/perf
> >> ;-).
> >
> > Hehe, yes :-)
> >
> > Background: when creating tools/perf/ i cherry-picked all the nice
> > Git libraries into tools/perf/util/, to give a standard environment
> > for all tooling things that might come up in the future.
> >
> > Some of those are not used yet but it looked more logical to pick up
> > whole pieces - some already gained uses. For example config.c is not
> > truly used yet, but very much expected to have a role in the future.
> >
> > ( The only invasive thing i had to do was the s/git_/perf_/ mass
> >  rename across all the files - having 'git_' in perf looked
> >  quite confusing. )
> >
> > And our general experience with the Git libraries in
> > tools/perf/util/* is: we love them!
> >
> > For example parse-options.c is a striking improvement compared to
> > getopt.h we used before, and all the other facilities are sane and
> > straight to the point as well. So in this sense 'perf' is an ...
> > interesting cross-discipline 'fork' of Git's generic libraries.
> >
> > The auto-generation of everything out of Documentation/*.txt is
> > another thing we picked up, and that's very nice too.
> >
> > One bookeeping issue: i found few explicit credits in those files -
> > so i noted in the changelog that i took them from Git and i noted
> > the specific upstream Git sha1 when i copied them. Would be nice to
> > update each file with names to make credit more explicit:
> 
> >From http://git.kernel.org/?p=linux/kernel/git/x86/linux-2.6-tip.git;a=tree;f=tools/perf;hb=HEAD
>
> it looks like there may be some other files like builtin-help.c 
> (and perhaps some files in perf/Documentation/ too though there 
> should be some AUTHOR information already in them).

Correct - the makefile and the whole glue code (and much else!) comes from Git - see commits:

 0780060: perf_counter tools: add in basic glue from Git
 d24e473: perf_counter: copy in Git's top Makefile

Any suggestions about how best credit everyone there? One central linux/tools/perf/CREDITS file?

	Ingo
Previous: Christian CouderNext: Junio C Hamano
Message 13 of 14 in “Re: [PATCH] tools: fread does not return negative on error”
  1. Ingo MolnarJun 22, 2009
  2. roel kluinJun 22, 2009
  3. fread does not return negative on errorRené Scharfe, Jun 22, 2009
  4. Junio C HamanoJun 23, 2009
  5. Ingo MolnarJun 24, 2009
  6. Johannes SchindelinJun 24, 2009
  7. Junio C HamanoJun 24, 2009
  8. Johannes SchindelinJun 24, 2009
  9. Ingo MolnarJun 24, 2009
  10. Alex RiesenJun 24, 2009
  11. Junio C HamanoJun 24, 2009
  12. Christian CouderJun 24, 2009
  13. Ingo MolnarJun 24, 2009
  14. Junio C HamanoJun 25, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.