|
Home > Archive > Unix Programming > June 2004 > Re: Difference between various functions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: Difference between various functions
|
|
| Joona I Palaste 2004-06-14, 5:56 pm |
| Nils O. Selåsdal <NOS@utel.no> scribbled the following:
> On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:
[vbcol=seagreen]
> int open(const char *pathname, int flags);
> int open(const char *pathname, int flags, mode_t mode);
> FILE *fopen(const char *path, const char *mode);
Wait, wait. Two distinct functions with the same name aren't possible in
ISO-compliant C, even if they use different parameters. Does the POSIX
standard actually require the compiler to use non-standard extensions?
--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Normal is what everyone else is, and you're not."
- Dr. Tolian Soran
| |
| Dragan Cvetkovic 2004-06-14, 5:56 pm |
| Joona I Palaste <palaste@cc.helsinki.fi> writes:
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
>
>
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
Well, the actuall prototype should be
int open(const char *, int, ...);
or, as commonly used in documentation
int open(const char *path, int oflag, /* mode_t mode */);
and that C handles quite well using <stdarg.h> type of functions.
The same way you handle fprintf(...) type of functions.
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole No it isn't. L. E. J. Brouwer
!!! Sender/From address is bogus. Use reply-to one !!!
| |
| Eric Sosman 2004-06-14, 5:56 pm |
| Joona I Palaste wrote:
> Nils O. Sel=E5sdal <NOS@utel.no> scribbled the following:
>=20
between[vbcol=seagreen]
>=20
>=20
>=20
>=20
> Wait, wait. Two distinct functions with the same name aren't possible i=
n
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
<OT> I think
int open(const char *path, int flags, ...);
is acceptable. </OT>
--=20
Eric.Sosman@sun.com
| |
| Goran Larsson 2004-06-14, 5:56 pm |
| In article <cal2es$cr9$1@oravannahka.helsinki.fi>,
Joona I Palaste <palaste@cc.helsinki.fi> wrote:
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
[vbcol=seagreen]
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters.
It is possible if it can be implemented as a function with a variable
argument list, like this:
| #if defined(__STDC__)
|
| extern int fcntl(int, int, ...);
| extern int open(const char *, int, ...);
The open() function only needs to look at the third argument (mode) if
a certain bit (O_CREAT) is set in the second argument (flags).
> Does the POSIX
> standard actually require the compiler to use non-standard extensions?
No non-standard extensions are required.
--
Göran Larsson http://www.mitt-eget.com/
| |
| Ben Pfaff 2004-06-14, 5:56 pm |
| Joona I Palaste <palaste@cc.helsinki.fi> writes:
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
>
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
No. Typically open() is actually prototyped as
int open(const char *, int, ...);
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton
| |
| Barry Margolin 2004-06-14, 5:56 pm |
| In article <cal2es$cr9$1@oravannahka.helsinki.fi>,
Joona I Palaste <palaste@cc.helsinki.fi> wrote:
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
>
>
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
No, they require support for varargs functions, which is standard. The
actual prototype is:
int open(const char *pathname, int flags, ...);
But the only valid ways to call it correspond to the two prototypes that
Nils showed.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Stephen L. 2004-06-14, 5:56 pm |
| Joona I Palaste wrote:
>
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
>
>
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
>
In Unix, `open()' looks like (in <fcntl.h> ) ->
extern int open(const char *, int, ...);
^^^
The third arg is used when `open()' is asked to
create the file (with `O_CREAT') - they represent
the access mode of the file (after its creation).
The third arg is only used when `O_CREAT' is
specified - it's ignored and not provided otherwise.
Obviously, the `open()' call was in Unix at
the epoch, in the days of K&R prototype-less C;
it appears this way for historical reasons.
In Unix, the 1st prototype would be incorrect
(and you shouldn't see it in _any_ Unix header file).
The `open()' prototype(s) you've shown is NOT
an example of function overloading in the C Language.
C does not DO function overloading.
-
Stephen
| |
| Joona I Palaste 2004-06-14, 5:56 pm |
| Goran Larsson <hoh@invalid.invalid> scribbled the following
on comp.lang.c:
> In article <cal2es$cr9$1@oravannahka.helsinki.fi>,
> Joona I Palaste <palaste@cc.helsinki.fi> wrote:
[vbcol=seagreen]
[vbcol=seagreen]
> It is possible if it can be implemented as a function with a variable
> argument list, like this:
> | #if defined(__STDC__)
> |
> | extern int fcntl(int, int, ...);
> | extern int open(const char *, int, ...);
> The open() function only needs to look at the third argument (mode) if
> a certain bit (O_CREAT) is set in the second argument (flags).
[vbcol=seagreen]
> No non-standard extensions are required.
D'oh. I should have paid more attention to the parameter lists. Even
ISO standard C functions (printf, fprint, ...) work that way. Thanks to
all who replied.
One further question: Since AFAIK ISO standard C provides no way to
explicitly check the length of the varargs list, how does open() know
whether the "mode" argument was supplied or not? Or does it even need
to?
--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp
| |
| Rich Teer 2004-06-15, 5:56 pm |
| On Mon, 14 Jun 2004, Joona I Palaste wrote:
> One further question: Since AFAIK ISO standard C provides no way to
> explicitly check the length of the varargs list, how does open() know
> whether the "mode" argument was supplied or not? Or does it even need
> to?
It doesn't need to know. The writers of the function quite
reasonably assume that if O_CREAT was specified, then the 3rd
argument was also passed. If it wasn't passed, whatever junk
is on the stack at that location will be used instead.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
| Joona I Palaste 2004-06-15, 5:56 pm |
| Rich Teer <rich.teer@rite-group.com> scribbled the following
on comp.lang.c:
> On Mon, 14 Jun 2004, Joona I Palaste wrote:
[vbcol=seagreen]
> It doesn't need to know. The writers of the function quite
> reasonably assume that if O_CREAT was specified, then the 3rd
> argument was also passed. If it wasn't passed, whatever junk
> is on the stack at that location will be used instead.
All righty, thanks. I note that this behaviour is dependent on the
POSIX standard and the ISO C standard alone does not suffice to
guarantee it.
--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Nothing lasts forever - so why not destroy it now?"
- Quake
| |
| Goran Larsson 2004-06-15, 5:56 pm |
| In article <Pine.SOL.4.58.0406141512250.12483@zaphod.rite-online.net>,
Rich Teer <rich.teer@rite-group.com> wrote:
> If it wasn't passed, whatever junk
> is on the stack at that location will be used instead.
| If it wasn't passed, whatever junk
| is in the implementation specific location[*] used to pass arguments
| will be used instead.
|
| [*] location includes memory, registers, disks, punched cards,
| mercury delay lines, ...
Writing about "the stack" in comp.lang.c is not recommended. :-/
--
Göran Larsson http://www.mitt-eget.com/
| |
| David Schwartz 2004-06-15, 5:56 pm |
| Joona I Palaste wrote:
[vbcol=seagreen]
> D'oh. I should have paid more attention to the parameter lists. Even
> ISO standard C functions (printf, fprint, ...) work that way. Thanks
> to all who replied.
> One further question: Since AFAIK ISO standard C provides no way to
> explicitly check the length of the varargs list, how does open() know
> whether the "mode" argument was supplied or not? Or does it even need
> to?
Look up.
DS
| |
| Rich Teer 2004-06-15, 5:56 pm |
| On Mon, 14 Jun 2004, Joona I Palaste wrote:
> All righty, thanks. I note that this behaviour is dependent on the
> POSIX standard and the ISO C standard alone does not suffice to
> guarantee it.
Right; that's because ISO C has no concept of file modes (they're
a UNIX/POSIX type of thing in this case), and nor can it. Being
platform agnostic, the type of the 3rd argument for a POSIX platform
might be wildly different to that on another.
--
Rich Teer, SCNA, SCSA
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
| |
|
| Joona I Palaste wrote:
> Nils O. Selåsdal <NOS@utel.no> scribbled the following:
>
>
>
>
>
> Wait, wait. Two distinct functions with the same name aren't possible in
> ISO-compliant C, even if they use different parameters. Does the POSIX
> standard actually require the compiler to use non-standard extensions?
>
First, before I comment on the correctness of what is listed above,
fopen returns a pointer to a stream, while open() returns a integer file
descriptor. Second, fopen() is called a high level I/O stream function,
while open() is called a low level I/O function. Have I confused you yet?
Now, open() is a variadic function as explained in this link:
http://www.gnu.org/software/libc/ma...ic%20Prototypes
Thus, it can take a variable number of arguments. Please include the
header stdarg.h to extract them should you write your own.
Now, here's the definition I found on open() from the glibc library:
http://www.gnu.org/software/libc/ma...Closing%20Files
I hope the above links answer your remaining questions.
My answers assume you are using GNU GCC with the glibc library.
Brian
P.S. I did not cross post to comp.lang.c .
Note: While the above shows the variable option in [], it is listed in
fcntl.h as a variadic function.
| |
| Old Wolf 2004-06-15, 5:57 pm |
| Joona I Palaste <palaste@cc.helsinki.fi> wrote:
> Rich Teer <rich.teer@rite-group.com> scribbled the following
> on comp.lang.c:
>
>
> All righty, thanks. I note that this behaviour is dependent on the
> POSIX standard and the ISO C standard alone does not suffice to
> guarantee it.
Yes it does. This is analogous to printf() , the difference being
that a flag bit is used instead of a character sequence starting with %
Presumably the implementation of open() (if written in ISO C and not
assembly, of course), won't attempt to extract a parameter if that
flag was not specified.
| |
| Joona I Palaste 2004-06-16, 5:57 pm |
| Old Wolf <oldwolf@inspire.net.nz> scribbled the following
on comp.lang.c:
> Joona I Palaste <palaste@cc.helsinki.fi> wrote:
[vbcol=seagreen]
> Yes it does. This is analogous to printf() , the difference being
> that a flag bit is used instead of a character sequence starting with %
> Presumably the implementation of open() (if written in ISO C and not
> assembly, of course), won't attempt to extract a parameter if that
> flag was not specified.
What I meant was that the ISO C standard does not specify that open()
will only look at the third parameter if the second one's value was
O_CREAT. In fact the ISO C standard does not specify anything that
open() will do. But the POSIX standard specifies that it will act as
described here.
--
/-- Joona Palaste (palaste@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"B-but Angus! You're a dragon!"
- Mickey Mouse
|
|
|
|
|