fseek and open_memstream

[Dmitry Belous]

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);
}

 

[Richard Bos]

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

 

[Walter Roberson]

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.

 

[mark_bluemel]

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>

 

[Richard Tobin]

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

 

[CBFalconer]

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

 

[Keith Thompson]

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.h> if
_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.

 

[Christopher Layne]

// 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?

 

[Keith Thompson]

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?

 

[Christopher Layne]

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

 

[CBFalconer]

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

 

[Keith Thompson]

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.

 

[Christopher Layne]

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.

 

[Christopher Layne]

Because we like helping people.

Hah.

s#helping people#being right#g

 

[Richard Heathfield]

Keith Thompson said:

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

 

[mark_bluemel]

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

Doh! Of course...

 

[Keith Thompson]

Hah.

s#helping people#being right#g

The two are not incompatible.

This is boring. Bye.

 

[Kenny McCormack]

Why is it?

[...]

Because we like helping people.[/QUOTE]

Translation: Because we have no lives.

 

[Kenny McCormack]

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.

 

[Richard]

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.