473,376 Members | 1,003 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,376 software developers and data experts.

which functions set the end-of-file indicator?

Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
Committee Draft — Septermber 7, 2007 WG14/N1256)

/* ============================= */
#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
/* ============================= */
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?
Aug 4 '08 #1
80 6378
On Aug 4, 9:05 pm, nicolas.sit...@gmail.com wrote:
<snip>
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?
All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)
Aug 4 '08 #2

<ni************@gmail.comwrote in message news:
>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached.
The book is wrong, at least to all intents and purposes. EOF will be
returned after the contents of the file have been exhausted by any of the
read functions. feof() returns true after the first read to return EOF.

I think what he is thinking is that if a call to a function like fscanf()
doesn't match the input format than you'll get a partial read - the function
will return the number of arguments successfully converted - and EOF may not
be set, even if you are very close to the end of the file and have no
complete records left.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Aug 4 '08 #3
ni************@gmail.com wrote:
Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached, but in C99 standard, I find p 288 (ISO/IEC 9899:TC3
Committee Draft — Septermber 7, 2007 WG14/N1256)

/* ============================= */
#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
/* ============================= */
It seems to say that fscanf family function set end-of-file indicator
too? which functions set the end-of-file indicator?
Any function that tries to read from a stream can set the
end-of-file indicator for that stream. The fopen(), freopen(),
clearerr(), ungetc(), fseek(), rewind(), and fsetpos() functions
can clear it (I think that's all, but it's possible I've overlooked
a few). No other functions modify the end-of-file indicator --
except that, as always, there's no telling what might happen if
the program invokes undefined behavior.

--
Er*********@sun.com
Aug 4 '08 #4
In article <27**********************************@k13g2000hse. googlegroups.com>
<ni************@gmail.comwrote:
>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached ...
This is incorrect. In the "obviously wrong" part, putc() is not
going to set the end-of-file indicator, for instance. :-) But it
is still wrong, and perhaps overly complicated.

All I/O is done "as if" via fgetc() and fputc(). If fgetc() would
have set the end-of-file indicator, any other input-oriented
operation that would have called fgetc() must also set the e-o-f
indicator. (And of course, if fgetc() would have set the error
indicator, any other input-oriented operation that would have called
fgetc() must also set the error indicator. The "would have"s here
simply mean that, deep inside the implementation, scanf() or fread()
or whatever might use something "faster" or "better" than an actual
call to fgetc(), such as an inline expansion of what fgetc() does.
But if they do avoid fgetc() in favor of something "better", they
still have to act *as if* they had made an actual call to fgetc(),
including setting the e-of-f and/or error indicators in the same
way that fgetc() would have.)

(For instance, an implementation might have a macro like this:

#define fast_inlined_getc(f) \
((f)->_readcount 0 ? --(f)->_readcount, *(f)->_readptr++ : \
fgetc(f))

and it could then use this in the scanf engine. The fgets() and
fread() functions might look directly at f->_readcount:

int fgets(char *buf, size_t bufsize, FILE *stream) {
...
p = memchr(f->_readptr, '\n', min(f->_readsize, room_in_user_buffer));
if (p != NULL) {
/*
* Found entire input line in current buffer. Do a quick
* copy-and-take.
*/
line_len = p - f->_readptr; /* length of the line */
memcpy(buf, f->_readptr, line_len); /* copy it */
f->_readptr += line_len; /* and take it out */
f->_readsize -= line_len; /* of the stdio buffer */
} else {
/*
* Found only part of line in current buffer, or buffer
* is empty. Do whatever is required to copy partial
* line (if any) and read more input, in a loop as needed.
*/
...
}
...
}

At some point, though, these all call fgetc() (or the underlying
code that implements fgetc()) to refill the stdio buffer. It is
this code that handles "read from underlying file or device"
requests, and it is this "read from underlying file or device"
request that encounters the kinds of failures that set the end-of-file
and/or error indicators.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
Aug 4 '08 #5
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
Aug 4 '08 #6
ni************@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
Here you go:

<http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29237>

Aug 4 '08 #7
ni************@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

All *input* functions are able to set the end-of-file indicator.
Some specified functions (the list I posted earlier, plus ungetwc() --
I warned you I might have missed a few) -- can clear the indicator.
Other functions leave it alone, barring undefined behavior.

The normative reference is section 7.19 of the Standard.

--
Er*********@sun.com
Aug 4 '08 #8
Eric Sosman wrote:
ni************@gmail.com wrote:
>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.
To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

A bit of an overstatement, but this happens in ordinary speech. We can't
all expect be like Keith!

<snip>

Aug 4 '08 #9
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!


* * *The normative reference is section 7.19 of the Standard.

--
Eric.Sos...@sun.com
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
Aug 4 '08 #10
ni************@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
>nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!


The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than once?

Aug 4 '08 #11
On 4 août, 21:59, santosh <santosh....@gmail.comwrote:
nicolas.sit...@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!
The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than once?
read what I said : all IO INPUT functions
Aug 4 '08 #12
ni************@gmail.com wrote:
On 4 août, 21:59, santosh <santosh....@gmail.comwrote:
>nicolas.sit...@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions
can potentially set/clear the end-of-file indicator, but nobody
give me normative reference, and the author says that nothing in
the C99 says that all I/O functions can set/clear end-of-file
indicator!!!
>The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!

Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than
once?

read what I said : all IO INPUT functions
You have already been told that all input in C is done as if it is
composed of one or more calls to fgetc, and fgetc can most certainly
set the end-of-file indicator, and it's implied that other input
functions modelled on top of it, must also do so. Indeed they have no
choice but to do so. However they do have different methods of
notifying the user of such an exception. For example fgets returns a
null pointer, fread returns a short item count, scanf returns EOF etc.
In all cases you can always determine whether a particular FILE stream
is at end-of-file by calling the feof function, and whether an I/O
error has occurred during the last access by using the ferror function.

Aug 4 '08 #13
santosh wrote:
Eric Sosman wrote:
>ni************@gmail.com wrote:
>>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)
The O.P. asked about the end-of-file indicator. The end-of-file
indicator and the error indicator are separate indicators, and are
set and cleared under different circumstances.

--
Er*********@sun.com
Aug 4 '08 #14
nicolas.sit...@gmail.com wrote:
On 4 ao�t, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
...
� � �The normative reference is section 7.19 ofthe Standard.

--
Eric.Sos...@sun.com
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
It doesn't explain it in those terms. You have to follow several
intermediate steps.

7.19.7.1p3 says that fgetc() sets the end-of-file indicator.
7.24.3.1p3 says the same for fgetwc(). All wide character input
functions have their behavior defined in terms of successive calls to
fgetwc(), and all byte input functions have their behavior defined in
terms of repeated calls to fgetc() (7.19.3p11). All of the input
functions are defined as either wide character input functions or byte
input functions (7.19.1p3) . Those functions don't have to actually
call fgetc()/fgetwc(), but must produce the same behavior as if they
called fgetc()/fgetwc(), which means that they must set the end-of-
file indicator, when appropriate.
Aug 4 '08 #15
On 4 août, 22:14, santosh <santosh....@gmail.comwrote:
nicolas.sit...@gmail.com wrote:
On 4 août, 21:59, santosh <santosh....@gmail.comwrote:
nicolas.sit...@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions
can potentially set/clear the end-of-file indicator, but nobody
give me normative reference, and the author says that nothing in
the C99 says that all I/O functions can set/clear end-of-file
indicator!!!
The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO INPUT functions set/clear the end-of-file indicator!
Hasn't it been made clear to you by now that only one poster has said
that all functions that perform an I/O operation set these flags, and
that he was overstating his case, as has been explained more than
once?
read what I said : all IO INPUT functions

You have already been told that all input in C is done as if it is
composed of one or more calls to fgetc, and fgetc can most certainly
set the end-of-file indicator, and it's implied that other input
functions modelled on top of it, must also do so. Indeed they have no
choice but to do so. However they do have different methods of
notifying the user of such an exception. For example fgets returns a
null pointer, fread returns a short item count, scanf returns EOF etc.
In all cases you can always determine whether a particular FILE stream
is at end-of-file by calling the feof function, and whether an I/O
error has occurred during the last access by using the ferror function.
sorry but, one more time, you don't answer me : can you say precisely,
where in the normative reference it is write that all IO INPUT
functions clear/set the end-of-file indicator cause if I write to the
author without any proof...
Aug 4 '08 #16
Eric Sosman wrote:
santosh wrote:
>Eric Sosman wrote:
>>ni************@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99
says that all I/O functions can set/clear end-of-file indicator!!!
Unless the post hasn't reached my news server yet, nobody has
claimed that all I/O functions can set or clear the end-of-file
indicator. putc(), for example, cannot. Nor can ftell(), nor
setvbuf(), nor feof(), nor a bunch of others.

To quote vippstar:

All functions that perform IO operations. (ie even perror() can set
the 'error' indicator for stderr if an error occurs at writing)

The O.P. asked about the end-of-file indicator. The end-of-file
indicator and the error indicator are separate indicators, and are
set and cleared under different circumstances.
You're right. Apologies to vippstar for misquoting him.

Aug 4 '08 #17
ni************@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
>nicolas.sit...@gmail.com wrote:
>>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
It's in the same paragraph that says the Moon is made of
green cheese. In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.

Is it possible that you have confused the end-of-file
indicator with the error indicator? They are not the same.

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

Aug 4 '08 #18
On 4 août, 22:28, Eric Sosman <Eric.Sos...@sun.comwrote:
* * *Is it possible that you have confused the end-of-file
indicator with the error indicator? *They are not the same.

--
Eric.Sos...@sun.com
In fact, the author says that except the functions I mentioned above,
all other are not guaranteed to set the end-of-file OR error
indicator, and he says that other functions are not portable if used
in this way. For french programmers who want to verify my saying, the
book is "méthodologie de la programmation en C, norme C99, API POSIX"
de Achille Braquelaire.
Aug 4 '08 #19
Eric Sosman wrote:
ni************@gmail.com wrote:
>On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
>>nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!

The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!

It's in the same paragraph that says the Moon is made of
green cheese. In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.

Is it possible that you have confused the end-of-file
indicator with the error indicator? They are not the same.
Pardon me; I overlooked the insertion of the word "input" in
your restatement of the question. Yes, the Standard says that all
input functions can set the end-of-file indicator, but it says so
in the descriptions of the individual functions, not as a blanket
statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf, I believe
that the description of each says it can set the end-of-file
indicator. (I haven't checked, but you're welcome to -- and
maybe to file a Defect Report if any of them forgets to!) You can
also search the function descriptions for those that clear or can
clear the end-of-file indicator; it would be somewhat clumsier to
make a blanket statement about the latter category.

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

Aug 4 '08 #20
Eric Sosman wrote:
....
statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) ...
Which starts out saying "The input/output functions are given the
following collective terms"
... plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf,
All of which fall into the category defined by 7.19.1p5 as "byte input/
output functions".

The standard may fail to distinguish between byte input and byte
output functions, but is anyone seriously in doubt as to which of the
byte input/output functions are input functions, and which ones are
output functions?
... I believe
that the description of each says it can set the end-of-file
indicator. (I haven't checked, but you're welcome to -- and
I have. The ones that process more than one character at a time don't
say so directly. You have to invoke 7.19.3p11 to determine that they
are also required to set it.
Aug 4 '08 #21
ja*********@verizon.net wrote:
Eric Sosman wrote:
...
>statement about all input functions. (Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) ...

Which starts out saying "The input/output functions are given the
following collective terms"
>... plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf,

All of which fall into the category defined by 7.19.1p5 as "byte input/
output functions".

The standard may fail to distinguish between byte input and byte
output functions, but is anyone seriously in doubt as to which of the
byte input/output functions are input functions, and which ones are
output functions?
I'd say that's the commonsense view. In fact, I *did* say
that's the commonsense view. Not sure what the argument's about ...

--
Er*********@sun.com
Aug 4 '08 #22
On 4 août, 22:48, Eric Sosman <Eric.Sos...@sun.comwrote:
Eric Sosman wrote:
nicolas.sit...@gmail.com wrote:
On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
>* * *The normative reference is section 7.19 of the Standard.
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
* * It's in the same paragraph that says the Moon is made of
green cheese. *In other words, the Standard says no such thing:
You are searching for the normative text of a falsehood.
* * Is it possible that you have confused the end-of-file
indicator with the error indicator? *They are not the same.

* * *Pardon me; I overlooked the insertion of the word "input" in
your restatement of the question. *Yes, the Standard says that all
input functions can set the end-of-file indicator, but it says so
in the descriptions of the individual functions, not as a blanket
statement about all input functions. *(Indeed, the Standard never
defines "input functions" as such, although it does define some
close relatives.)

* * *If we take the commonsense view that "input functions" are the
"wide character input functions" (7.19.1p5) plus fgetc, fgets, fread,
fscanf, getc, getchar, gets, scanf, vfscanf, and vscanf, I believe
that the description of each says it can set the end-of-file
indicator. *(I haven't checked, but you're welcome to -- and
maybe to file a Defect Report if any of them forgets to!) *You can
also search the function descriptions for those that clear or can
clear the end-of-file indicator; it would be somewhat clumsier to
make a blanket statement about the latter category.

--
Eric.Sos...@sun.com
I checked and for example, the fscanf function, nothing says that it
sets the end-of-file indicator except perhaps this example :

#include <stdio.h>
/* ... */
int count; float quant; char units[21], item[21];
do {
count = fscanf(stdin, "%f%20s of %20s", &quant, units, item);
fscanf(stdin,"%*[^\n]");
} while (!feof(stdin) && !ferror(stdin));
Aug 4 '08 #23
On Mon, 4 Aug 2008 12:50:23 -0700 (PDT), ni************@gmail.com
wrote:
>On 4 août, 21:30, Eric Sosman <Eric.Sos...@sun.comwrote:
>nicolas.sit...@gmail.com wrote:
OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!


* * *The normative reference is section 7.19 of the Standard.

--
Eric.Sos...@sun.com
I looked at this section, but I didn't find anything saying clearly
that all IO input functions set/clear the end-of-file indicator!
Since it is obviously false, you shouldn't. Read 7.19.3-11 followed
by 7.19.7.1-3 to learn when it is set. You should then be able to
find on your own when it is cleared.

--
Remove del for email
Aug 4 '08 #24
On 4 août, 22:58, jameskuy...@verizon.net wrote:
Eric Sosman wrote:
I have. The ones that process more than one character at a time don't
say so directly. You have to invoke 7.19.3p11 to determine that they
are also required to set it.
11 The wide character input functions read multibyte characters from
the stream and convert
them to wide characters as if they were read by successive calls to
the fgetwc function.
Each conversion occurs as if by a call to the mbrtowc function,
with the conversion state
described by the stream’s own mbstate_t object. The byte input
functions read
characters from the stream as if by successive calls to the fgetc
function.
Many thanks to everybody, this time it's clear for me.
Aug 4 '08 #25
On Mon, 04 Aug 2008 14:06:55 -0700, nicolas.sitbon wrote:
I checked and for example, the fscanf function, nothing says that it
sets the end-of-file indicator
Okay, maybe an example is clearer for you.

7.19.1p5 (Input/output <stdio.h>; Introduction)
"The byte input/output functions [...]: [...], fscanf, [...]"

7.19.3p11 (Files)
"The byte input functions read characters from the stream as if by
successive calls to the fgetc function."

7.19.7.1p3 (The fgetc function)
"If [...] the stream is at end-of-file, the end-of-file indicator for the
stream is set [...]"

Yes, it doesn't explicitly say that fscanf sets the end-of-file indicator.
But a conforming implementation where fscanf *doesn't* set the end-of-file
indicator cannot exist; it would have to break one of these three
requirements. Either it doesn't classify fscanf as a byte input function,
or it doesn't make byte input functions read input as if by successive
calls to fgetc, or it doesn't make fgetc set the end-of-file indicator.
Aug 4 '08 #26
Malcolm McLean wrote, On 04/08/08 19:27:
>
<ni************@gmail.comwrote in message news:
>Hi everybody, in a french C book, the author says that only {fgetc,
getc, getchar, fgetwc, getwc, getwchar, fgets, gets, fgetws, getws,
fputc, putc, putchar, fputwc, putwc, putwchar, fputs, puts, fputws}
are guaranteed to set the end-of-file indicator when the end-of-file
is reached.

The book is wrong, at least to all intents and purposes. EOF will be
returned after the contents of the file have been exhausted by any of
the read functions. feof() returns true after the first read to return EOF.
The above is at least misleading. EOF is a macro which evaluates to an
integer constant. Since some of the input functions return pointers you
are obviously wrong about all of the input functions being able to
return its value. Also for those which can return EOF they can do so
because of an error, and if it is an error causing the routine to return
EOF then feof() will not return true but ferror() will.
I think what he is thinking is that if a call to a function like
fscanf() doesn't match the input format than you'll get a partial read -
the function will return the number of arguments successfully converted
- and EOF may not be set, even if you are very close to the end of the
file and have no complete records left.
Well, that appears to not be what the OP's book was referring to, but it
is true.
--
Flash Gordon
Aug 4 '08 #27
In article <50**********************************@f63g2000hsf. googlegroups.com>,
<ni************@gmail.comwrote:
>OK OK, everybody seems to be ok to say that all I/O functions can
potentially set/clear the end-of-file indicator, but nobody give me
normative reference, and the author says that nothing in the C99 says
that all I/O functions can set/clear end-of-file indicator!!!
All I/O function don't, for instance, I seem to recal ferror() does not,
although you may argue that that call does not do any real I/O even though
it is in the I/O family. Also, some involve WEOF.

However, C99 specifically mentions which routines return EOF et al,
and that's a real lot of them.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Aug 5 '08 #28
In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:
>... set ... the end-of-file
indicator. putc(), for example, cannot.
Dunno if we're using different words or not, but
putc certainly can return EOF.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Aug 5 '08 #29
On Aug 5, 3:40 am, com...@panix.com (Greg Comeau) wrote:
In article <1217878106.929229@news1nwk>,
Eric Sosman <Eric.Sos...@sun.comwrote:
... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.
The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

Mr Sosman is talking about file streams that feof() returns non-zero
for. (ie the eof flag is set).
putc cannot set that flag.
Aug 5 '08 #30
In article <g7**********@panix3.panix.com>,
Greg Comeau <co****@comeaucomputing.comwrote:
>In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:
>>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.
Oops, we're definitely using different words,
so while what I wrote is true, you were clearly talking
about something else.
--
Greg Comeau / 4.3.10.1 with C++0xisms now in beta!
Comeau C/C++ ONLINE == http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?
Aug 5 '08 #31
co****@panix.com (Greg Comeau) writes:
In article <1217878106.929229@news1nwk>,
Eric Sosman <Er*********@sun.comwrote:
>>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.
Certainly.

Returning EOF and setting the end-of-file indicator are two different
things.

Concretely:

before = feof(stdout);
putc_result = putc('x');
after = feof(stdout);

It can be the case that putc_result == EOF, but it cannot be the case
that before==0 and after!=0.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 5 '08 #32
Greg Comeau wrote:
Eric Sosman <Er*********@sun.comwrote:
>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.
Returning EOF signals error, not setting of end-of-file indicator.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Aug 5 '08 #33
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vi******@gmail.com wrote:
>On Aug 5, 3:40 am, com...@panix.com (Greg Comeau) wrote:
>In article <1217878106.929229@news1nwk>,
Eric Sosman <Eric.Sos...@sun.comwrote:
>... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.
The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.
>
Mr Sosman is talking about file streams that feof() returns non-zero
for. (ie the eof flag is set).
putc cannot set that flag.
--
Remove del for email
Aug 5 '08 #34
Barry Schwarz wrote:
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vi******@gmail.com wrote:
>>On Aug 5, 3:40 am, com...@panix.com (Greg Comeau) wrote:
>>In article <1217878106.929229@news1nwk>,
Eric Sosman <Eric.Sos...@sun.comwrote:

... set ... the end-of-file
indicator. putc(), for example, cannot.

Dunno if we're using different words or not, but
putc certainly can return EOF.

The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following

o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.
And here is a test program as well:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
int retval = 0, rc = 0;
puts("Writing EOF to stderr with putc...");
retval = putc(EOF, stderr);
if (retval == EOF) {
printf("\nputc returned EOF. Value is: %d\n", retval);
if (ferror(stderr)) {
puts("Error indicator for stderr set.");
rc = EXIT_FAILURE;
}
} else printf("\nputc returned: %d\n", retval);
return rc;
}

$ ./a.out
Writing EOF to stderr with putc...
?
putc returned: 255
$

Aug 5 '08 #35
On Aug 5, 11:44 am, Barry Schwarz <schwa...@dqel.comwrote:
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vipps...@gmail.com wrote:
<snip>
The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following
o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

google thread
<http://groups.google.com/group/comp....thread/thread/
9047fe9cc86e1c6a/d5b9489e0b16a415>
or use the message id
<c9**********************************@e39g2000hsf. googlegroups.com>
Aug 5 '08 #36
On Aug 5, 12:35 pm, santosh <santosh....@gmail.comwrote:
Barry Schwarz wrote:
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vipps...@gmail.com wrote:
>On Aug 5, 3:40 am, com...@panix.com (Greg Comeau) wrote:
In article <1217878106.929229@news1nwk>,
Eric Sosman <Eric.Sos...@sun.comwrote:
>... set ... the end-of-file
indicator. putc(), for example, cannot.
>Dunno if we're using different words or not, but
putc certainly can return EOF.
>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following
o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.
The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

And here is a test program as well:
<snip>

Test programs like this are meaningless.
It's like claiming that CHAR_BIT is 8 and then writing a test program
to back up the claim...
See my response to Mr Schwarz about EOF and putc.
Aug 5 '08 #37
vi******@gmail.com wrote:
On Aug 5, 11:44 am, Barry Schwarz <schwa...@dqel.comwrote:
>On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vipps...@gmail.com wrote:
<snip>
>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following
o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

google thread
<http://groups.google.com/group/comp....thread/thread/
9047fe9cc86e1c6a/d5b9489e0b16a415>
or use the message id
<c9**********************************@e39g2000hsf. googlegroups.com>
Are you specifically claiming that a call to fputc/putc with EOF as it's
first argument will return EOF if a call to ferror on the stream
immediately after the fputc/putc call returns zero?

Aug 5 '08 #38
vi******@gmail.com wrote:
>
.... snip ...
>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.
Since EOF is a negative constant, it is hard to represent in an
unsigned char.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Aug 5 '08 #39
CBFalconer said:
vi******@gmail.com wrote:
>>
... snip ...
>>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.
It is, however, trivial to convert EOF into an unsigned char.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 5 '08 #40
Richard Heathfield wrote:
CBFalconer said:
>vi******@gmail.com wrote:
>>>
... snip ...
>>>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.
However it is far from trivial to convert an unsigned char into
EOF.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Aug 5 '08 #41
CBFalconer wrote:
Richard Heathfield wrote:
>CBFalconer said:
>>vi******@gmail.com wrote:

... snip ...

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.
That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or putc.
As they take an int expression for their first arguments, it is
possible to do so. That value is then converted inside [f]putc to an
unsigned char value and written to the stream specified. Then this byte
is cast to int and returned, if there are no write errors, in which
case EOF is returned.

I think the issue is whether both of these two (simplified)
implementations of fputc are correct, as per the Standard:

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return (unsigned char)ch;
else { s->err_flag = 1; return EOF; }
}

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return ch;
else { s->err_flag = 1; return EOF; }
}

I think that the Standard doesn't allow the second implementation. The
relevant part is 7.19.7.3 of n1256.

Aug 5 '08 #42
CBFalconer <cb********@yahoo.comwrites:
Richard Heathfield wrote:
>CBFalconer said:
>>vi******@gmail.com wrote:

... snip ...

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.
You just need an implementation where sizeof(int)==1 (which implies
CHAR_BIT>=16). (I'm ignoring the possibility of padding bits.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Aug 5 '08 #43
5On Tue, 5 Aug 2008 05:32:36 -0700 (PDT), vi******@gmail.com wrote:
>On Aug 5, 11:44 am, Barry Schwarz <schwa...@dqel.comwrote:
>On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vipps...@gmail.com wrote:
<snip>
>The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following
o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.

The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.

No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

It will never return EOF as the value of the byte written. That is
what you claimed as the second case and it cannot be. More to the
point, putc will never write a negative value since each byte is
converted to unsigned char. Read the second section of the standard I
reference above.

--
Remove del for email
Aug 5 '08 #44
On Aug 5, 8:23 pm, Barry Schwarz <schwa...@dqel.comwrote:
5On Tue, 5 Aug 2008 05:32:36 -0700 (PDT), vipps...@gmail.com wrote:
On Aug 5, 11:44 am, Barry Schwarz <schwa...@dqel.comwrote:
On Mon, 4 Aug 2008 18:45:02 -0700 (PDT), vipps...@gmail.com wrote:
<snip>
The end of file indicator has nothing to do with the EOF macro.
When putc returns EOF, it means one of the following
o error with the stream; ferror() should return non-zero.
o EOF is a valid byte value that has been written to the stream.
The second case cannot be. EOF is guaranteed to be negative. While
it is certainly possible to pass this value to putc, it will be
converted to unsigned char (7.19.7.8-2 and 7.19.7.3-2). It is this
positive value which will be returned, not EOF.
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.

It will never return EOF as the value of the byte written. That is
what you claimed as the second case and it cannot be. More to the
point, putc will never write a negative value since each byte is
converted to unsigned char. Read the second section of the standard I
reference above.
I'm not convinced. Read the discussion in my message that you snipped.
I don't think you understand the situation I'm talking about.
Aug 5 '08 #45
Barry Schwarz wrote:
>
No one said EOF could not be a valid byte. However, putc will never
put a negative value. In the absence of an error, putc returns the
value it puts. Therefore, in the absence of an error, it must return
a positive value. Since EOF is negative, putc cannot return EOF other
than as an error indicator.
Not even when CHAR_MIN<=EOF and UCHAR_MAX>INT_MAX?

--
Er*********@sun.com
Aug 5 '08 #46
santosh wrote:
CBFalconer wrote:
>Richard Heathfield wrote:
>>CBFalconer said:
vi******@gmail.com wrote:
>
... snip ...
>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.
Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Aug 5 '08 #47
CBFalconer said:
santosh wrote:
<snip>
>The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.

Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.
santosh claimed that, inside [f]putc, the value is converted /to an
unsigned char value/, and that is a perfectly correct claim.

Proof (C89): 4.9.7.3 The fputc function

Synopsis

#include <stdio.h>
int fputc(int c, FILE *stream);

Description

The fputc function writes the character specified by c (converted
to an unsigned char )

Proof (C99): 7.19.7.3 The fputc function
Synopsis
1 #include <stdio.h>
int fputc(int c, FILE *stream);
Description
2 The fputc function writes the character specified by c (converted to
an unsigned char)
You have incorrectly "corrected" santosh. In such circumstances, an apology
is traditional in this newsgroup.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Aug 5 '08 #48
Richard Heathfield wrote:
CBFalconer said:
>santosh wrote:

<snip>
>>The issue here is whether it makes sense to pass EOF to fputc or
putc. As they take an int expression for their first arguments, it
is possible to do so. That value is then converted inside [f]putc
to an unsigned char value and written to the stream specified.
Then this byte is cast to int and returned, if there are no write
errors, in which case EOF is returned.

Nit time. Your analysis is flawed. Notice that in the prototype:

int fputc(int ch, FILE *f);

ch is defined as an int. The conversion to int occurs before the
function is called. So fputc never sees a ch, and never converts
any such.

santosh claimed that, inside [f]putc, the value is converted /to an
unsigned char value/, and that is a perfectly correct claim.
.... trim justification ...
>
You have incorrectly "corrected" santosh. In such circumstances, an apology
is traditional in this newsgroup.
Alright. Apology tendered. It WAS a nit.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Aug 5 '08 #49
On Tue, 05 Aug 2008 20:28:38 +0530, santosh <sa*********@gmail.com>
wrote:
>CBFalconer wrote:
>Richard Heathfield wrote:
>>CBFalconer said:
vi******@gmail.com wrote:
>
... snip ...
>
No it can be. We had a recent discussion about this and I think
everyone agreed that it's possible for EOF to be a valid byte.

Since EOF is a negative constant, it is hard to represent in an
unsigned char.

It is, however, trivial to convert EOF into an unsigned char.

However it is far from trivial to convert an unsigned char into
EOF.

That's impossible and makes no sense too.

The issue here is whether it makes sense to pass EOF to fputc or putc.
As they take an int expression for their first arguments, it is
possible to do so. That value is then converted inside [f]putc to an
unsigned char value and written to the stream specified. Then this byte
is cast to int and returned, if there are no write errors, in which
case EOF is returned.
When the unsigned char is converted back to an int, the value must be
non-negative. In that case it cannot be EOF which is guaranteed to be
negative. In the absence of an error, only non-negative values will
be returned. EOF is only returned on error.
>
I think the issue is whether both of these two (simplified)
implementations of fputc are correct, as per the Standard:

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return (unsigned char)ch;
else { s->err_flag = 1; return EOF; }
}

int fputc(int ch, FILE *s) {
if (write((unsigned char)ch, s) == SUCCESS) return ch;
else { s->err_flag = 1; return EOF; }
}

I think that the Standard doesn't allow the second implementation. The
relevant part is 7.19.7.3 of n1256.
Since you know this to be incorrect, then you know that the return
value will be non-negative in the absence of an error.

--
Remove del for email
Aug 6 '08 #50

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

22
by: TC | last post by:
I have an Access database application with a lot of custom row functions written in VBA. In other words, a lot of queries contain calculated fields which use functions defined in the modules. I...
11
by: sotto | last post by:
If i have this Interface: Public Interface MyInterface Function test() As Boolean Function test(ByVal MyVar As String) As Boolean End Interface And then i make a Public Class MyOwnClass
1
by: George | last post by:
I am new to VB, I need 2 string functions to return last char and remove last char. I made them up. Am I recreating the wheel? do similar functions exist in String? I could not find them ...
11
by: Bruce A. Julseth | last post by:
I have: If (Microsoft.VisualBasic.Left(TextBox1.Text, 1) = "$") Then TextBox1.Text = Microsoft.VisualBasic.Right(TextBox1.Text, TextBox1.Text.Length - 1) End If Adding: Imports...
5
by: Nathan | last post by:
Hi, How can I create a function that will accept as a parameter either a datarow or a datarow array? I want to do this without creating two different functions. Thanks, Nathan
7
by: msxkim | last post by:
How to execute functions in the parent class first and then functions in the child class? For example, I have a parent class with functions 'ONE' and 'TWO' and child class has a function 'THREE'. ...
0
by: Zlatko Matiæ | last post by:
Hello. While I was working with Access Projects (Access front-end with MSDE) I was able to call stored procedures by using ADO command and parameters object. Now I am trying to migrate my...
4
by: markaelkins | last post by:
In the code below I’m trying to figure out how to dynamically perform math functions in a form. To start, I would like to subtract TxtITotal.Text from TxtPTotal.Text and display the results in...
1
by: Newbie | last post by:
I need the following functions using the standards for Week Numbering IE Week one is the first week with a thursday in it. getWeekStartDate( WeekNum as Integer , YearNumber as Integer ) as Date...
31
by: Spiro Trikaliotis | last post by:
Hello, I have a question regarding subtracting a pointer from another one. Assume I have two pointers p1 and p2, which both point to a memory area obtained with malloc(). Assume p1 = p2 + some...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...
0
by: ryjfgjl | last post by:
In our work, we often need to import Excel data into databases (such as MySQL, SQL Server, Oracle) for data analysis and processing. Usually, we use database tools like Navicat or the Excel import...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.