Message-ID: <004701c8323d$c0da8780$6501a8c0@paul>
From: "Paul Edwards" <mutazilah AT gmail DOT com>
To: <cygwin AT cygwin DOT com>
Subject: Re: cygwin 1.5.24-2 gcc 3.4.4 stdio.h
Date: Thu, 29 Nov 2007 15:10:16 +1100
MIME-Version: 1.0
Content-Type: text/plain; 	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

Eric Blake wrote...

> 1) the newlib headers pollute the namespace in strict ANSI mode (or in
> other words, gcc -ansi _still has bugs_ in newlib) because no one has
> submitted patches to the newlib project to clean them up.  Patches are
> welcome, but should be directed to the newlib list rather than the cygwin
> list.

Ok.

> 2) why are you trying to use -ansi in the first place?  A strict ANSI C99

First of all, I'm after strict ANSI C89, not C99.  And quite frankly, I'll
be pretty happy when C89 is universally available.

> compilation environment is very restrictive in what you can code:
> theoritically, it implies portability to other strict ANSI C99 systems,
> but in reality, how many strict C99 compliant environments are there,

Most platforms have extensions of C89.  But C89 is the common
denominator.

> really?  I think you are better off with POSIX for portability than strict
> C99, 

No, C89 is far more portable than Posix.  Posix is not part of normal
MVS, and while the USS environment exists as an option in some
systems, it is just an overhead.  Any system that supports Posix should
support C89 programs.  The reverse is not true.  It is C89 that is
portable, not Posix.

> because there are more systems trying for POSIX compliance rather
> than just C99, and because POSIX adds so many more portable interfaces
> above and beyond C99 (at the expense of some namespace clashes, as your
> example proves).  But even then, be aware that there are very few strictly
> compliant POSIX systems (cygwin certainly fails to be one of them).

There's basically no system that only runs strictly conforming programs.
All systems will allow someone to code something that assumes the
size or endianness of integers, for example.  It is the C programmers
job to not make such assumptions.  And it is the C compiler's job to
provide one of many possible C89-compliant environments.

> 3) just because strict C99 requires that you be allowed to compile code
> that #defines pid_t prior to inclusion of <stdio.h>, what does it buy you?

It allows me to write my own Posix-replacement functions that work
on MVS etc.  Or at least a subset of them.  Which was working fine,
on multiple environments, until I ran across this C compiler that
doesn't even manage to conform to a spec that has been available for
around 20 years.

> It is more pragmatic to write code that is portable to a wide variety of
> not-quite-standard compliant systems (of which, newlib is one - it is not
> quite C99 compliant), than to expect every system to obey every standard.

They only need to obey one standard - C89.  If it doesn't do that, then you
don't have a C compiler.  Which list do I need to go to to consult someone
about modifying newlib?  I can probably make the changes to get it at least
closer to C89 compliance if I have someone to give patches to.

> Which means you are better off not #defining pid_t before including
> <stdio.h>.

No, that stops my application from working.  I want a C89 compiler, and
Cygwin doesn't appear to provide one.  Even TC++ 1.01 for DOS managed
to provide that, and I was using that in a different project just a few months
ago.  Speaking of which, DOS is another environment that isn't Posix and
if you code for Posix, your code is in no way portable.

> How awkward - here you are complaining about spam, then you post
> plain-text email in your reply.  

Damn.  I didn't realise that.  I took care to remove Robert's email address
from the reply, not realising that my original was still there.

BFN.  Paul.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/