libassuan troubles

Marcus Brinkmann marcus.brinkmann at ruhr-uni-bochum.de
Mon Apr 19 17:15:08 CEST 2004


At Mon, 19 Apr 2004 16:54:37 +0200,
Michael Nottebrock wrote:
> 
> [1  <text/plain; iso-8859-1 (quoted-printable)>]
> On Monday 19 April 2004 16:34, Marcus Brinkmann wrote:
> 
> > This seems spurious.  Maybe putc_unlocked is only defined as a macro
> > on BSD, and thus circumvents the autoconf tests?  This would sound
> > broken to me (it may be allowed to define it as a macro, but it should
> > still be defined as a function in the library).
> 
> Yes, it's a macro. However, I don't see what's wrong about that other than 
> making autoconf's life harder.

putc_unlocked is specified as a function that may be defined as a
macro.  The fact that it is defined as a macro does not relief you
from also declaring and defining it as a function.  IE, the following
must be possible in a program:

#undef putc_unlocked
  putc_unlocked ('a');

At least this is my interpretation of the wording in POSIX.  In fact,
if you not only take into account the specification, but also the
application usage, it becomes apparent:


16064 APPLICATION USAGE
16065              Since they may be implemented as macros, getc_unlocked( ) and putc_unlocked( ) may treat
16066              incorrectly a stream argument with side effects. In particular, getc_unlocked(*f++) and
16067              putc_unlocked(*f++) do not necessarily work as expected. Therefore, use of these functions in
16068              such situations should be preceded by the following statement as appropriate:
16069              #undef getc_unlocked
16070              #undef putc_unlocked

The autoconf test relies on the function in the library object file.
This will work for almost all functions, except those for which POSIX
explicitely allows the lack of a function definition (like setjmp,
FD_CLR, etc).

Thanks,
Marcus



More information about the Gpa-dev mailing list