On Sat, Aug 11, 2018 at 1:30 AM Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote
> On Sat, Aug 11 2018, Elijah Newren wrote:
>
> [CC'd sha1dc maintainers, for context the relevent patch is
> https://public-inbox.org/git/20180811043218.31456-8-new...@gmail.com/T/#u]
>
> >   * Patches 6-8: These patches might need to be submitted to separate
> >     projects elsewhere.  Let me know if so.
>
> Yes, for sha1dc (your 7/9) it's much better if we submit patches to
> upstream and then submit a patch to git.git to update from upstream, as
> my 23e37f8e9d ("sha1dc: update from upstream", 2018-08-02) sitting in
> 'next' does.
>
> When we build that library we define SHA1DC_NO_STANDARD_INCLUDES, so we
> don't use the codepath you patched, so your description of "I was bit
> yet again by compilation errors[...]" doesn't add up in that case. I
> assume you just started adding stdlib.h where you could grep for
> stdint.h.

The part of my story you snipped in the ellipsis is kind of important,
though: "...and decided to determine which header files were missing
their own necessary #include's and forward declarations."  The way I
did so was making a simple one-line .c file that included exactly one
header, and checked to see if I could compile it (without any special
defines), fixed it up as necessary, then repeated that process for
every toplevel header.

Most of the stdlib.h additions were for the definition of size_t,
sha1dc/sha1.h was no different; without my patch:

In file included from nukeme.c:1:0:
sha1dc/sha1.h:96:43: error: unknown type name ‘size_t’
 void SHA1DCUpdate(SHA1_CTX*, const char*, size_t);

Your point that we use SHA1DC_NO_STANDARD_INCLUDES normally when
compiling within git, though, does mean my patch #7 is kind of useless
to git.

> When I check out sha1collisiondetection.git stand-alone (which will use
> that path) and compile it, it works fine for me. This is on GCC 8.1.0 on
> Debian, so perhaps that patch isn't needed in that case.

I never said git or its subprojects failed to compile.  I said when I
added another #include of some header to some existing or new files, I
sometimes saw unknown symbol errors.  It's happened before, it
happened again today, and I got annoyed, so I set out to address it.
Sorry if that wasn't clear.

Reply via email to