By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,110 Members | 1,010 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,110 IT Pros & Developers. It's quick & easy.

fseek and open_memstream

P: n/a
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
--
Dmitry
Jan 31 '07 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Dmitry Belous <dm***********@ua.fmwrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
open_memstream() is not an ISO C function. It, or its return value,
probably interacts with fseek() in a way that clears buf, but _why_ this
happens is off-topic here. If it's a POSIX function (I don't know, your
compiler should tell you), ask in comp.unix.programmer. If it's not,
find a newsgroup that deals with your implementation - from the looks of
it, that's gcc, so ask gnu.help.something.

Richard
Jan 31 '07 #2

P: n/a
In article <ep***********@pandora.alkar.net>,
Dmitry Belous <dm***********@ua.fmwrote:
>Why when I uncomment fseek line buf become empty?
>#define _GNU_SOURCE
#include <stdio.h>
>int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
What is open_memstream() ? It is not part of C89, and I've never
heard of it being part of C99.
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
You appear to be using an implementation library function. You
will need to ask in a location that specializes in your implementation.
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Jan 31 '07 #3

P: n/a
On 31 Jan, 16:08, Dmitry Belous <dmitry_bel...@ua.fmwrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);}
<Off-topic>
The non-standard open_memstream() function, from the online man pages
I've viewed, allows you to treat a character buffer as an output
stream to which you can write.

Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.

For more information, I suggest you use a GNU libraries newsgroup or
mailing list.
</Off-topic>
Jan 31 '07 #4

P: n/a
In article <11**********************@q2g2000cwa.googlegroups. com>,
<ma**********@pobox.comwrote:
>Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.
Or else fclose() causes a null to get written at the current position.

It's possible that you'll get an answer to this on some Linux newsgroup,
but the answer may be "oh, we forgot to specify exactly what happens when
you use fseek() on these extension streams".

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.
Jan 31 '07 #5

P: n/a
Dmitry Belous wrote:
>
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}
Who knows? open_memstream is undefined. _GNU_SOURCE is useless
(never referenced). main fails to return a value. If you don't
have a C99 compiler // fseek... is a syntax error.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Jan 31 '07 #6

P: n/a
CBFalconer <cb********@yahoo.comwrites:
Dmitry Belous wrote:
Why when I uncomment fseek line buf become empty?
#define _GNU_SOURCE
#include <stdio.h>

int main() {
char *buf = 0;
int size = 0;
FILE* f = open_memstream(&buf, &size);
fwrite("test", 1, 4, f);
// fseek(f, 0, SEEK_SET);
fclose(f);
fprintf(stderr, buf);
}

Who knows? open_memstream is undefined. _GNU_SOURCE is useless
(never referenced). main fails to return a value. If you don't
have a C99 compiler // fseek... is a syntax error.
On *some* systems, open_memstream is declared in <stdio.hif
_GNU_SOURCE is defined (so _GNU_SOURCE is referenced in <stdio.h>);
since _GNU_SOURCE is in the implementation's namespace, this is
permitted.

// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 1 '07 #7

P: n/a
Keith Thompson wrote:
// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.
Why do you guys waste so much time on these obviously OS specific code
questions that are not even worth approaching?
Feb 1 '07 #8

P: n/a
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a legal
C90 program, outside a comment, string literal, or character constant;
if the compiler treats it as a comment delimiter in such cases, it's
not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

Why do you guys waste so much time on these obviously OS specific code
questions that are not even worth approaching?
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 1 '07 #9

P: n/a
Keith Thompson wrote:
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?

It's like an attempt to not be an enabler to the OP but with the added message
of "oh and none of this shit is portable either, go to another NG."
Feb 1 '07 #10

P: n/a
Christopher Layne wrote:
Keith Thompson wrote:
>// is a syntax error if you have a compiler that implements C90
without extensions; it's accepted by many compilers that don't
implement all of C99. There are cases where // can appear in a
legal C90 program, outside a comment, string literal, or character
constant; if the compiler treats it as a comment delimiter in such
cases, it's not a conforming C90 compiler.

In C99, falling off the end of main() has the effect of "return 0;".

Your overall point, that the code depends on implementation-specific
features and is therefore off-topic, is quite correct, of course.

Why do you guys waste so much time on these obviously OS specific
code questions that are not even worth approaching?
Because if they are not pointed out, they will have kittens. Soon
we would be knee deep in yowling feral cats and all the birds would
have been eaten.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
Feb 1 '07 #11

P: n/a
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?
[...]

Because we like helping people.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 1 '07 #12

P: n/a
CBFalconer wrote:
Because if they are not pointed out, they will have kittens. Soon
we would be knee deep in yowling feral cats and all the birds would
have been eaten.
That's the fear. Yet you need food for kittens to grow.
Feb 1 '07 #13

P: n/a
Keith Thompson wrote:
Because we like helping people.
Hah.

s#helping people#being right#g
Feb 1 '07 #14

P: n/a
Keith Thompson said:

<snip>
I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Well, we *could* get some programming done...

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 1 '07 #15

P: n/a
On 31 Jan, 17:31, rich...@cogsci.ed.ac.uk (Richard Tobin) wrote:
In article <1170263751.020700.309...@q2g2000cwa.googlegroups. com>,

<mark_blue...@pobox.comwrote:
Seeking back to the beginning is presumably regarded as preparation to
write again, so in effect it clears the buffer.

Or else fclose() causes a null to get written at the current position.
Doh! Of course...

Feb 1 '07 #16

P: n/a
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
Because we like helping people.

Hah.

s#helping people#being right#g
The two are not incompatible.

This is boring. Bye.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 1 '07 #17

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>Why is it?
[...]

Because we like helping people.
Translation: Because we have no lives.

Feb 1 '07 #18

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
....
>I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?
Just ignore it. (As you *claim* to do with the "trolls")
The idea is, if it is effective there, then it should be so here.

Feb 1 '07 #19

P: n/a
Christopher Layne <cl****@com.anodizedwrites:
Keith Thompson wrote:
>I was responding to CBFalconer's followup. Chuck wrote just 3 lines
that, in effect, pointed out that the code is implementation-specific,
hardly a huge waste of time. I wasn't commenting directly on the
original code; I was quibbling about some technical points in Chuck's
followup.

What do you suggest we do instead?

Well you know I'm not going to tell you what to do Keith. :) It's just that I
see people post such completely random code that it so off-base, yet people
still chase after it like rabid dogs waiting to throw down the corrections.
Why is it?

It's like an attempt to not be an enabler to the OP but with the added message
of "oh and none of this shit is portable either, go to another NG."
It is the biggest "put off" in this NG IMO. A bunch of show offs rushing
to be first to post the "standard correction". Often they post the
correction even though they can see it has been done 20 times already.

Tedious and mind numbingly petty isn't sufficient to describe the
characters of certain contributors to this NG.

Again : if you don't want to be constructive and help, then don't reply.
Feb 2 '07 #20

P: n/a
Richard <rg****@gmail.comwrites:
[...]
Again : if you don't want to be constructive and help, then don't reply.
Correcting errors is constructive.

--
Keith Thompson (The_Other_Keith) ks***@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.
Feb 2 '07 #21

P: n/a
Richard said:

<snip>
Again : if you don't want to be constructive and help, then don't reply.
When you've posted a large volume of constructive, helpful replies on C
programming, maybe - just *maybe* - I'll start taking an interest in your
netiquette suggestions. Until then, if you can't be constructive and
helpful, don't expect me to treat you seriously.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
Feb 2 '07 #22

P: n/a
In article <s5******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Richard said:

<snip>
>Again : if you don't want to be constructive and help, then don't reply.

When you've posted a large volume of constructive, helpful replies on C
programming, maybe - just *maybe* - I'll start taking an interest in your
netiquette suggestions. Until then, if you can't be constructive and
helpful, don't expect me to treat you seriously.
Oh God. The irony...

Feb 2 '07 #23

P: n/a
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Richard <rg****@gmail.comwrites:
[...]
>Again : if you don't want to be constructive and help, then don't reply.

Correcting errors is constructive.
No, its not.

(Except for this one, of course)

Feb 2 '07 #24

This discussion thread is closed

Replies have been disabled for this discussion.