cvs commit: src/include stdio.h src/lib/libc/stdio clrerr.c feof.c ferror.c fileno.c getc.c getchar.c local.h putc.c putchar.c xprintf.c

[Kris Kennaway]

Coleman Kane wrote:
> On Thu, 2008-05-08 at 01:19 +0200, Kris Kennaway wrote:
>> Alfred Perlstein wrote:
>>> * John Baldwin <jhb at freebsd.org> [080507 10:28] wrote:
>>>> On Wednesday 07 May 2008 02:40:13 am Alfred Perlstein wrote:
>>>>> * John Baldwin <jhb at freebsd.org> [080505 13:47] wrote:
>>>>>> On Monday 05 May 2008 03:24:17 pm Peter Jeremy wrote:
>>>>>>> On Mon, May 05, 2008 at 02:59:28PM -0400, John Baldwin wrote:
>>>>>>>> On Monday 05 May 2008 02:40:03 pm Alfred Perlstein wrote:
>>>>>>>>> I'm _not_ objecting, just interested in why.
>>>>>>>>>
>>>>>>>>> Any references to discussions on this?  Are we now safe for
>>>>>>>>> future compat or something?
>>>>>>>> Having FILE be opaque broke just about every 'configure' script on the 
>>>>>>>> planet. :(
>>>>>>> Either autoconf and friends are _intended_ as impediments to
>>>>>>> portability or they are completely broken by design.
>>>>>> It appears that autoconf only believes a type is real if you can typedef 
>>>> it to 
>>>>>> another type, cast 0 to a valid pointer to the new typedef'd type, and do 
>>>> a 
>>>>>> sizeof() of the typdef'd type.  The last is where having an opaque type 
>>>>>> breaks down for scripts that want to make sure FILE is a real type.
>>>>> Oh c'mon!  we're going to revert this needed fix just because of
>>>>> autoconf?
>>>> Pretty much.  It appears that FILE has been public for so long that there is a 
>>>> lot of code that assumes it can use it.
>>> I don't think that's really fair, stdio has had adequate accessors
>>> for a long time, if AN(*) application does the wrong thing for long enough
>>> it does not make it right.
>>>
>>> (*) Important note: when considering autoconf scripts, most of the
>>> scripts test's come from a repository of scripts or are carbon
>>> copied from each other.  Saying that "all ports are broken" is not
>>> true, it is a single suite of configuration scripts that are broken
>>> and need fixing, then we will be OK.
>>>
>>> We have precident here of hacked autoconf and ports build logic
>>> that automatically "seds" various things in scripts.  I think
>>> a few knobs can fix this for us.
>> The offer was a serious one.  If you're interested in evaluating the 
>> impact of this change on ports then just say the word.
>>
>> Kris
>>
> 
> What if we fix this breakage through a patch in our autoconf/automake
> and then put a toggle in the ports system that could be told to re-run
> autogen on the offending ports before the configure script is run
> (hopefully replacing the broken "configure" with one that works)?

If it was just the broken autofools then this might work, except

1) It's not just autofools that are broken (the fact that several parts 
of the base tree were already broken gives some estimation of the rate 
of other code breakage that should be expected)

2) There are lots of ports that tweak the autoconf output, either 
upstream in the vendor or in the port.  Fixing them to work properly 
again will be an exercise in patience, subtlety and irritation.

Anyway -- again -- we won't know the precise impact until we run a full 
build with a group of volunteers to study the results.

Kris