www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1994/11/22/12:29:59

Subject: Re: ansi/posix compatibility ideas and issues
To: ucf-cs!stealth.ctron.com!dj AT alfred DOT oau DOT org (DJ Delorie)
Date: Tue, 22 Nov 1994 08:01:26 -0500 (EST)
From: "Bill Perkins" <billp AT datamax DOT oau DOT org>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

DJ writes:
> This part works OK.
> 
> One question is, should I use the same technique for functions that
> are ansi but not posix, so that an ansi program can (for example)
> provide a non-standard write() function and still expect printf() to
> work as ansi documents?
Sounds like the program would not be ANSI at that point...
[stuff deleted] 
> by various conditionals (like _POSIX_SOURCE).  Since the __ff-style
> symbols don't violate POSIX but aren't part of POSIX, should they go
> in the posix section or the non-posix section?  Basically, if you
> declare yourself to be a _POSIX_SOURCE program, should the headers
> provide prototypes for the __ff functions?
Once again, it wouldn't be pure POSIX... 
> The same goes for ansi.  If you say you're a pure ansi program, should
> you get prototypes for non-ansi functions that fall within the ansi
> reserved name space?
I would go with the portability: _POSIX_SOURCE defined should mean portable
to another POSIX compiler, ANSI should mean that it can be portable to another
ANSI compiler...
		Regards,
		Bill 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019