Difference between various functions

[SDZ]

Could somebody explain in simple forms, what is/are the difference(s) between

- scanf and sscanf and ssscanf
- printf and sprintf
- open and fopen

Thanks in advance,
SDZ

 

[Joona I Palaste]

Could somebody explain in simple forms, what is/are the difference(s) between

- scanf and sscanf and ssscanf

scanf reads from stdin, sscanf from a string. ssscanf doesn't exist.

- printf and sprintf

printf prints into stdout, sprintf into a string.

- open and fopen

open doesn't exist. fopen opens a file.

 

[Paulo PEREIRA]

scanf reads from stdin, sscanf from a string. ssscanf doesn't exist.


printf prints into stdout, sprintf into a string.


open doesn't exist. fopen opens a file.

open is an UNIX system call for opening files. Not related to ISO C.

 

[Default User]

Could somebody explain in simple forms, what is/are the difference(s) between

- scanf and sscanf and ssscanf
- printf and sprintf
- open and fopen

What does your C textbook say? Learning C from random questions on
usenet is a bad idea and no substitute for proper study. You are wasting
your time and ours.




Brian Rodenborn

 

[=?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=]

Could somebody explain in simple forms, what is/are the difference(s) between

- scanf and sscanf and ssscanf
- printf and sprintf
- open and fopen

Thanks in advance,
SDZ

int scanf(const char *format, ...);
int sscanf(const char *str, const char *format, ...);
(never heard of ssscanf)
int printf(const char *format, ...);
int sprintf(char *str, const char *format, ...);

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);

You can easily see some docs for these in section 2 and 3
at e.g. http://netbsd.gw.com/cgi-bin/man-cgi

 

[Joona I Palaste]

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?

 

[Goran Larsson]

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.

 

[Dragan Cvetkovic]

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 !!!

 

[Ben Pfaff]

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, ...);

 

[Eric Sosman]

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?

<OT> I think

int open(const char *path, int flags, ...);

is acceptable. </OT>

 

[Barry Margolin]

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.

 

[Joona I Palaste]

Goran Larsson <[email protected]> scribbled the following

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).

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 ([email protected]) ------------- 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]

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]

Rich Teer <[email protected]> scribbled the following

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.

 

[Goran Larsson]

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. :-/

 

[David Schwartz]

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]

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

 

[Old Wolf]

Rich Teer <[email protected]> scribbled the following



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]

Old Wolf <[email protected]> scribbled the following

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.