At about the time of 3/25/2007 10:10 AM, Barry Schwarz stated the following:
snip
As for strncpy(3), the man page states the following:
The strncpy() function copies at most len characters from src into dst.
If src is less than len characters long, the remainder of dst is filled
with `\0' characters. Otherwise, dst is not terminated.
if (feof != 0) eof_flag = 1;
snip
if (strlen(argv[1]) > sizeof(infilename) - 2)
Why -2? If strlen() returns 5 and sizeof evaluates to 6, there is
room for the name plus the '\0'.
Call it paranoia about security. I didn't want to take the chance of
having a off-by-one error. Better to be sure now than fixing a
security problem later.
strncpy(infilename, argv[1], sizeof(infilename) - 2);
Since you know it will fit at this point, why not strcpy, which will
include the terminal '\0', eliminating the need for the next
statement?
Security Paranoia.
Does malloc() set errno? Is it required to? Shouldn't you clear
errno before the call?
Yes, and No.
No and yes actually.
If malloc returns NULL for a non 0 memory allocation request, that means
it failed, reguardless of what the error was. Usually, unless something
really bizarre happened, errno would be set to ENOMEM. I dunno about
Linux, but the BSDs and Mac OSX exhibit this behavior. I'll have to
check the man pack on a sun to see what Solaris does with it.
What *IS* n1124? I see everyone referring to it, but I don't know what
it is and I don't have it.
Setting errno by malloc is neither required nor prohibited. It
may on your system but portable code cannot depend on it. (Portable
also include the next update to your library.)
Library functions are allowed to set errno even if no error
occurs.
No library function is allowed to reset errno.
Footnote 172 recommends setting errno to 0 before calling a
function if you intend to use the value after the function returns.
A little paranoia in a programmer is a good thing. But you are acting
inconsistently. You refuse to accept the documented behavior of
strncpy (propagating '\0' to fill the destination array) but are quite
willing to accept undocumented properties about errno (who sets it and
how long the values persist). Hobgoblins of small minds not
withstanding, consistency in a programmer is a very good thing.
Well, the little blurb there about strncpy says that it will behave like
that UNLESS src fills dst completely, then dst is *NOT* null terminated.
I'm doing it to make sure. Besides, *MOST* library function return
some indication that an error occurred. A value like -1 or 0, or
returns a number of bytes smaller than what was requested. That's what
I did with the fread functions.
If fread returned less than what I requested, then I checked for EOF.
If it wasn't an EOF that caused a short read, then the only thing that
it can be is an error.
snip
Not according to n1124. It is neither required nor prohibited.
Consequently, portable code cannot depend on it.
If your man page says this then it is wrong. n1124 does not state
"only" which is good because we know that fseek will also clear the
end-of-file indicator.
That was a direct quote. It must be system dependent behavior then.
Unfortunately, this has nothing to do with my question.
While feof cannot clear errno (see previous comment), it is allowed to
set it to a non-zero value. Depending on the value from fread still
being present after feof is called is non-portable.
The error indicator and errno are two completely separate topics.
Again, n1124 does not say "only".
This statement is not part of the standard. Furthermore, the standard
specifically states that errno need not be an external variable.
From your context, I cannot tell what "These functions" refer to. If
it is only ferror and feof (seems likely given the context) then it is
probably true but also irrelevant.
Not portably.
There is no fpurge in n1124. It may be posix (since you reference man
pages) but it is not standard.
I went looking for it, but I can't seem to find it outside of the
fflush(3) man page. I could have sworn it was in my C manual.
snip
The #if block is unnecessary. If you intend to keep it, you probably
need to insert a #undef before the #define.
Someone complained about that, but I guess I can take the entire
construct out and leave it as a simple #define.
#define FILENAMESIZE 1024 /* max size of filenames */
int copyfile(const char *infilename, const char *outfilename);
void cleanup(FILE *infile, FILE *outfile, void *buffer);
int main(int argc, char **argv)
{
int i; /* generic variable */
char infilename[FILENAMESIZE]; /* input filename */
char outfilename[FILENAMESIZE]; /* output filename */
/* get filenames */
if (argc != 3)
{
switch(argc)
{
case 1:
printf("Enter path/filename to copy -->");
fflush(stdout);
fpurge(stdin);
No such standard function.
I thought it was in the C manual, but I guess not. I went looking for it.
snip
You call cleanup for normal end of input and for errors on either
stream. If the error was on outfile, this fflush will probably also
fail and you will have two error messages for the same condition.
So how would you have handled it?
Slightly redundant since fclose(outfile) will automatically flush the
stream.
Remove del for email
--
Daniel Rudy
Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m
Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep
