From mboxrd@z Thu Jan  1 00:00:00 1970
Content-Type: multipart/mixed; boundary="===============1629652386163353738=="
MIME-Version: 1.0
From: Ali Bahrami <Ali.Bahrami@Oracle.COM>
To: elfutils-devel@lists.fedorahosted.org
Subject: Re: libelf gelf_newehdr and gelf_newphdr return types
Date: Tue, 06 Dec 2016 09:45:31 -0700
Message-ID: <24bd1ec2-efa2-e900-80cf-52dd27e1cd77@Oracle.COM>
In-Reply-To: 1481034712.15612.38.camel@klomp.org

--===============1629652386163353738==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

On 12/ 6/16 07:31 AM, Mark Wielaard wrote:
>   /* Some gelf_newehdr implementations don't return the resulting
>      ElfNN_Ehdr, so we have to do it the hard way instead of:
>      e_ident =3D (char *) gelf_newehdr (elf, gelf_getclass (dso->elf)); */
>   switch (gelf_getclass (dso->elf))
>     {
>     case ELFCLASS32:
>       e_ident =3D (char *) elf32_newehdr (elf);
>       break;
>     case ELFCLASS64:
>       e_ident =3D (char *) elf64_newehdr (elf);
>       break;
>     default:
>       e_ident =3D NULL;
>       break;
>     }
>
> Which is slightly horrible. But neither the Solaris documentation, nor
> the elfutils libelf documentation seem to actually make any promise
> about the return value. It is only implied that, like all gelf
> functions, zero will be returned on failure.
>
> I wanted to update the elfutils gelf documentation for these functions
> to state that the returned pointer is to the appropriate header for the
> ELF class. Which I believe is the only sane thing to do. I don't know of
> any libelf implementation where the comment from dwz is true.


    I'm not aware of libelf implementations where the return
value isn't the pointer to the underlying class specific
header, but I suppose that there could be one.

I never thought I'd argue against clarifying documentation,
but I'm not sure that making this any more explicit is really
helping anyone. It really doesn't make sense that a library
that exists to provide class independent access to objects
returns a class dependent pointer, and I think the intent
really is that callers only pay attention to 0 vs non-zero.
Perhaps the documentation should just say that, while the
internals return the pointer as they always have, to maintain
compatibility with the past.

- Ali

--===============1629652386163353738==--