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]

SDZ <sa******@hotmail.com> scribbled the following:

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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It was, er, quite bookish."
- Horace Boothroyd

[Paulo PEREIRA]

On 2004-06-14, Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

SDZ <sa******@hotmail.com> scribbled the following:

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.

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

--
"Computers are useless. They can only give you answers"
- Pablo Picasso

[paulo-pereira dot perso at wanadoo dot fr]

[Default User]

SDZ wrote:

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

[Nils O. Selåsdal]

On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:

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]

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:

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

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 (pa*****@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]

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:

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

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t 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?

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]

Joona I Palaste wrote:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:

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

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?

<OT> I think

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

is acceptable. </OT>

--
Er*********@sun.com

[Goran Larsson]

In article <ca**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);

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]

Joona I Palaste <pa*****@cc.helsinki.fi> writes:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t 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?

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]

In article <ca**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

On Mon, 14 Jun 2004 04:47:13 -0700, SDZ wrote:

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

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?

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, ba****@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

[Joona I Palaste]

Goran Larsson <ho*@invalid.invalid> scribbled the following
on comp.lang.c:

In article <ca**********@oravannahka.helsinki.fi>,
Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Nils O. Selåsdal <NO*@utel.no> scribbled the following:

> int open(const char *pathname, int flags);
> int open(const char *pathname, int flags, mode_t mode);

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.

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 (pa*****@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]

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: [phone]
URL: http://www.rite-online.net

[Joona I Palaste]

Rich Teer <ri*******@rite-group.com> scribbled the following
on comp.lang.c:

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.

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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Nothing lasts forever - so why not destroy it now?"
- Quake

[Goran Larsson]

In article <Pi*******************************@zaphod.rite-online.net>,
Rich Teer <ri*******@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]

Joona I Palaste wrote:

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

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]

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: [phone]
URL: http://www.rite-online.net

[Old Wolf]

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Rich Teer <ri*******@rite-group.com> scribbled the following
on comp.lang.c:

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.

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 <ol*****@inspire.net.nz> scribbled the following
on comp.lang.c:

Joona I Palaste <pa*****@cc.helsinki.fi> wrote:

Rich Teer <ri*******@rite-group.com> scribbled the following
on comp.lang.c:

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

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.

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 (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"B-but Angus! You're a dragon!"
- Mickey Mouse