Re: standards/47119: putc_unlocked(3) is found even with -std=c89

[Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>]

The following reply was made to PR standards/47119; it has been noted by GNATS.

From: Steffen "Daode" Nurpmeso <sdaoden%gmail.com@localhost>
To: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%NetBSD.org@localhost
Subject: Re: standards/47119: putc_unlocked(3) is found even with -std=c89
Date: Wed, 24 Oct 2012 16:05:07 +0200

 Martin Husemann <martin%duskware.de@localhost> wrote:
 
  |On Wed, Oct 24, 2012 at 03:11:03PM +0200, Steffen Daode Nurpmeso wrote:
  |> Because it is not part of C89/C99?
  |
  |You are misunderstanding the compiler option - it has no influence on the
  |symbols visible in libraries nor system headers (at least in general).
  |There are a few defines you can add via -D to make the headers pollute less
 
 Hmm.  I think you're right.
 Well i'm not really working with those headers, and i still see
 a '#define _GNU_SOURCE' on top of the one that's really important
 for me.
 
  |namespace, but since this is a posix blessed function, it is better
  |to avoid a name clash in application code.
  |Martin
 
 Yes, a lot of conditions and a lot of what standards produce most
 of the time, so thanks for all those work on standard compliance.
 
 Nonetheless - the bug is triggered only with -std=c89, and only on
 NetBSD 6.0.  And in the meanwhile i've found it.
 In fact it has nothing to do with putc_unlocked() (i was so clumsy
 that i even tried to compile with -pthread and -D_REENTRANT, and
 it was still expanded to __sputc() or so - amazing!), but it is in
 fact alloca(3) that returns an invalid buffer:
 
   %fwrite_td() calls ac_alloc for 29
   fwrite_td() calls memcpy (From: <XXXXXXXXXXX%YYYY.com@localhost>
   )29
   fwrite_td() before delctrl (^])29
   fwrite_td() calls prefixwrite (^])29
   *29 (0xbfbf9254)()*^@^@^@^@^@^@^@^@XXXXXXXXXX%YYYY.com@localhost>
 
 From the alloca(3) manual i see nothing special to adhere to,
 i would not describe 29 bytes as a "large unbounded allocation".
 The CFLAGS are simply '-std=c89 -O2', so nothing special at all.
 I think this is worth another PR?
 
 --steffen