Clean up vasprintf() usage

[derobins]

• Remove HD from vasprintf()
• Document that it's GNU/BSD, not POSIX
• Minor tidying

[qkoziol]

This change to make a macro of the same name as vasprintf() is going to be confusing and is the reason we put the HD prefix in place, so that users are aware that it isn't the system/library call. I would update the comments, but leave the HD prefix for this.

[derobins]

This change to make a macro of the same name as vasprintf() is going to be confusing and is the reason we put the HD prefix in place, so that users are aware that it isn't the system/library call. I would update the comments, but leave the HD prefix for this.

If the semantics are the same, should a developer care?

I can leave H5_ in front of the dozen or so calls that will be different on some platform, but that means that developers will have the cognitive overhead of remembering which random functions need the prefix. I think it's easier to say that we assume you have a POSIX system that conforms to POSIX.1-2008 and C99/C11 and that we'll do what it takes to fake that if you aren't compliant. vasprintf() is weird because it's GNU/BSD and not POSIX, so maybe we can do something different with that.

Like using H5_flock() or H5_(un)lock_file() for our file locking semantics is probably a good idea. Ditto H5_basename() since the semantics are not the same on all platforms. I'm not sure that people need to care that fseek() is _fseeki64() on Windows, though.

Basically, what I'm trying to do is the same thing that POSIX did with LFS.

[hyoklee]

This change to make a macro of the same name as vasprintf() is going to be confusing and is the reason we put the HD prefix in place, so that users are aware that it isn't the system/library call. I would update the comments, but leave the HD prefix for this.

Thanks for the explanation, @qkoziol! I was always curious about the long history of HD prefix.

[derobins]

Closing this. We've decided to keep HD as a prefix for anything that might be a work-around.