Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!longway!std-unix From: karish@forel.stanford.edu (Chuck Karish) Newsgroups: comp.std.unix Subject: Re: Query about Message-ID: <447@longway.TIC.COM> Date: 27 Nov 89 18:35:08 GMT References: <437@longway.TIC.COM> <438@longway.TIC.COM> <441@longway.TIC.COM> <442@longway.TIC.COM> Sender: std-unix@longway.TIC.COM Reply-To: karish@forel.stanford.edu (Chuck Karish) Organization: Mindcraft, Inc. Lines: 40 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: karish@forel.stanford.edu (Chuck Karish) In article <442@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote: >In article <441@longway.TIC.COM> Andy Tanenbaum writes: >-> char d_name[1]; >-What happens when a program allocates a struct dirent in a program? The >-compiler will not allocate enough storage and it will crash when used. > >That's what happens when programmers assume things that are not promised >by the standards. This is spelled out in the rationale (B.5.1.1). >-Is it legal to add a line >-#include >-in ? > >NO. A citation would be more useful here than this proclamation. I haven't been able to find anything in the 1003.1 documents that would prohibit this. The form of a header is defined by the implementation. There are many places in the Standard where it is required that a particular identifier be available when a particular header is #included, but I haven't found any that require that identifiers not be visible when the headers to which they are assigned have not been #included. Portable application code must #include headers as listed in the function descriptions in the standard, if only for compatibility with implementations that don't support ANSI C. It will be easier to identify non-portable code under implementations that refrain from #including, for example, in . Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu Volume-Number: Volume 17, Number 75