undefined behaviour?

[Friedrich Dominicus]

Re: undefined behaviour?

"santosh" <santosh.k83@gm ail.com> writes:
[color=blue]
> Jordan Abel wrote:[color=green]
>> On 2005-12-15, santosh <santosh.k83@gm ail.com> wrote:[color=darkred]
>> >> char *file_name = "t1.txt";
>> > An uninitialised pointer is being used here.[/color]
>>
>> The line you are responding to is a declaration, and, moreover, one with
>> an initializer.
>>
>> You claim that on your implementation the program crashes on that line.
>> Either you're lying, or you have a very crappy [and non-conforming]
>> implementation.[/color]
>
> Your right. I'm sorry. It was an incredible oversight on my part.
>
> That being said, the code as was posted did crash over here.
> The compiler is gcc (mingw).
> After I introduced error checking for each function call I found that
> the
> first error was with foen().[/color]
Well that does not mean that the code as given was invalid
[color=blue]
> I modified "r+" to "w+" which succeeded, but then ungetc() returned
> EOF.[/color]
That's interesting and I think that should not happen, even if you use
"r+".[color=blue]
> I corrected that by inserting a 'fflush(pf)' before calling
> ungetc().[/color]
I'd argue this is the real problem.

The system as used her has worked fine but baild out on the fclose at
the end. After insering the fflush here this was gone and the result
were as expected.
[color=blue]
> After I changed 'ch' from char to int the program finally executed as
> it[/color]
I don't think this is really a problem.[color=blue]
> should. The contents of the file after running the code is:[/color]
Can't tell I did not care about the content just the fputs + ungetc
stuff. However thanks for taking the time checking all this "stuff"

Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

[Friedrich Dominicus]

Re: undefined behaviour?

"Robert Gamble" <rgamble99@gmai l.com> writes:
[color=blue]
> Here is the appropriate section of the Standard (n1124 to be exact):
>
> 7.19.5.3p6
>
> When a file is opened with update mode ('+' as the second or third
> character in the
> above list of mode argument values), both input and output may be
> performed on the
> associated stream. However, output shall not be directly followed by
> input without an
> intervening call to the fflush function or to a file positioning
> function (fseek,
> fsetpos, or rewind), and input shall not be directly followed by output
> without an
> intervening call to a file positioning function, unless the input
> operation encounters endof-
> file. Opening (or creating) a text file with update mode may instead
> open (or create) a
> binary stream in some implementations .
>
> I hope that relieves any doubt you had about the validity of the
> statements made to that effect here.[/color]

Well that is the "definitive " answer for me. I have not seen
it. Thanks for pointing it out to me.

Regards
Friedrich


--
Please remove just-for-news- to reply via e-mail.

[Nick Keighley]

Re: undefined behaviour?

santosh wrote:[color=blue]
> Friedrich Dominicus wrote:[/color]
[color=blue][color=green]
> > ungetc('z', pf);[/color]
> The first parameter of ungetc() is an int.[/color]

and 'z' *is* an int


--
Nick Keighley

[Keith Thompson]

Re: undefined behaviour?

"Nick Keighley" <nick_keighley_ nospam@hotmail. com> writes:[color=blue]
> santosh wrote:[color=green]
>> Friedrich Dominicus wrote:[/color]
>[color=green][color=darkred]
>> > ungetc('z', pf);[/color]
>> The first parameter of ungetc() is an int.[/color]
>
> and 'z' *is* an int[/color]

And even if it weren't, it would be implicitly converted to int (since
there's a "#include <stdio.h>").

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

Re: undefined behaviour?

On Thu, 15 Dec 2005 16:14:21 +0100, in comp.lang.c , Friedrich
Dominicus <just-for-news-frido@q-software-solutions.de> wrote:
[color=blue][color=green]
>> You cannot use ungetc() on an output-oriented update stream
>> without first using fflush() or a file positioning function.[/color][/color]
[color=blue]
>As posted before I can understand this argument, and as said before I
>have found it out there, but was puzzling about its validity.[/color]

Its in the Standard.

7.19.5.3(6) When a file is opened with update mode ... output shall
not be directly followed by input without an intervening call to the
fflush function or to a file positioning function..., and input shall
not be directly followed by output without an intervening call to a
file positioning function...

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[abdur_rab7@yahoo.co.in]

Re: undefined behaviour?


Though the uninitialised pointer leeds to error,

The code
char *file_name = "t1.txt";
is legal

Always try to check the file opening cause

the code
FILE *pf = fopen(file_name , "r+");

"r+" -- to open an existing text file for reading and writing

if the file does not exists, it will give a null pointer.

If the file does not exists and u try to execute do fputs with null
pointer will cause undefined behaviour

Best Regards,
Abdur