This is the mail archive of the
mailing list for the glibc project.
Re: inet_aton 0x0 in integer in structure
-----BEGIN PGP SIGNED MESSAGE-----
On Fri, May 12, 2017 at 01:08:13PM +0200, Toebs Douglass wrote:
> On 12/05/17 13:02, email@example.com wrote:
> > On Fri, May 12, 2017 at 11:56:40AM +0200, firstname.lastname@example.org wrote:
> >> It is valid ANSI C code and it makes sense. And it is a pointer,
> >> like in the header:
> >> extern int inet_aton (const char *__cp, struct in_addr *__inp) __THROW;
> >> The compiler accepted it as well.
> > No. Sorry to be a bit blunt, but I think you haven't understood C.
> The language itself does not express what should happen here. A pointer
> looks the same as a pointer to allocated store. Of course, a developer
> familiar with C will infer the latter because if you were going to
> allocate in the function you'd pass in a pointer to pointer - but,
> again, here, the language is not itself *actually explicitly expressing
> in what you actually write* what's what. A pointer is a pointer is a
> pointer :-)
I take something back. Automatic variables are actually uninitialized
(they may contain stuff that has been left ofer in the stack). So
the OP's pointer might be actually pointing to anything.
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
-----END PGP SIGNATURE-----